SBOM（Software Bill of Materials：ソフトウェア部品表）は、あるソフトウェア製品に含まれるすべてのコンポーネント・ライブラリ・依存関係を機械可読な形式で一覧化したドキュメントです。Log4Shellやaxios サプライチェーン攻撃のような広範囲に影響する脆弱性が発覚した際、自社の製品やシステムに当該ライブラリが含まれているかを即座に特定できるかどうかは、被害規模を大きく左右します。本記事では、SBOMの定義・主要フォーマット・国内外の規制動向、そして導入のステップを解説します。
SBOMとは：ソフトウェアの「成分表示」を可視化する仕組み
SBOMの定義
SBOMは、ソフトウェア製品を構成する以下のような情報を構造化して記述したものです。
- 含まれるコンポーネント名（ライブラリ・モジュール・パッケージ）
- バージョン番号
- サプライヤー（開発元・配布元）
- 一意識別子（PURL、CPE など）
- 依存関係（どのコンポーネントが何に依存しているか）
- ライセンス情報
- ハッシュ値（改ざん検知用）
食品の「成分表示」のように、ソフトウェアに何が含まれているかを明示することがSBOMの役割です。
なぜ「部品表」が必要なのか
現代のソフトウェアは、自社開発コードよりもオープンソース（OSS）依存の比率が圧倒的に高いケースが一般的です。Synopsys（現Black Duck）の「Open Source Security and Risk Analysis Report」では、商用コードベースの大半でOSSが使用され、その多くに既知の脆弱性が含まれていると報告されています。
依存ライブラリはさらに別の依存ライブラリを呼ぶ「推移的依存」を持ちます。直接importしているライブラリは10個でも、その下に数百〜数千の間接依存が連なるのが現実です。SBOMがなければ、自社製品に何が含まれているかを正確に把握することすら困難です。
フィッシング訓練選定ガイド
フィッシング訓練サービスの選び方を解説。訓練テンプレート、レポーティング、AI活用など、効果的な訓練に必要な機能を比較できます。
SBOMが必要とされる背景：サプライチェーン攻撃と脆弱性対応
Log4Shellが明らかにした「見えない依存」のリスク
2021年12月に公表されたApache Log4j 2の脆弱性（CVE-2021-44228、通称Log4Shell）は、世界中の組織を混乱させました。Log4jは多数のJavaアプリケーション・製品に組み込まれており、「自社のどのシステムにLog4jが含まれているか」を即座に答えられない組織が大半だったためです。
SBOMが整備されていれば、対象バージョンを含む製品をクエリ1つで特定できます。整備されていなければ、ベンダーへの問い合わせ・ソースコード調査・パッケージマネージャの全件確認といった手作業に追われることになります。
サプライチェーン攻撃の高度化
近年のサイバー攻撃は、最終ターゲット企業を直接狙うのではなく、その企業が利用するソフトウェアやライブラリを汚染する「サプライチェーン攻撃」が増加しています。代表例として、SolarWinds Orion事件（2020年）、3CX事件（2023年）、polyfill.io事件（2024年）などが挙げられます。
攻撃の入り口が「自社が信頼して利用していたソフトウェア」であるため、従来型の境界防御だけでは検知が困難です。SBOMによってサプライチェーン全体を可視化することが、検知と被害局所化の前提となります。
SBOMの主要フォーマット
SBOMには国際的に普及している3つの主要フォーマットがあります。
| フォーマット | 主導団体 | 特徴 |
|---|---|---|
| SPDX | Linux Foundation | ISO/IEC 5962:2021として国際標準化。ライセンス管理に強み |
| CycloneDX | OWASP Foundation | セキュリティ用途に最適化。脆弱性情報の付与がしやすい |
| SWID Tag | NIST / ISO/IEC 19770-2 | ソフトウェア資産管理（SAM）由来 |
米国NTIA（国家電気通信情報庁）が公表した「SBOMの最低要素（The Minimum Elements For a Software Bill of Materials）」では、サプライヤー名・コンポーネント名・バージョン・一意識別子・依存関係・SBOM作成者・タイムスタンプの7項目を最低限含めることが推奨されています。
実務上の選択
- OSSライセンス遵守を重視 → SPDX
- 脆弱性管理・セキュリティ運用を重視 → CycloneDX
- 既存の資産管理ツールとの連携 → SWID Tag
組織によっては複数フォーマットでの出力をCI/CDパイプラインに組み込むケースもあります。
SBOMの活用領域
1. 脆弱性管理（VEX連携）
SBOMにNVD・GitHub Advisory Database・OSVなどの脆弱性情報を突き合わせることで、自社製品に含まれる既知脆弱性を継続的に把握できます。さらにVEX（Vulnerability Exploitability eXchange）と組み合わせれば、「該当ライブラリは含まれるが、攻撃可能な経路では使われていない」といった文脈情報も伝達できます。
2. OSSライセンスコンプライアンス
GPL系ライセンスを含むコードを商用配布物に混入させると、ライセンス違反となるリスクがあります。SBOMがあれば、配布前にライセンス互換性を機械的にチェックできます。
3. 調達・契約管理
ソフトウェア調達時にベンダーからSBOMの提出を受けることで、自社が間接的に取り込むリスクを事前評価できます。米国では大統領令14028に基づき、連邦政府機関へ納品するソフトウェアにSBOM提出が求められる流れが進んでいます。
4. インシデント対応
新たな脆弱性が公表された際、SBOMリポジトリを横断検索することで、影響を受ける製品・バージョン・顧客を即座に特定できます。「Log4Shellの夜」のような全社調査が不要になります。
国内外の規制・ガイドライン動向
米国：大統領令14028とCISA
2021年5月、バイデン政権は大統領令14028（Executive Order 14028）「国家のサイバーセキュリティ向上に関する大統領令」を発令し、連邦政府向けソフトウェアのセキュリティ強化方針を打ち出しました。これを受けて発出されたOMB M-22-18・M-23-16などにより、連邦政府機関へ納品するソフトウェアにはセキュアソフトウェア開発の自己宣誓（self-attestation）が求められ、必要に応じてSBOM提出が要求される枠組みが整備されつつあります。CISA（米サイバーセキュリティ・インフラセキュリティ庁）はSBOM普及に関するガイダンスを継続的に発行しています。
日本：経済産業省の手引
経済産業省は「ソフトウェア管理に向けたSBOMの導入に関する手引」を公開し、国内企業向けにSBOM導入の意義・手順・運用ノウハウをまとめています。手引はver1.0（2023年7月）から改訂を重ねています。医療機器分野（厚生労働省・PMDA）や自動車分野（JASPAR等）でもSBOM活用の取り組みが進められています。
EU：CRAサイバーレジリエンス法
EUのCyber Resilience Act（CRA）は、デジタル製品のサプライチェーンセキュリティに関する要求事項を整備しており、SBOMの整備・脆弱性対応プロセスの義務化が含まれます。EU市場へ製品を提供する事業者には実質的な対応負荷が生じます。
SBOM導入のステップ
ステップ1：生成対象と範囲を決める
まずは「どの製品・どのリポジトリに対してSBOMを生成するか」を決めます。社内ツール・SaaS・組み込み機器など、組織内のソフトウェア資産は多岐にわたるため、リスクの高いものから段階的に始めるのが現実的です。
ステップ2：生成ツールをCI/CDに組み込む
SBOM生成は手作業ではなく、CI/CDパイプラインに組み込んで自動化します。代表的なOSSツールには Syft、CycloneDX CLI、SPDX SBOM Generator などがあります。ビルドのたびにSBOMを生成・保存することで、リリースごとの差分追跡が可能になります。
ステップ3：脆弱性スキャンとの連携
生成したSBOMを Grype、OSV-Scanner、Trivy などの脆弱性スキャナにかけ、含まれるコンポーネントの既知脆弱性を継続的にチェックします。CI失敗条件（重大度Highの脆弱性検出時にブロック）を組み合わせると、シフトレフトが実現できます。
ステップ4：SBOMリポジトリで一元管理
製品×バージョンごとにSBOMを蓄積するリポジトリを構築します。新たな脆弱性が公表された際、横断検索することで影響範囲を即座に特定できる体制を整えます。
ステップ5：調達・取引先との連携
社内だけでなく、取引先・OSSコミュニティから受け取るSBOMの取り扱いポリシーも整備します。SBOMの「受け取り側」としての運用も同等に重要です。
SBOMだけでは解決しない課題
SBOMはあくまで「可視化」の手段であり、それ自体が脆弱性を修正するわけではありません。以下の運用が伴って初めて効果を発揮します。
- 脆弱性が見つかったコンポーネントの更新運用（パッチ適用・代替ライブラリ移行）
- VEXによる文脈情報の付与（含まれているが影響を受けない、を伝達）
- 依存関係の継続的な棚卸し（不要な依存を減らす）
- アクセス管理・開発者アカウント保護（メンテナアカウント乗っ取り対策）
特に最後の点は、SBOMの精度がいくら高くても「悪意ある変更が公式リポジトリに混入してしまう」攻撃には別レイヤーの防御が必要であることを意味します。
LOCKEDサービスとの関係
SBOM自体はソフトウェア開発・調達プロセスのツールですが、その運用を支えるアイデンティティ管理は別レイヤーで必要です。LOCKED MSOによるSSO・MFA統合は、開発者アカウントやリポジトリ管理者アカウントが乗っ取られるリスクを低減します。LOCKED ATPによる標的型フィッシング訓練は、開発者を狙ったソーシャルエンジニアリング（OSSメンテナ乗っ取りの起点になりやすい）に対する組織耐性を高めます。
LOCKEDの詳細を見る サプライチェーンセキュリティの土台となるアイデンティティ管理・標的型攻撃対策はLOCKEDにご相談ください。 資料請求・デモ依頼はこちら →
まとめ：SBOMはサプライチェーン攻撃時代の前提インフラ
| ポイント | 内容 |
|---|---|
| SBOMとは | ソフトウェアに含まれるコンポーネント・依存・ライセンスを機械可読に記述したドキュメント |
| 主要フォーマット | SPDX（ライセンス強み）／CycloneDX（セキュリティ強み）／SWID Tag（資産管理） |
| 主な用途 | 脆弱性影響範囲の即時特定／OSSライセンス遵守／調達リスク評価／インシデント対応 |
| 規制動向 | 米EO14028、経産省手引、EU CRAなどで実質的な義務化が進行 |
| 限界 | 可視化のみ。更新運用・VEX・アカウント保護と組み合わせて初めて機能する |
「自社製品に何が入っているか分からない」状態は、もはや経営リスクです。SBOMはそのリスクを定量化・可視化するための前提インフラとして位置付けるべきです。
参考資料・関連機関
- 経済産業省：ソフトウェア管理に向けたSBOMの導入に関する手引（v2.0プレスリリース）
- IPA（情報処理推進機構）：サプライチェーンリスクマネジメント
- NTIA：The Minimum Elements For a Software Bill of Materials (SBOM)
- CISA：Software Bill of Materials (SBOM)