Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
SolarWinds事件以降、ソフトウェアサプライチェーンは「信頼の連鎖」が前提では成り立たない領域となりました。攻撃者はアプリケーション本体ではなく、その依存先・ビルドパイプライン・パッケージレジストリといった上流を狙います。SBOM（Software Bill of Materials）は、この見えない依存関係を可視化し、CVE発生時に「自社で影響があるのはどこか」を即答するための基盤です。本記事は、SBOMの定義からSPDX／CycloneDXフォーマット、VEXによる優先度設計、CI/CDへの組み込み、OSSライセンス管理までを、シフトレフトの中核実装として体系的に整理します。
なぜ今、サプライチェーンセキュリティが急務か
過去数年で連続して発生したサプライチェーン攻撃を整理し、「依存関係の信頼」がもはや既定値ではないことを確認します。
SolarWinds（2020）／Log4j（2021）／3CX（2023）／XZ Utils（2024）の系譜
SolarWinds Orion（2020年）の Sunburst バックドアは、正規の署名付きアップデート経由で米連邦政府を含む数千組織に配布されました。攻撃者は最終製品ではなく、ビルドサーバそのものを侵害しています。
Log4j（2021年12月、CVE-2021-44228／Log4Shell）は、ほぼあらゆるJavaアプリケーションに間接依存として埋め込まれていたロギングライブラリの欠陥が、リモートコード実行に直結した事例です。多くの組織が「自社プロダクトのどの製品・どのコンテナにLog4jが含まれるか」を即答できず、棚卸しに数週間を要しました。
3CX（2023年）はデスクトップ通話アプリの正規アップデートが侵害された二段階サプライチェーン攻撃で、上流の開発元（Trading Technologies）の侵害から下流へ波及しました。XZ Utils backdoor（2024年3月、CVE-2024-3094）は、Linuxディストリビューションに広く採用される圧縮ライブラリへ、長期間にわたり貢献者として信頼を獲得した人物がバックドアを混入させた事例で、OSSメンテナンスモデルそのものの脆弱性を露呈しました。
npm event-stream／Codecov／PyPI Typosquatting — 依存攻撃の常態化
エンタープライズ向けの大型事件だけが問題ではありません。npm event-stream（2018年）は、人気パッケージのメンテナ権限が悪意あるユーザーに譲渡され、間接依存に暗号資産窃取コードが混入した事例です。Codecov Bash Uploader（2021年）はCIで実行されるアップロードスクリプトが書き換えられ、顧客のCI環境変数（クラウド認証情報含む）が外部送信されました。PyPI／npmにおけるTyposquatting（reqeusts／colourama等、人気パッケージ名のtypoを狙うマルウェアパッケージ）も日常的に検出され続けています。
これらに共通するのは、「自分が書いていないコード」が本番に流れ込み、しかもその流路が日常運用に溶け込んでいる点です。
規制側の動き — 米国大統領令14028／EU CRA／日本のソフトウェア管理に関する手引き
規制は急速に追随しています。米国大統領令14028（2021年5月）は連邦政府調達ソフトウェアにSBOM提出を義務付け、NTIAが最小要素（Minimum Elements）を定義しました。EU Cyber Resilience Act（CRA、2024年成立）は域内市場で販売される「デジタル要素を持つ製品」にSBOMと脆弱性管理プロセスを要求しています。日本国内でも経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引き」が改訂を重ね、医療機器・自動車分野での先行採用が進んでいます。
つまりSBOMは、「やった方がよい」段階を過ぎて「ない状態が説明責任を欠く」段階に入っています。
SBOMとは何か — Software Bill of Materialsの定義
SBOMという概念をエンジニアリング視点で定義し直します。
「ソフトウェアの部品表」というメタファ
SBOM（Software Bill of Materials）は、製造業における「部品表（BOM）」をソフトウェアに適用した概念です。1台の自動車に何千個の部品が組み込まれ、それぞれの製造元・ロット番号・サプライヤがどこかを管理しなければリコールが成立しないのと同じく、現代のアプリケーションも数百〜数千のOSSコンポーネントから構成されており、その内訳を構造化データとして保持する必要があります。
食品の成分表示に近いという説明も有効です。アレルギー物質（＝既知脆弱性）が判明したときに、「どの製品にどれだけ含まれているか」を即座に追跡できる前提が、出荷側にも消費者側にも求められます。
SBOMが解決する3つの問い（何が含まれるか／何に依存するか／何が脆弱か）
SBOMは、概ね次の3つの問いに答えるためのインベントリです。
何が含まれるか（Composition）：直接依存・間接依存を含む全コンポーネントの名前・バージョン・ハッシュです。
- 何に依存するか（Dependency Graph）：コンポーネント間の依存関係です。Log4j のようにn次依存で混入するライブラリも追跡できます。
- 何が脆弱か（Vulnerability Mapping）：各コンポーネントを既知CVE／OSVデータベースと突き合わせ、影響範囲を即時に算出します。
SBOMそのものは脆弱性スキャナではありませんが、スキャナとマッピングするための一次データを提供します。
SBOMの登場で何が変わったか
SBOM以前は、CVE発生時の初動が「grepで依存ライブラリのバージョンを探す」「ビルド担当者にSlackで聞く」といった属人的な作業に依存していました。SBOMが整備されたパイプラインであれば、新規CVEのPURL（Package URL）またはCPEを検索キーとして、影響を受ける製品・コンテナイメージ・バージョンを分単位で列挙できます。Log4j級のインシデントで「対応開始まで数日」から「数十分」への短縮が現実的になった意義は、決して小さくありません。
SBOMの代表的なフォーマット
SBOMフォーマットの主要3規格を整理します。
SPDX（Linux Foundation）
SPDX（Software Package Data Exchange、ISO/IEC 5962:2021）はLinux Foundationが主導する標準で、ライセンスコンプライアンスを起点に発展してきた経緯から、ライセンス記述の表現力が高いという特徴があります。JSON・YAML・RDF・タグバリュー形式に対応しており、米国NTIAのSBOM最小要素を満たす実装として、連邦政府調達ではデファクトに近い位置を占めています。
{
"spdxVersion": "SPDX-2.3",
"name": "example-app",
"packages": [{
"name": "log4j-core",
"versionInfo": "2.14.1",
"licenseConcluded": "Apache-2.0",
"externalRefs": [{"referenceType": "purl",
"referenceLocator": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"}]
}]
}CycloneDX（OWASP）
CycloneDX はOWASPが策定するセキュリティ用途寄りのSBOM規格です。SBOMだけでなく、VEX（後述）、SaaSBOM、ML-BOM、Cryptography BOM など派生仕様を同一スキーマで扱える点が特徴で、開発ツール側（Snyk、Trivy、Syft等）の対応も広がっています
<bom xmlns="http://cyclonedx.org/schema/bom/1.5" version="1">
<components>
<component type="library" purl="pkg:npm/lodash@4.17.20">
<name>lodash</name><version>4.17.20</version>
</component>
</components>
</bom>SWID（ISO/IEC 19770-2）
SWID（Software Identification Tag）はISO/IECで標準化された資産管理寄りのタグ規格で、Windowsエコシステムや組み込み機器のインベントリ管理で採用が見られます。SPDX／CycloneDXに比べCI/CD連携ツールは限定的ですが、相互変換のリファレンス実装がNIST等から提供されています。
どれを選ぶべきか — ツールチェーンとの互換性視点
実務的には、セキュリティ運用主体ならCycloneDX、ライセンス監査主体ならSPDXを一次フォーマットに据え、相互変換ツール（cyclonedx-cli convert等）で他方も生成する構成が多く見られます。両方を生成するコストは小さいため、提出先の指定に応じて使い分けるのが現実的です。
SBOMの生成と運用 — CI/CDへの組み込みパターン
SBOMをCI/CDに組み込み、アーティファクトとして管理するパターンを紹介します。
Build時生成（Syft・Trivy・Sysdig CLI等）
SBOM生成は、ビルド成果物が確定するタイミング（コンテナイメージビルド直後、リリースアーティファクト作成直後）で行うのが基本です。代表的なツールは以下のとおりです。
- Syft（Anchore）：コンテナイメージ・ファイルシステム・アーカイブからSPDX／CycloneDX形式のSBOMを生成します。
- Trivy（Aqua Security）：脆弱性スキャナですが、trivy sbom でSBOM出力にも対応しています。
- Microsoft SBOM Tool：SPDX形式の生成に対応し、Azure Pipelinesと連携できます。
- Sysdig CLI（sysdig-cli-scanner）：イメージスキャンと併せて、SBOMや脆弱性情報を出力します。
Syftによる基本例は次のとおりです。
syft packages registry.example.com/api:v1.4.2 \
-o cyclonedx-json=sbom.cdx.json \
-o spdx-json=sbom.spdx.jsonContainer Image vs Sourceコード vs Binary
SBOM生成の対象は、段階によって異なります。
実用上は、ビルド時のSBOMとコンテナイメージのSBOMを両方生成し、後者を最終アーティファクトに付随させる構成が堅実です。
アーティファクト管理（OCIレジストリへの保管／署名・Sigstore）
生成したSBOMをコンテナイメージと同じOCIレジストリにアタッチして保管する流れが、近年定着しつつあります。cosign attach sbom や oras attach を使えば、イメージのダイジェストにSBOMを紐付けられます。あわせてSigstore（cosign）でイメージとSBOMを署名し、Kubernetes admissionで「署名付きイメージのみ起動許可」を強制することも可能です。
cosign attach sbom --sbom sbom.cdx.json \
registry.example.com/api@sha256:abc...
cosign sign --key cosign.key \
registry.example.com/api@sha256:abc...シフトレフト全体での位置付け
SBOMの生成や署名は、シフトレフト全体（IDE → コミット → ビルド → デプロイ）の「ビルド」ステージに該当します。CI/CD全体（4ステージ）の俯瞰と各ステージの実装パターンは、所属ハブのシフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイドをご参照ください。本記事は、その中の「ビルド段階＝SBOM」部分の深掘りに集中します。
GitHub Actions への組み込み例を以下に示します。
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
image: registry.example.com/api:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Attach & Sign
run: |
cosign attach sbom --sbom sbom.cdx.json $IMAGE
cosign sign --yes $IMAGEVEX（Vulnerability Exploitability eXchange）— 「全部直さない」前提
SBOMから列挙される脆弱性をすべて修正することは現実的ではなく、「悪用可能性」で絞り込む仕組みが必要になります。
CVEは検出された脆弱性／VEXは「悪用可能か」の判断
SBOMと脆弱性データベースの突合で得られるのは、「コンポーネントXのバージョンYにCVE-Zが該当する」という事実までです。しかし実際には、
- 該当コードパスが製品で呼ばれていない（dead code）
- 設定上、外部からアクセスできない
- ベンダー側で別の緩和策がすでに実装されている
といったケースが大量に存在します。VEX（Vulnerability Exploitability eXchange）は、各CVEに対して製造側が「悪用可能（affected）／悪用不可（not_affected）／修正済み（fixed）／調査中（under_investigation）」を機械可読な形式で表明する仕組みです。CycloneDX VEX、OpenVEX、CSAF VEX といった実装があります。
CycloneDX VEX の例を以下に示します。
{
"vulnerabilities": [{
"id": "CVE-2021-44228",
"analysis": {
"state": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"detail": "log4j-coreは内包するがJNDIルックアップを呼ぶコードパスは存在しない"
},
"affects": [{"ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"}]
}]
}SBOM × VEX による優先度設計
VEXを併用すると、SBOMから出る「数百〜数千件のCritical」のうち、製造側が悪用不可と表明した分を除外できます。残った件数のみが、実際に修正計画の対象となります。これにより、開発チームは「全部直さなければならない」というプレッシャーから解放され、本当に対応すべきものに集中できるようになります。
ランタイム情報との掛け合わせで本当に直すべき件数を絞る
VEXに加えて、本番ランタイムでの実コードパス実行情報（どのライブラリが実際にロード／呼び出されているか）を掛け合わせると、Critical件数を桁違いに削減できます。この掛け合わせの仕組み（カーネル経由のロード検知やIn-Use判定）と具体的な削減数値については、コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組みで詳しく解説しています。本記事ではビルド段階のVEX判定までを扱い、ランタイム情報との連携は当該記事をあわせてご参照ください。
依存パッケージの継続監視
SBOM生成後の「継続監視」フェーズについて整理します。
Dependabot／Renovate／OSV連携
SBOMはビルド時点のスナップショットでしかなく、CVEは後から発見されるものです。継続監視のためには、次のようなツールを組み合わせる構成が一般的です。
- Dependabot（GitHub）：依存マニフェスト（package.json、go.mod など）に基づいてPRを自動生成します。
- Renovate（Mend）：より細かいスケジューリングや、モノレポ構成にも対応します。
- OSV-Scanner（Google）：OSV.devデータベースに対するスキャナで、SBOM（SPDX／CycloneDX）を直接入力に取ることができます。
OSV-Scanner はSBOMファイルを引数に取れるため、ビルド時のSBOMを成果物として保管しておけば、後日でも同じスナップショットに対して再スキャンを実施できます。
osv-scanner --sbom=sbom.cdx.json新規CVE発生時のリスクトリアージ・ワークフロー
新規CVEが公開された際の標準的なワークフローは、おおむね次のようになります。
- CVE → 該当するPURL／CPEを特定します。
- SBOMインベントリを横断検索し、影響を受ける製品・コンテナ・バージョンを列挙します。
- VEX判定（悪用可能性の評価）を実施し、対応要否を決定します。
- 対応が必要なものについて、修正PR・パッチリリース・ワークアラウンド適用のいずれかで対処します。
- 修正後、VEX文書を更新して顧客や運用側へ配布します。
この一連の流れが「人手の調査」から「クエリ1本」に置き換わることこそ、SBOM導入における最大のROIだといえます。
OSSライセンスのコンプライアンス管理
この章では、SBOMをライセンス監査の証跡として活用する観点を整理します。
GPL／Apache／MIT等の代表的ライセンスとリスク
特にAGPLとGPLは、商用配布時のソース公開義務がプロダクト設計に直結するため、ビルド前の段階で混入を検知しておくことが望ましいといえます。
SBOMをライセンスインベントリとして活用
SPDX は licenseConcluded フィールドに各コンポーネントのライセンスを保持するため、SBOMはそのままライセンスインベントリとしても機能します。CI で「禁止ライセンスを含むビルドはfail」とするポリシーゲートを設けておくことで、AGPLの混入を出荷前の段階で防ぐことができます。FOSSA、ScanCode、Syft の --source-version-format などで抽出が可能です。
ライセンス監査は通常、年1〜2回の棚卸し作業として実施されてきましたが、SBOMをCIで生成・蓄積しておけば、リリースごとの差分監査も現実的なものとなります。
SBOM運用の役割分担とSLA
SBOMやVEX判定・修正・公開の役割分担は、Plat / Sec / Dev 三者の合意が前提となります。「誰がVEX判定を出すか」「Criticalの修正期限をどう設定するか」「In-Use判定をどの段階で挟むか」といった RACI と SLA の具体的な設計指針については、DevSecOpsとコンテナセキュリティで詳しく解説しています。本記事では「SBOMという技術コンポーネントの実装」に焦点を絞っていますので、運用ガバナンスについては当該記事をあわせてご参照ください。
Sysdig SecureのSBOM／サプライチェーンセキュリティ機能
Sysdig Secure がSBOMライフサイクルをどのように支援するかを、実装の観点で整理します。
SBOM自動生成・脆弱性データベース連携
Sysdig Secure は、CI/CDパイプライン上（sysdig-cli-scanner）でコンテナイメージから SBOM（SPDX／CycloneDX）を自動生成し、内蔵脆弱性データベース（NVD、OSV、ベンダーアドバイザリ等を統合）と突き合わせます。生成されたSBOMはイメージダイジェスト単位で保管され、後日の再スキャンやCVE発生時の影響範囲特定にもそのまま利用できます。GitHub Actions・Jenkins・GitLab CI などへのインテグレーションがそろっているため、既存パイプラインへの組み込みもスムーズです。
Runtime Insightsとの統合
Sysdig の差別化要素は、ビルド時のSBOMとランタイム実行情報を統合した「In-Use」判定にあります。本番でロードまたは実行されているライブラリだけを優先度上位に押し上げる仕組みによって、Critical対応の件数を実運用可能な水準まで絞り込めます。この統合の具体的な仕組みや数値については、コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組みで詳しく解説しています。本記事ではビルド側のSBOM生成・VEX判定までを扱い、ランタイム側の検知技術は分担して記述する構成にしています。
まとめ — シフトレフトを完成させる三本柱の一つとして
SBOM は、SolarWinds 以降のサプライチェーン攻撃や、Log4Shell 級の影響範囲特定の難しさに対して、現時点で最も実装が成熟した回答の一つだといえます。SPDX／CycloneDX のいずれかでイメージやソースから自動生成し、VEX で悪用可能性を判定、Dependabot／OSV-Scanner で継続監視、Sigstore で署名・検証——この一連の流れをCI/CDに組み込めれば、「依存先の見えなさ」という根本的な課題を構造的に縮小していくことができます。
ただし、SBOMだけで完結する話ではありません。ビルド時の正確な依存把握（本記事）、ランタイム側での実行コード判定（コンテナランタイム記事）、組織側のRACI／SLA設計（DevSecOps記事）という3つの要素が揃って初めて、シフトレフトの実装は形になります。本記事は、その3つのうち「ビルド段階＝SBOM」の正典として位置づけられるものです。