Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
SolarWinds事件以降、ソフトウェアサプライチェーンは「信頼の連鎖」を前提にできない領域になりました。攻撃者はアプリケーション本体だけでなく、その依存先、ビルドパイプライン、パッケージレジストリ、更新配布の仕組みといった上流を狙います。
SBOM（Software Bill of Materials）は、こうした見えにくい依存関係を可視化し、CVE発生時に「自社のどの製品・コンテナ・バージョンに影響があるのか」を迅速に特定するための基盤です。
本記事では、SBOMの定義から、SPDX／CycloneDXなどの代表的フォーマット、VEXによる優先度設計、CI/CDへの組み込み、OSSライセンス管理までを、シフトレフトの中核実装として体系的に整理します。
1. なぜ今、サプライチェーンセキュリティが急務なのか
過去数年で、ソフトウェアサプライチェーンを狙った攻撃が繰り返し発生しています。共通しているのは、攻撃者が「自社が直接書いたコード」ではなく、その周辺にある依存関係や開発・配布プロセスを狙っている点です。
1-1. SolarWinds／Log4j／3CX／XZ Utilsに見る攻撃の変化
SolarWinds OrionのSunburstバックドアは、正規の署名付きアップデートを通じて、多数の組織に配布されました。攻撃者は最終製品そのものではなく、ビルド環境や配布プロセスを侵害した点が特徴です。
Log4jの脆弱性、いわゆるLog4Shellでは、広範なJavaアプリケーションに間接依存として組み込まれていたライブラリの欠陥が、リモートコード実行につながりました。多くの組織が「自社のどの製品・どのコンテナにLog4jが含まれているのか」を即座に把握できず、影響調査に多くの時間を要しました。
3CXの事例では、正規のデスクトップ通話アプリのアップデートが侵害され、上流の開発元から下流の利用企業へ攻撃が波及しました。XZ Utilsのバックドア事例では、OSSプロジェクトに長期的に関与して信頼を獲得した人物が、広く利用されるライブラリに悪意あるコードを混入させた点が大きな衝撃を与えました。
これらの事例は、ソフトウェアの信頼性を「配布元が正規であること」だけでは判断できない時代になったことを示しています。
1-2. npm event-stream／Codecov／Typosquattingに見る依存攻撃の常態化
大規模な国家レベルの攻撃だけが問題ではありません。日常的な開発で使われるOSSパッケージやCIツールも、サプライチェーン攻撃の入口になり得ます。
npm event-streamでは、人気パッケージのメンテナ権限が悪意あるユーザーに渡り、間接依存に不正コードが混入しました。Codecov Bash Uploaderでは、CIで実行されるアップロードスクリプトが改ざんされ、顧客のCI環境変数やクラウド認証情報が外部に送信されました。
また、PyPIやnpmでは、人気パッケージ名に似せたTyposquattingパッケージも継続的に確認されています。開発者がわずかに名前を打ち間違えるだけで、悪意あるパッケージを取り込んでしまう可能性があります。
これらに共通するのは、「自分たちが書いていないコード」が日常的な開発・ビルド・デプロイの流れに入り込み、本番環境まで到達し得るという点です。
1-3. 規制・調達要件としても重要性が高まるSBOM
SBOMは、セキュリティ上のベストプラクティスにとどまらず、規制や調達要件の文脈でも重要性を増しています。
米国では大統領令14028を契機に、連邦政府調達ソフトウェアにおけるSBOMの提出・活用が注目されるようになりました。NTIAはSBOMの最小要素を定義し、ソフトウェアの構成要素を機械可読な形で把握する取り組みを後押ししています。
EUのCyber Resilience Actでも、デジタル要素を持つ製品に対して、脆弱性管理や構成コンポーネントの把握が求められています。日本国内でも、経済産業省がSBOM導入に関する手引きを公開・改訂しており、医療機器や自動車などの分野で先行的な活用が進んでいます。
つまりSBOMは、「導入した方がよい取り組み」から、ソフトウェアの説明責任を果たすための基盤へと位置づけが変わりつつあります。
2. SBOMとは何か — Software Bill of Materialsの定義
SBOM（Software Bill of Materials）は、ソフトウェアを構成する部品表です。アプリケーションに含まれるOSSライブラリ、パッケージ、バージョン、ライセンス、依存関係などを、機械可読な形式で記録します。
2-1. 「ソフトウェアの部品表」という考え方
製造業では、1台の自動車にどの部品が使われ、どのサプライヤから供給され、どのロットに属しているかを管理します。リコールが発生した際には、この部品表をもとに影響範囲を特定します。
SBOMは、この考え方をソフトウェアに適用したものです。現代のアプリケーションは、数百から数千のOSSコンポーネントや外部ライブラリによって構成されています。どのライブラリが、どのバージョンで、どのような依存関係を持って組み込まれているのかを把握できなければ、脆弱性発生時に影響範囲を特定できません。
食品の成分表示に近いと考えることもできます。ある成分に問題が見つかったときに、どの製品に含まれているのかをすぐに確認できる状態を作ることが、SBOMの基本的な役割です。
2-2. SBOMが答える3つの問い
SBOMは、主に次の3つの問いに答えるためのインベントリです。
1つ目は、「何が含まれているか」です。直接依存・間接依存を含むコンポーネント名、バージョン、ハッシュ、ライセンスなどを把握します。
2つ目は、「何に依存しているか」です。コンポーネント同士の依存関係を可視化することで、Log4jのようにn次依存で混入するライブラリも追跡できます。
3つ目は、「何が脆弱か」です。SBOMの構成情報をCVE、OSV、ベンダーアドバイザリなどの脆弱性データベースと突き合わせることで、影響を受ける製品やコンテナイメージを特定できます。
ただし、SBOMそのものは脆弱性スキャナではありません。SBOMはあくまで一次データであり、脆弱性データベースやスキャナと組み合わせることで、実際のリスク判断に活用できます。
2-3. SBOMによって初動対応はどう変わるか
SBOMが整備されていない環境では、新規CVEが公開された際に、依存ライブラリをgrepで探したり、ビルド担当者に確認したり、各チームへSlackで問い合わせたりする対応になりがちです。
一方、SBOMをCI/CDで継続的に生成・蓄積していれば、PURLやCPEを検索キーとして、影響を受ける製品、コンテナイメージ、バージョンを短時間で列挙できます。
Log4j級のインシデントにおいて、「影響範囲の把握に数日かかる状態」から「初期調査を数十分〜数時間で開始できる状態」へ移行できることは、SBOM導入の大きな価値です。
3. SBOMの代表的なフォーマット
SBOMには複数のフォーマットがあります。実務で特に重要なのは、SPDX、CycloneDX、SWIDの3つです。
3-1. SPDX — ライセンス管理に強い標準フォーマット
SPDX（Software Package Data Exchange）は、Linux Foundationが主導するSBOM標準です。ライセンスコンプライアンスを起点に発展してきた経緯があり、ライセンス情報の表現力に強みがあります。
JSON、YAML、RDF、タグバリュー形式などに対応しており、OSSライセンス監査や政府調達向けの提出フォーマットとしても広く利用されています。
3-2. CycloneDX — セキュリティ用途に強いSBOMフォーマット
CycloneDXは、OWASPプロジェクトとして策定されたセキュリティ用途寄りのSBOMフォーマットです。アプリケーションセキュリティの文脈で使いやすく、VEX、SaaSBOM、ML-BOM、Cryptography BOMなどの派生仕様にも対応しています。
Snyk、Trivy、Syftなど、多くの開発・セキュリティツールがCycloneDXに対応しており、CI/CDへの組み込みや脆弱性管理との連携にも向いています。
3-3. SWID — 資産管理寄りの識別タグ
SWID（Software Identification Tag）は、ISO/IECで標準化されたソフトウェア識別タグです。IT資産管理や組み込み機器、Windowsエコシステムなどで利用されることがあります。
SPDXやCycloneDXと比べると、CI/CDやアプリケーションセキュリティ領域での利用は限定的ですが、資産管理やソフトウェア識別の観点では重要な規格です。
3-4. どのフォーマットを選ぶべきか
実務では、セキュリティ運用を主目的とする場合はCycloneDX、ライセンス監査を重視する場合はSPDXを中心に据えるケースが多く見られます。
ただし、どちらか一方だけに固定する必要はありません。SyftやTrivyなどのツールを使えば、同じ成果物からSPDXとCycloneDXの両方を生成できます。提出先や利用目的に応じて複数フォーマットを生成しておく構成が、現実的な運用と言えます。
4. SBOMの生成と運用 — CI/CDへの組み込みパターン
SBOMは、手作業で作成するものではありません。ビルドやリリースのタイミングで自動生成し、成果物と紐づけて管理することが基本です。
4-1. ビルド時にSBOMを生成する
SBOMは、ビルド成果物が確定したタイミングで生成するのが望ましいです。たとえば、コンテナイメージのビルド直後やリリースアーティファクト作成直後です。
代表的なツールには、次のようなものがあります。
Syftは、コンテナイメージ、ファイルシステム、アーカイブからSPDX／CycloneDX形式のSBOMを生成できます。
Trivyは脆弱性スキャナとして広く使われていますが、SBOMの生成やSBOMを入力としたスキャンにも対応しています。
Microsoft SBOM Toolは、SPDX形式のSBOM生成に対応し、Azure Pipelinesなどとの連携に向いています。
Sysdig CLI Scannerは、コンテナイメージスキャンとあわせて、CycloneDX形式でのSBOM抽出と脆弱性情報の出力を支援します。SBOMはCycloneDX JSON形式でAPIまたはSysdig Secure UIからダウンロードできます。
4-2. 生成対象はソースコード、ビルド成果物、コンテナイメージで異なる
SBOMは、どの段階で生成するかによって取得できる情報が変わります。
ソースコードから生成するSBOMは、package.json、go.mod、pom.xmlなどに記載された依存関係を把握できます。ただし、実際にビルドで解決されたバージョンとずれる場合があります。
ビルド時に生成するSBOMは、ビルドツールが解決した依存関係を把握しやすく、アプリケーションの実態に近い情報を得られます。
コンテナイメージから生成するSBOMは、最終的にイメージへ含まれたアプリケーション依存とOSパッケージの両方を把握できます。一方で、ソースコード上の来歴や開発時の文脈は薄くなります。
実務上は、ビルド時のSBOMとコンテナイメージのSBOMを両方生成し、最終的なリリース成果物にはイメージSBOMを紐づける構成が堅実です。
4-3. SBOMをアーティファクトとして管理する
生成したSBOMは、CIジョブの一時ファイルとして残すだけでは不十分です。コンテナイメージやリリース成果物と紐づけ、後から参照できる形で保管する必要があります。
近年は、SBOMをコンテナイメージと同じOCIレジストリにアタッチして保管する運用が広がっています。cosignやorasを使えば、イメージのダイジェストにSBOMを紐づけられます。
さらに、SigstoreやcosignでイメージとSBOMに署名し、KubernetesのAdmission Controlで「署名済みイメージのみ起動を許可する」といったポリシーを適用することも可能です。
4-4. シフトレフト全体におけるSBOMの位置づけ
SBOMの生成・署名・保管は、シフトレフト全体の中では主にビルドステージに位置づけられます。
IDEやコミット段階では、開発者が依存追加やライセンス違反に気づけるようにします。ビルド段階では、実際に解決された依存関係をSBOMとして記録します。デプロイ前には、署名やポリシーゲートを通じて、許可された成果物だけを本番へ進めます。
SBOMは、単なる棚卸しファイルではなく、CI/CD全体におけるセキュリティ判断の入力データとして機能します。
5. VEX — 「検出されたCVEを全部直す」から脱却する
SBOMを導入すると、脆弱性の可視化は進みます。しかし、見つかったCVEをすべて同じ優先度で修正しようとすると、開発チームはすぐに対応しきれなくなります。
そこで重要になるのが、VEX（Vulnerability Exploitability eXchange）です。
5-1. CVEは「該当する脆弱性」、VEXは「悪用可能性」の判断
SBOMと脆弱性データベースを突き合わせると、「このコンポーネントのこのバージョンに、このCVEが該当する」という情報が得られます。
しかし、それだけでは本当に修正が必要かどうかは判断できません。
たとえば、脆弱なコードパスが製品内で呼び出されていない場合があります。設定上、外部から到達できない場合もあります。あるいは、製品側で別の緩和策がすでに実装されている場合もあります。
VEXは、こうした文脈を踏まえ、各CVEに対して「影響あり」「影響なし」「修正済み」「調査中」といった状態を機械可読な形で表明する仕組みです。
5-2. SBOMとVEXを組み合わせて優先度を設計する
SBOMだけでは、該当する脆弱性が大量に列挙されます。特に大規模なコンテナ環境では、CriticalやHighの件数が数百〜数千件に達することもあります。
VEXを併用すると、その中から「製品の実装上は悪用できない」「該当コードパスが使われていない」と判断できるものを、修正優先度の下位に回せます。
これにより、開発チームは「検出されたものをすべて直す」状態から、「悪用可能性が高く、実際に影響があるものから直す」状態へ移行できます。
5-3. ランタイム情報と組み合わせると、さらに優先度を絞り込める
VEXに加えて、本番ランタイムでの実行情報を組み合わせると、優先度判断はさらに現実的になります。
たとえば、脆弱なライブラリがイメージ内に存在していても、本番環境でロードされていない、または実行されていない場合があります。一方で、外部公開されたワークロードで、脆弱なパッケージが実際に使われている場合は、優先度を高く設定すべきです。
このように、SBOMで「含まれているもの」を把握し、VEXで「悪用可能性」を判断し、ランタイム情報で「実際に使われているか」を確認することで、修正対象を現実的な件数に絞り込めます。
6. 依存パッケージの継続監視
SBOMは、生成して終わりではありません。ビルド時点では安全だったコンポーネントに、後日CVEが公開されることは珍しくありません。そのため、SBOMは継続監視の入力データとして活用する必要があります。
6-1. Dependabot／Renovate／OSV-Scannerとの連携
依存パッケージの継続監視には、Dependabot、Renovate、OSV-Scannerなどを組み合わせる構成が一般的です。
Dependabotは、主にGitHub上の依存マニフェストをもとに、脆弱性修正やバージョン更新のPRを自動生成します。Renovateは、より細かなスケジューリングやルール設定に対応しており、モノレポや複数言語のリポジトリでも柔軟に運用できます。OSV-Scannerは、OSV.devの脆弱性データベースと連携し、依存関係やSBOMを入力としてスキャンできます。ビルド時に生成したSBOMを保管しておけば、後日公開されたCVEに対して、過去のリリース成果物を再スキャンできます。
6-2. 新規CVE発生時のトリアージワークフロー
新規CVEが公開された際には、まず該当するPURLやCPEを特定します。次に、保管済みのSBOMインベントリを横断検索し、影響を受ける製品、コンテナイメージ、バージョンを列挙します。
そのうえで、VEXやランタイム情報を使って悪用可能性を評価し、対応が必要なものを優先順位づけします。修正が必要な場合は、パッチ適用、依存バージョン更新、ワークアラウンド適用、リリース差し替えなどを実施します。
この流れのうち、影響範囲の初期特定を人手の棚卸しから機械的な検索へ置き換えられることが、SBOM導入の大きなROIです。
7. OSSライセンスのコンプライアンス管理
SBOMは、脆弱性管理だけでなく、OSSライセンス管理にも活用できます。
7-1. ライセンスリスクをビルド前に把握する
OSSライセンスには、MIT、Apache 2.0、BSDのように商用利用しやすいものもあれば、GPL、LGPL、AGPLのように利用形態によって注意が必要なものもあります。特にGPLやAGPLは、配布形態やネットワーク提供の形態によって、ソースコード開示義務が問題になる場合があります。商用プロダクトにこれらのライセンスが意図せず混入すると、リリース直前や監査時に大きな手戻りが発生します。
7-2. SBOMをライセンスインベントリとして使う
SPDXは、各コンポーネントのライセンス情報を構造化して保持できます。そのため、SBOMはライセンスインベントリとしても機能します。CIで「禁止ライセンスを含む場合はビルドを失敗させる」「特定ライセンスを含む場合は法務レビューに回す」といったポリシーを設定すれば、リリース前にライセンスリスクを検知できます。従来、OSSライセンス監査は年1〜2回の棚卸しとして実施されることが多くありました。しかし、SBOMをCIで継続的に生成・蓄積しておけば、リリースごとのライセンス差分監査も現実的になります。
8. SBOM運用の役割分担とSLA
SBOMを導入するだけでは、運用は回りません。誰がSBOMを生成し、誰がVEX判定を行い、誰が修正期限を決め、誰が顧客や運用部門へ説明するのかを決める必要があります。たとえば、PlatformチームはCI/CDへのSBOM生成・署名・保管の仕組みを整備します。Securityチームは脆弱性データベースとの突合、VEX判定ルール、ポリシーゲートを設計します。Devチームは、実際の依存更新や修正PRへの対応を担います。
また、CriticalやHighの脆弱性について、どの条件で何日以内に修正するのか、VEXで「not affected」と判断する場合にどのような根拠を残すのか、といったSLAも必要です。この役割分担と基準が整って初めて、SBOMは技術的なファイルであると同時に、DevSecOpsの運用プロセスを支える共通言語でもあります。
9. Sysdig SecureによるSBOM／サプライチェーンセキュリティ支援
SBOMは、生成・保管・再スキャン・優先度判断まで含めた運用プロセスとして機能して初めて価値を発揮します。ここでは、Sysdig Secureがこのライフサイクルをどのように支援するかを整理します。
9-1. SBOM生成と脆弱性マッピング
Sysdig Secureは、CI/CDパイプライン上でのコンテナイメージスキャンを通じて、SBOMや脆弱性情報の可視化を支援します。イメージに含まれるパッケージやライブラリを把握し、脆弱性データベースと突き合わせることで、どのイメージにどのリスクが含まれているかを確認できます。CI/CDへの組み込みにより、リリース前の段階でリスクを検出し、ポリシーに基づいてビルドやデプロイを制御する運用も可能になります。
9-2. Runtime Insightsとの統合による優先度づけ
Sysdig Secureの特徴は、ビルド時の脆弱性情報をランタイムの実行状況と接続できる点にあります。コンテナイメージに含まれる脆弱性のうち、本番環境で実際に使われているパッケージや、外部公開されたワークロードに関係するものを優先的に確認できます。これにより、単にCVSSや重大度だけで並べるのではなく、実際の使用状況に基づいて「本当に対応すべきリスク」を絞り込めます。
SBOMや脆弱性スキャンは、シフトレフトの入口です。そこにランタイムの文脈を組み合わせることで、開発・セキュリティ・運用の各チームが、同じリスク情報をもとに優先順位を判断しやすくなります。
10. まとめ — SBOMはシフトレフトを機能させる基盤である
SBOMは、SolarWinds以降のサプライチェーン攻撃や、Log4Shell級の影響範囲特定の難しさに対して、現時点で最も実装が進んでいる対策の一つです。SPDXやCycloneDXでSBOMを自動生成し、VEXで悪用可能性を判断し、DependabotやOSV-Scannerで継続監視し、Sigstoreなどで署名・検証する。この一連の流れをCI/CDに組み込むことで、「依存先が見えない」という根本的な課題を構造的に小さくできます。
ただし、SBOMだけですべてのサプライチェーンリスクを解決できるわけではありません。ビルド時に正確な依存関係を把握すること、ランタイムで実際に使われているコードを確認すること、組織としてRACIやSLAを設計すること。この3つが揃って初めて、シフトレフトは実効性を持ちます。SBOMは、単なるコンプライアンス対応のためのファイルではありません。開発スピードを落とさずに、サプライチェーンリスクへ継続的に備えるための、DevSecOpsの中核実装です。