2026.05.21第30回SBOMとは？
ソフトウェアの「部品表」が守るサプライチェーンの安全性
他社のシステムに侵入する『ペネトレーションテスト』を業務とする筆者が、攻撃者の目線でセキュリティ対策について考えます。
株式会社トライコーダ 代表取締役
上野 宣 氏 氏
奈良先端科学技術大学院大学で情報セキュリティを専攻。2006年に株式会社トライコーダを設立。ハッキング技術を駆使して企業などに侵入を行うペネトレーションテストや各種サイバーセキュリティ実践トレーニングなどを提供。
攻撃者が組織のシステムに侵入する際には、必ずしもその組織のサーバーやシステムを直接狙うとは限りません。むしろ、より労力の少ない「別の入口」を探します。その一つが「ソフトウェアサプライチェーン」、つまり「ソフトウェアを構成する部品やサービスのつながり」です。クラウドやSaaS、オープンソースソフトウェア（OSS）などを組み合わせて開発を行う現代では、一つのアプリケーションの中に数十、数百ものライブラリが含まれています。攻撃者はこの中に脆弱な部品を見つけると、それを突破口として侵入を試みます。こうした見えないリスクを可視化するために登場したのが「SBOM（Software Bill of Materials ： ソフトウェア部品表）」です。
すでに攻撃は起きている
2020年に発生した「SolarWinds事件」は、ソフトウェアサプライチェーン攻撃の代表例です。ネットワーク監視ツールの更新プログラムに不正なコードが混入され、約1万8,000社に配布されました。この攻撃では、攻撃者が1社を狙う代わりに、そのソフトウェアを利用している組織すべてに同時に侵入するという、極めて効率的な攻撃を実現したのです。
また、2021年には、JavaのOSSライブラリ「Log4j」に深刻な脆弱性が見つかり、世界中のシステムが影響を受けました。多くの企業が「自社の製品やサービスがそのライブラリを使っているかどうか」を把握できていなかったことが問題でした。脆弱性が公開されても、どこに使われているのかがわからなければ、修正もできません。この“見えない部品”の存在こそが、攻撃者にとって格好のターゲットとなるのです。
SBOMとは何か
SBOMは「ソフトウェアの部品表」を意味し、ライブラリやモジュールなど、ソフトウェアを構成するすべての部品の依存関係やバージョン、ライセンス情報などを一覧化したものです。製造業でいえば、製品を構成する部品の一覧表（BOM）と同じ考え方です。
例えば、あなたがWebアプリケーションを開発しているとします。その中で使われているのは、フレームワーク、ログ機能のライブラリ、暗号化モジュールなど多岐にわたります。SBOMを作成すれば、どの部品がどのバージョンで、どんなライセンス条件で使われているかを一覧で把握することが可能です。つまり、「このソフトウェアには何が入っているか」を正確に説明できる状態をつくるのです。
なぜSBOMが必要なのか
攻撃者は常に「どのソフトウェアに脆弱な部品が含まれているか」を探しています。公開された脆弱性情報（CVE）を参照し、特定のライブラリやバージョンを狙ってスキャンをかけるのが一般的な手法です。もしあなたの製品が古いライブラリを使っていれば、攻撃者はその情報から容易に侵入経路を特定できます。一方、防御する側はどうでしょうか。自社のソフトウェアにどのライブラリが含まれているかを把握していなければ、脆弱性が見つかっても「どこに影響があるのか」が判断できません。対応が遅れるほど、攻撃のリスクは高まります。SBOMは、こうした「知らなかった」をなくすための仕組みなのです。
また、法的にもSBOMの重要性は高まっています。アメリカでは2021年の大統領令（EO 14028）で、政府と取引するソフトウェア開発者にSBOMの提供が義務づけられました。日本でも経済産業省やIPA（独立行政法人情報処理推進機構）がSBOMの整備を推奨しています。今後は調達や取引の条件として求められることが増えていくでしょう。
SBOMは誰が、何に使うのか
SBOMは単なる技術者向けの資料ではありません。組織のさまざまな立場で活用されます。
- セキュリティ担当者
脆弱なライブラリを迅速に特定し、修正を指示できる - 開発者
依存関係の把握や更新時の影響範囲を確認できる - 調達・契約担当
取引先に対して安全性を要求できる - 経営層
ソフトウェアの安全性を説明するエビデンスとして活用できる - インシデント対応チーム
脆弱性報告が出た際に、影響範囲を即座に特定できる
SBOMの作り方と運用のポイント
SBOMの代表的な規格には「CycloneDX」と「SPDX（Software Package Data Exchange）」があります。このSBOMは手作業で作るものではありません。ビルドプロセスやリリース工程にSBOM自動生成ツールを組み込み、常に最新の状態を保つことが基本です。生成したSBOMは、リポジトリやアーティファクト管理ツールに保管し、脆弱性データベース（NVDやJVNなど）と照合して自動的にリスクを検出します。開発現場ではCI/CDパイプラインの中でSBOMを生成・更新することで、運用負荷を最小限にできます。
また、生成したSBOMをどこまで共有するかも重要です。顧客や取引先への開示は信頼性の証しとなる一方で、攻撃者に内部構造を知られるリスクにもつながります。公開範囲を制御し、アクセス権限を厳格に管理することが求められます。
攻撃者視点で見たSBOMの意義
攻撃者は、システムを分解して「どの部品に弱点があるか」を調べます。守る側がSBOMを作るということは、攻撃者と同じ視点で自らのシステムを“分解して理解する”ということです。つまり、SBOMは「攻撃者の武器を、守る側の武器に変える」ための仕組みといえます。
SBOMは導入しただけで安全になるわけではありません。作った後に更新しなければ、すぐに古い情報になってしまいます。脆弱性情報との突き合わせや、修正対応フローの整備といった「運用」があってこそ真価を発揮します。
可視化こそ最大の防御
サプライチェーン攻撃の恐ろしさは、「自分では制御できない部分」から侵入されることにあります。しかし、どんなに複雑なシステムでも、まず構成要素を“見える化”すれば対策の糸口はつかめます。
攻撃者が狙うのは、組織が気づいていない場所です。だからこそ、SBOMによってソフトウェアの全体像を把握し、「見えていなかったリスク」を照らし出すことが、セキュリティ強化の第一歩になります。SBOMは単なるリストではなく、攻撃対象領域（Attack Surface）を管理するための防御地図です。ソフトウェアの透明性を高めることが、結果として組織の信頼性を守ることにつながるのです。
（「SKYSEA Client View NEWS Vol.107」 2026年4月掲載）