SBOMとは：「ソフトウェアの成分表」
製品の食品に「成分表示（原材料名・添加物の一覧）」が義務付けられているように、ソフトウェアにも「何で構成されているか」を示す部品表が必要だという考えが世界的に広がっています。これがSBOM（Software Bill of Materials、ソフトウェア部品表）です。
SBOMとは、特定のソフトウェア製品・システムが使用しているすべてのコンポーネント（OSSライブラリ・フレームワーク・サードパーティ製ソフトウェア・依存関係）を一覧化した構造化データです。各コンポーネントのバージョン・ライセンス情報・既知の脆弱性との関係を記録します。
食品の成分表が「アレルゲンを持つ消費者がその食品を食べても安全かを判断できる」ように、SBOMは「ある脆弱性（CVE）が発覚した際に、自社のどのシステムが影響を受けるかを判断できる」ためのデータです。
なぜ今SBOMが必要なのか：Log4Shellが示した教訓
「使っているかどうかわからない」問題
2021年12月9日、セキュリティ研究者が「Log4Shell（CVE-2021-44228）」と名付けられた脆弱性を公開しました。Javaアプリケーションで広く使われるロギングライブラリ「Apache Log4j 2」に存在するリモートコード実行脆弱性で、CVSSスコアは最高値の10.0。攻撃の容易さと影響の深刻さから、史上最悪のソフトウェア脆弱性の一つとして記録されています。
このインシデントで明らかになった最大の問題は、「自社のどのシステムにLog4jが使われているかを把握できていない企業が続出した」ことです。
Log4jはJava向けの非常に基礎的なライブラリであり、多くのソフトウェアが直接的・間接的に依存していました。製品ベンダーのソフトウェアに含まれる場合、サードパーティのコンポーネントに含まれる場合など、自社が直接導入した覚えのないLog4jが様々な形で組み込まれていたため、「影響を受けるシステムの特定」に多くの企業が数週間〜数ヶ月を要しました。
もしSBOMが整備されていれば、「Log4j 2.x.x（脆弱なバージョン）を使用しているシステムの一覧」を数分で抽出でき、対応の優先順位付けを迅速に行えたはずです。
現代のソフトウェアの「複雑な依存関係」
現代のソフトウェア開発は、OSSライブラリを組み合わせて効率的に構築するのが一般的です。しかし、一つのアプリケーションが依存するライブラリの数は膨大です。
例えば、典型的なNode.jsアプリケーションは数百〜数千のnpmパッケージに依存しています。Pythonのアプリケーションも同様に多数のPyPIパッケージを使用します。これらの中には「ライブラリのライブラリ（推移的依存関係）」も含まれており、開発者が直接インストールしたパッケージだけでなく、そのパッケージが依存するパッケージまで含めると、依存関係の総数は非常に大きくなります。
この複雑さを人手で管理することは現実的でなく、自動化されたSBOM生成・管理ツールが必要です。
経産省「SBOM導入の手引ver2.0」（2024年8月）の要点
経済産業省は2023年3月に「ソフトウェア管理に向けたSBOMの導入に関する手引」を発行し、2024年8月に「ver2.0」として大幅に改訂・拡充しました。製造業・IoT・組み込みシステムを含む幅広い産業を対象とした日本初の包括的なSBOMガイドラインです。
手引の主要な内容
SBOM整備のメリット（手引より）：
- 脆弱性対応の効率化：新たな脆弱性情報が公開された際に、影響を受けるコンポーネントを迅速に特定できる
- ライセンスコンプライアンスの管理：OSSのライセンス（GPL・MIT等）の遵守状況を一元管理できる
- サプライチェーンリスクの可視化：委託先・ベンダーのソフトウェアに含まれるコンポーネントを把握できる
- 製品安全性の向上：製品出荷後の脆弱性対応を組織的・迅速に実施できる
SBOM整備の推奨フォーマット：
手引ではSBOMのデータフォーマットとして、以下の2つが広く使われており互換性もあることが示されています。
- SPDX（Software Package Data Exchange）：Linux Foundation主導の国際標準（ISO/IEC 5962）
- CycloneDX：OWASP主導のフォーマット。セキュリティユースケースに強みを持つ
段階的な導入アプローチ：
手引は「すべてのシステムを一度に対応することは難しい」という現実を踏まえ、重要度の高いシステムから段階的に整備することを推奨しています。
EU サイバーレジリエンス法（CRA）：2027年段階的義務化
CRAとは
EU Cyber Resilience Act（サイバーレジリエンス法、CRA）は、EUで販売されるデジタル要素を持つ製品（ソフトウェア・IoT機器・その他ハードウェア）に対してセキュリティ要件を義務付ける法規制です。2024年12月にEU官報に掲載され、2027年から段階的に義務が発効します。
CRAがSBOMに関連する理由
CRAでは以下のセキュリティ要件が義務付けられており、SBOMはこれらの要件を満たすための基盤となります。
- 既知の脆弱性への対応義務：製品に含まれる脆弱なコンポーネントを特定し、適時にパッチを提供すること
- 脆弱性の開示義務：製品に含まれる既知の悪用可能な脆弱性をCERTに報告すること（24時間以内）
- セキュリティアップデートの提供義務：製品のサポート期間（最低5年）中、セキュリティアップデートを無料提供すること
これらの義務を果たすためには、製品に含まれるすべてのコンポーネントを把握しているSBOMが不可欠です。
日本企業への影響
EUで製品を販売または提供している日本企業（製造業・ITベンダー・IoT機器メーカー等）は、CRAへの対応が求められます。違反した場合の制裁は最大で年間世界売上高の2.5%または1,500万ユーロの高い方となっており、その影響は軽視できません。
2027年の発効までに十分な準備期間があるように見えますが、SBOM整備・脆弱性管理プロセスの構築・組織体制の整備には相当の時間がかかるため、今から準備を始めることが重要です。
15カ国「SBOMの共有ビジョン」国際ガイダンス（2025年9月）
2025年9月、米国CISA・英国NCSC・日本のNISC（内閣サイバーセキュリティセンター）を含む15カ国のサイバーセキュリティ機関が共同で「SBOMの共有ビジョン（A Shared Vision for SBOM）」と題した国際ガイダンスに署名しました。
このガイダンスは、SBOMを国際的なソフトウェアサプライチェーンセキュリティの基盤として位置づけ、各国が一貫したアプローチでSBOMの普及・活用を進めることを促しています。
ガイダンスの主要なメッセージ：
- SBOMはソフトウェアの透明性を確保するための基礎的なツールである
- ソフトウェアを開発・販売・調達するすべての組織がSBOMの作成・受け取り・活用に取り組むべきである
- SBOM単独ではなく、脆弱性管理・セキュリティテスト・インシデント対応と組み合わせることで真の効果が発揮される
NISCが署名したことは、日本政府としてSBOMを重要なセキュリティ施策として位置づけていることを意味します。経産省の手引と合わせて、日本企業にとってSBOM対応の機運は急速に高まっています。
SBOMと脆弱性管理の連携方法
SBOMは「部品表を持つこと」自体が目的ではなく、「脆弱性への迅速な対応を可能にすること」が本来の目的です。SBOMを脆弱性管理プロセスと連携させることで初めてその価値が発揮されます。
ステップ①：SBOM生成の自動化
ソフトウェアのビルドプロセス（CI/CDパイプライン）にSBOM生成ツールを組み込み、リリースのたびに最新のSBOMを自動生成します。
主要なSBOM生成ツール：
- Syft（Anchore）：コンテナイメージ・ファイルシステムからSBOMを生成するオープンソースツール
- cyclonedx-cli：CycloneDXフォーマットのSBOMを生成・変換するCLIツール
- SPDX Tools：SPDXフォーマットのSBOM生成・検証ツール
- Trivy：コンテナ・ファイルシステムの脆弱性スキャンとSBOM生成を兼ねるツール
- Dependency-Track（OWASP）：SBOMの管理・脆弱性トラッキングを行うオープンソースプラットフォーム
ステップ②：脆弱性データベースとの照合
生成したSBOMを脆弱性データベース（NVD・OSV・JVN等）と照合し、SBOMに含まれるコンポーネントの既知の脆弱性を自動的に検出します。OWASP Dependency-Trackなどのツールは、SBOMをアップロードするだけでCVEとの照合・リスクスコアの算出を自動で行います。
ステップ③：継続的な監視とアラート
脆弱性データベースは毎日更新されています。過去に生成したSBOMに含まれるコンポーネントに対して新たなCVEが追加された際に自動的にアラートを受け取る仕組みを構築することで、「後から発覚した脆弱性」にも迅速に対応できます。
ステップ④：パッチ対応の優先順位付け
検出された脆弱性をすべて即座に修正することは現実的ではありません。CVSSスコア・悪用可能性（EPSS等）・そのコンポーネントが担う機能の重要性などを考慮してリスクをスコア化し、修正の優先順位を決定します。
製造業・IoT企業固有の課題
製造業やIoT機器メーカーにとって、SBOMには特有の難しさがあります。
組み込みソフトウェアの複雑さ
製造機器・医療機器・産業用IoTのソフトウェアは、RTOSやBSPなどの専用プラットフォーム上で動作するケースが多く、一般的なSBOM生成ツールが対応していない場合があります。また、製品のライフサイクルが長い（10〜30年）製造業では、レガシーコンポーネントのSBOM遡及整備という課題も生じます。
サードパーティ・OEM部品の問題
製造業では、完成品を構成する多数のサードパーティ部品・OEM部品にもソフトウェアが含まれます。部品メーカーからSBOMを入手する仕組みを構築することが、完成品レベルのSBOM整備には不可欠ですが、サプライヤーのSBOM対応度はまだ低い状況です。
製造業のOTセキュリティについては、製造業のOTセキュリティ対策ガイドもあわせてご覧ください。
長期サポート（PSIRT活動）との連携
製品出荷後も長期間にわたって脆弱性対応を行うためのPSIRT（Product Security Incident Response Team）活動において、SBOMは脆弱性の影響範囲調査の基盤として機能します。特にEU CRAの発効後は、PSIRTとSBOM管理を連携させた体制の整備が義務的要件になります。
日本企業が今やるべきこと：まず棚卸しから
SBOMの全社整備は一朝一夕にはできません。以下の順序で段階的に取り組むことをお勧めします。
フェーズ1：現状把握（0〜3ヶ月）
まず「自社の主要システム・製品に何が使われているか」の棚卸しから始めます。
- 対象システムの優先順位付け：重要度（外部公開・機密データ処理・事業継続への影響）でシステムを分類する
- 手動棚卸しの実施：優先度上位のシステムについて、使用しているOSSライブラリを手作業でリストアップする（まず概要把握）
- 自動化ツールの評価：SBOMを自動生成できるツールを評価・選定する
フェーズ2：高優先度システムのSBOM整備（3〜12ヶ月）
- CI/CDへのSBOM生成組み込み：高優先度システムのビルドパイプラインにSBOM生成を自動化する
- 脆弱性照合の自動化：Dependency-Trackなど脆弱性管理ツールを導入し、CVEとの照合を開始する
- 運用プロセスの確立：SBOMの更新・脆弱性アラートへの対応フロー・責任者を定義する
フェーズ3：全社展開とサプライヤー連携（1〜3年）
- 対象を全システムに拡大：段階的に棚卸し・SBOM生成の対象を全システムに拡大する
- サプライヤーへの要求：委託先・部品メーカーに対してSBOMの提供を契約要件に盛り込む
- EU CRA対応の完了：EU市場向け製品のCRA要件への適合を確認する
サプライチェーン全体でのSBOM連携については、サプライチェーン攻撃とは？2025年の国内事例と企業が取るべき対策もご参照ください。
よくある質問（FAQ）
Q1. SBOMの作成は義務ですか？
A. 日本では現時点（2026年）で法的な義務はありません。ただし、EU CRAの適用対象となるEU市場向け製品については、2027年から段階的に実質的な義務となります。また、米国では連邦政府調達においてSBOMの提供が義務付けられており、米国政府機関と取引する企業は対応が必要です。経産省は導入を推奨していますが強制ではなく、現時点では業界標準として自主的な整備が推進されています。
Q2. SBOMの整備にはどのくらいのコストがかかりますか？
A. 初期コストはシステムの規模・複雑さによって大きく異なります。オープンソースツール（Syft・OWASP Dependency-Track等）を使えば、ツール自体の費用は無料ですが、導入・設定・運用の工数が発生します。商用ツール（Black Duck・Snyk等）は年間数百万円〜のライセンス費用がかかりますが、充実したサポートと高い自動化機能を提供します。
Q3. SBOMはどの部署が担当すべきですか？
A. SBOM整備は「開発部門」「セキュリティ部門」「調達・購買部門」の連携が必要です。開発部門がSBOMを生成・更新し、セキュリティ部門が脆弱性管理・対応の優先順位付けを担い、調達部門がサプライヤーへのSBOM要求を管理するという役割分担が一般的です。CISO・CTO直轄のタスクフォースとして立ち上げることも有効です。
Q4. 既存システム（レガシー）のSBOMはどうすれば？
A. レガシーシステムのSBOM遡及整備は、新規システムより難しい課題です。まず「このシステムに重大な脆弱性が発覚した場合、どれだけ迅速に影響範囲を特定できるか」を評価し、対応が困難なシステムについては優先的にSBOM整備を進めます。完璧なSBOMを目指すのではなく、まず「主要なコンポーネントの一覧化」から始めることが現実的です。
Q5. OSSライブラリを使っていない自社開発ソフトウェアはSBOMが不要ですか？
A. 完全に自社開発でOSSを全く使っていないソフトウェアは珍しく、コンパイラ・標準ライブラリ・フレームワーク等に何らかの外部コンポーネントを使っているケースがほとんどです。また、「自社コードにも脆弱性は存在する」という観点では、SBOMは外部コンポーネントの管理だけでなく、自社コードの脆弱性管理（SASTの活用等）と組み合わせた取り組みが重要です。
Q6. SBOMとライセンスコンプライアンスの関係は？
A. SBOMにはコンポーネントのライセンス情報も記録されるため、OSSのライセンス遵守状況（GPL汚染・商用利用制限等）の管理にも活用できます。GPL等のコピーレフトライセンスのライブラリを組み込んだ製品を販売する場合、ソースコードの公開義務が生じますが、SBOMなしでは全コンポーネントのライセンスを把握できません。ライセンス管理ツール（FOSSA・TLDR Legal等）との連携も検討に値します。
Q7. SBOM整備をベンダー任せにできますか？
A. ベンダーにSBOM生成を委託することは可能ですが、SBOMの「受け取り・管理・活用」は自社で行う必要があります。特に脆弱性アラートへの対応・パッチ適用の判断は自社責任です。また、複数ベンダーのシステムを使う場合、各ベンダーから受け取ったSBOMを統合管理するプラットフォームが必要です。
まとめ
SBOMは「ソフトウェアの透明性」を確保するための現代のセキュリティ管理に不可欠なツールです。Log4Shellが示したように、自社のシステムに何が使われているかを把握できていないことは、深刻なセキュリティリスクに直結します。
2026年の状況を踏まえると、以下の企業は特に緊急性が高いと言えます。
- EU市場に製品を販売・提供している製造業・IoT企業：CRA（2027年発効）への対応準備
- 米国連邦政府機関との取引がある、または予定している企業：SBOM提供の要求に対応するため
- 重要インフラ・産業制御システムを扱う企業：サプライチェーン攻撃リスクの高い環境でのSBOM管理
今すぐできることは「まず棚卸しから始めること」です。SBOMの全社整備は長期的なプロジェクトですが、最初の一歩として「最も重要なシステム・製品に何が含まれているか」を把握することから始められます。
AEVUSでは、プラットフォーム診断・Web/Mobile脆弱性診断を通じて、SBOM整備と脆弱性管理の連携を支援するサービスを提供しています。SBOMの導入方法・脆弱性管理体制の構築についてのご相談は、AEVUSにお気軽にお問い合わせください。
