このテーマを取り上げる理由
2026年4月、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）は1週間足らずで9件の既知悪用脆弱性をカタログに追加しました。BomgarのRMM製品を狙ったサプライチェーン攻撃の急増も報告されています。こうした動向は「自分たちのシステムに何が含まれているか」を即座に答えられる体制の重要性を改めて示しています。その基盤となるのがSBOM1（Software Bill of Materials：ソフトウェア部品表）です。
基本：何を解決する技術か
SBOMとは、ソフトウェアを構成するコンポーネント・ライブラリ・依存関係を機械可読な形式で一覧化した「部品表」です。製造業の部品表になぞらえた概念で、米国では大統領令14028（2021年）を機に政府調達要件として組み込まれ、日本でもIPA・経済産業省が導入指針を公表しています。
SBOMが解決する中心的な課題は脆弱性の影響範囲の特定速度です。新たなCVEが公開された際に「自社製品・インフラに該当コンポーネントが含まれるか」を数時間ではなく数分で判定できるようになります。Log4Shell（2021年12月のJavaライブラリ脆弱性）やXZ Utils（2024年3月のLinux圧縮ライブラリ侵害）のような広域インシデントでは、SBOMの有無がトリアージ工数に数倍の差をもたらすことが実務で示されています。
主な機能要素／構成要素
SBOMエコシステムは大きく「生成」「管理・流通」「活用」の3層で構成されます。
生成ツール（ジェネレーター）
- Syft（Anchore製OSS）: コンテナイメージ・ファイルシステムからSPDX2・CycloneDX3形式のSBOMを生成する。コマンド例:
syft dir:./app -o cyclonedx-json - cdxgen（OWASP）: 多言語対応のCycloneDX生成ツール。CI/CDパイプラインへの組み込みが容易。
- Trivy（Aqua Security製OSS）: 脆弱性スキャナーとしても使われるが、SBOM生成モードも備える。
フォーマット標準
- SPDX（Linux Foundation）: ライセンス管理に強み。ISO/IEC 5962として国際標準化されている。
- CycloneDX（OWASP）: セキュリティユースケースに最適化。VEX4（Vulnerability Exploitability eXchange）との親和性が高い。
管理・活用プラットフォーム
- Dependency-Track5（OWASP製OSS）: SBOMの継続的な脆弱性監視とダッシュボードを提供。Dockerで30分程度で立ち上げられる。
- 商用SaaS製品: CI/CD統合・ポリシー適用・エクスポートAPIを備えた製品が増加傾向にある（2026年時点）。
導入を検討する際の評価観点
1. 対応フォーマット: 社内ツールチェーンがSPDXとCycloneDXのどちらを要求するか確認します。両対応が望ましいといえます。
2. 生成タイミング: ビルド時（精度高）、デプロイ時（CI/CD統合しやすい）、実行時（動的ライブラリを捕捉可能）で採取粒度が異なります。
3. 言語・エコシステムカバレッジ: Java・Go・Pythonは対応が広いものの、独自ビルドシステムや組み込みC/C++環境では別途確認が必要です。
4. VEXとの連携: SBOMが「何が含まれるか」を示すのに対し、VEXは「その脆弱性が実際に影響するか」を表明する文書です。セットで運用できると誤検知対応の工数が減ります。
5. 既存の脆弱性管理ツールとの統合: Jira・ServiceNow・SIEMプラットフォームへのアラート連携が自動化できるかを確認します。
6. SBOMの保管・バージョン管理: 成果物リポジトリ（Artifactory・Harborなど）と統合し、コンテナイメージやリリースタグに紐付けられるかを確認します。
7. ライセンスコンプライアンス: セキュリティと並行してOSSライセンスの確認にも活用できると工数削減につながります。
よくある落とし穴
- 「一度作ればよい」という誤解: SBOMは依存関係が変わるたびに陳腐化します。リリースパイプラインの中で自動生成・自動更新する仕組みを組み込まないと、いざという時に古いSBOMで判断してしまうリスクがあります。
- 推移的依存関係の見落とし: 直接依存するライブラリだけを記録し、そのライブラリが依存するコンポーネント（推移的依存）を含めないと、脆弱性の影響範囲を見誤ります。ツール選定時は「深さ」まで対応しているか確認することが必要です。
- コンテナ外の資産がスコープ外になる: コンテナイメージのSBOMは整備されていても、スクリプトや設定ファイルに埋め込まれたバイナリ、あるいはファームウェアが管理対象外になるケースがあります。Siemens Industrial EdgeやZero Motorcyclesのファームウェアに関するICS勧告が相次いでいる現状を踏まえると、OT・IoT領域への拡張も視野に入れることが重要です。
一枚要約
- 何が起きているか: SBOMはソフトウェア部品表として標準化が進み、規制対応にとどまらずSOC初動の必須ツールに位置づけが変わりつつある。
- 自社への影響: 新規CVE公開時に自社の影響範囲を数時間ではなく数分で判定できる体制を持つかどうかが、対応コスト・規制対応の差として現れる。
- 打つべき手: まずは最重要成果物1本でSyft＋Dependency-Trackの最小構成を試行し、生成・突合・更新の運用感を掴むことから始めるのが現実的といえます。
今日着手できる3アクション
- 最重要成果物1本でSBOMを生成する: 自社で最もリスクの高い成果物（顧客向けAPIサーバ・主要Webアプリのコンテナイメージなど）を選び、
SyftまたはTrivyを使ってsyft dir:./app -o cyclonedx-jsonのように1コマンドで生成します。生成時間と出力サイズを記録すると後続の運用判断に役立ちます。 - Dependency-Trackで脆弱性突合を試す: OWASP公式Dockerイメージで30分程度に立ち上げ、生成したSBOMをアップロードしてCVE突合のダッシュボードを確認します。誤検知率と未対応CVE件数を初期値として記録します。
- CISA KEVカタログとの突合手順を文書化する: 過去90日のCISA Known Exploited Vulnerabilities（https://www.cisa.gov/）を抽出し、社内SBOMとの突合手順を1ページに整理します。インシデント発生時のスコーピング短縮効果を試算しておくと、稟議の根拠資料にも転用できます。
AI×セキュリティの観点
AIコーディング支援（GitHub Copilot等）の普及で、開発者が無意識にOSS依存を増やすケースが増えており、SBOMの重要性は加速度的に高まっています。攻撃側もAIで脆弱性発見・PoC生成を高速化しており、防御側はSBOM＋VEX＋自動アラートのパイプラインで対応速度を上げる必要があります。EU AI Actやサイバーレジリエンス法（CRA）はAIシステム自体のSBOM相当を要求する方向で議論が進んでおり、AI×ソフトウェア透明性は規制の次の焦点になるテーマといえます。
用語ミニ解説
- SBOM — Software Bill of Materialsの略。ソフトウェアの部品表で、コンポーネント・バージョン・ライセンス・依存関係を機械可読形式で一覧化する。米国大統領令14028で標準化が加速した。 ↩
- SPDX — Linux Foundationが開発したSBOMフォーマット。ライセンス情報の表現に強く、ISO/IEC 5962として国際標準化されている。 ↩
- CycloneDX — OWASPが開発したSBOMフォーマット。セキュリティユースケースに最適化されており、VEXとの親和性が高い。 ↩
- VEX — Vulnerability Exploitability eXchangeの略。「脆弱性が含まれていても実際に攻撃可能か」を表明する文書。SBOMと組み合わせて誤検知対応の工数を削減する。 ↩
- Dependency-Track — OWASP製のSBOM管理プラットフォーム。継続的脆弱性監視とダッシュボード機能を備え、OSSとして広く使われている。 ↩
コメント