2021年12月のLog4Shell（CVE-2021-44228）で、多くの組織が真っ先に直面したのは「自社の製品にLog4jが入っているか」という単純な問いだった。その答えがすぐ出せなかった事実こそ、SBOMが必要とされる理由を端的に示している。
SBOM（Software Bill of Materials、ソフトウェア部品表）は、ソフトウェアに含まれる全コンポーネントとバージョン、依存関係を機械可読な形式で一覧化した文書だ。サプライチェーン攻撃が常態化したいま、防御の出発点になる。
サプライチェーン攻撃の全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。
- SBOMの本質は「自分が使っているソフトの全成分表を機械可読で持つこと」。脆弱性や汚染パッケージ公表時に影響範囲を秒で特定できる
- 標準フォーマットはSPDX（Linux Foundation・ISO/IEC 5962）とCycloneDX（OWASP・Ecma ECMA-424）の2大勢力。生成ツールはどちらも出力できる
- 生成はSyft・Trivy・cargo-sbom、CI組み込みはGitHub Actions、改ざん対策はSigstore cosignの署名・検証。生成→署名→検証を自動化して初めて運用が回る
30秒でわかるSBOM——ソフトウェア部品表とサプライチェーン防御の要点
時間がない読者のために、SBOMの要点を先にまとめる。詳細は各セクションで掘り下げる。
・SBOMとは：ソフトウェアの依存パッケージ・ライブラリを一覧化した「部品表」。製造業のBOMのソフト版
・なぜ必要か：Log4Shellやnpmワーム（Shai-Hulud系）の公表時、影響範囲を即特定するため。リストがなければ手作業の棚卸しになる
・2大フォーマット：ライセンス・来歴重視ならSPDX、脆弱性・セキュリティ運用重視ならCycloneDX
・生成ツール：コンテナ／ファイルはSyft・Trivy、Rustはcargo-sbom。CIに組み込めば自動生成
・改ざん対策：Sigstoreのcosignでattestation署名し、配布側でverify-attestation検証
・法規制：米大統領令14028で連邦調達に必須化、EU CRAは2027年12月から本格適用へ
SBOMは「作って終わり」ではなく、生成・保管・署名・検証・更新のライフサイクルで運用する点が要だ。以下で具体的なコマンドと自動化の組み方を示す。
SBOMとは何か——ソフトウェア部品表が解決する依存関係の不可視問題
現代のソフトウェアは、自分で書いたコードよりも依存パッケージのほうが圧倒的に多い。npmの小さなアプリでも、推移的依存を含めれば数百〜千を超えるパッケージが同梱される。
問題は、その全容を誰も把握していないことだ。直接依存はpackage.jsonで見えても、依存の依存（推移的依存）は手作業では追えない。SBOMはこの不可視な依存ツリーを機械可読な一覧に変換する。
NTIAが定めた最小要素
米国のNTIA（国家電気通信情報管理庁）は2021年、SBOMが最低限満たすべき要素を定義した。これは大統領令14028を受けた成果で、いまも事実上の基準になっている。最小要素は3つのカテゴリで構成される。
・データフィールド：各コンポーネントについて追跡すべき基本情報
・自動化対応：機械可読フォーマットで自動生成・自動処理できること
・運用プロセス：SBOMの要求・生成・利用の運用ルール
データフィールドはさらに7項目に分かれる。下表がその全量だ。生成ツールが出力するフィールドが、この7項目を満たしているかが品質の最初のチェックポイントになる。
| # | データフィールド | 内容 |
|---|---|---|
| 1 | 供給者名（Supplier Name） | コンポーネントを作成・提供した個人または組織 |
| 2 | コンポーネント名（Component Name） | 供給者が定めるソフトウェア単位の名前 |
| 3 | バージョン（Version） | 前バージョンからの変更を識別する識別子 |
| 4 | 一意識別子（Other Unique Identifiers） | PURL・CPE・SWIDタグなどの機械可読ID |
| 5 | 依存関係（Dependency Relationship） | 上流コンポーネントとの依存の関係 |
| 6 | SBOM作成者（Author） | このSBOMデータを作成した主体 |
| 7 | タイムスタンプ（Timestamp） | SBOM作成日時。ISO 8601・UTC表記 |
NTIAは自動化対応の前提として、SPDX・CycloneDX・SWIDのいずれかの標準形式に準拠することを求めている。なお2025年8月にはCISAが最小要素の改訂版ドラフトを公開し、ハッシュ値やライセンス情報などフィールドの拡充が議論されている。
コンポーネントを一意に指す識別子
7項目のうち実運用で効いてくるのが「一意識別子」だ。同じ名前のパッケージが別エコシステムに存在するため、名前だけでは特定できない。ここで使われるのがPURL（Package URL）やCPE（Common Platform Enumeration）といった機械可読IDだ。
例えばPURLはpkg:npm/[email protected]のように、エコシステム・パッケージ名・バージョンを1つの文字列で表す。SBOMがこの識別子を持つことで、脆弱性データベースとの自動照合が可能になり、人手の名寄せが不要になる。逆に識別子が欠けたSBOMは、いざ照合する段で使い物にならない。
なぜSBOMが必要か——Log4jとShai-Hulud系ワームが突きつけた現実
SBOMの価値は、インシデント発生時に最も鮮明になる。脆弱性や汚染パッケージが公表された瞬間、対応の速さは「自社が影響を受けるか」を判定する速さで決まる。
Log4Shellが露呈した棚卸しコスト
2021年のLog4Shellは、Apache Log4jという広く使われたロギングライブラリの脆弱性だった。深刻だったのは脆弱性そのものより、「どの製品にLog4jが、どのバージョンで入っているか」を誰も即答できなかった点だ。
多くの組織が手作業のソース調査に数週間を費やした。SBOMが整備されていれば、log4j-coreを含むコンポーネントをクエリ一発で抽出し、対応の優先順位を即座に決められたはずだ。
npmワームが示す「速度」の脅威
依存汚染型の攻撃は年々高速化している。本サイトで追ってきたMini Shai-Hulud系ワームは、正規パッケージのバージョンにマルウェアを混入させ、自己増殖的に拡散する手口だ。
・@antv npmに不正コード混入｜Mini Shai-HuludがAnt Design可視化323パッケージを22分で汚染 では、汚染がわずか22分で300超のパッケージに波及した
・TanStack公式@tanstack/*にマルウェア混入｜205パッケージに広がるMini Shai-Huludワーム では公式パッケージ群が標的になった
・Shai-Hulud派生「Hades」がMCP開発者を標的に｜PyPI汚染とIronWorm併発の供給網ワーム総まとめ ではAI開発ツールの認証情報まで狙われた
これらの攻撃に共通するのは、公表から自社の点検完了までの時間が被害を左右する点だ。SBOMがあれば、汚染が確認されたパッケージ名とバージョンを照合し、影響範囲を数秒で割り出せる。リストがなければ、その場で全リポジトリの棚卸しを始めることになる。
SBOMは攻撃を防ぐ盾ではなく、攻撃が起きた後に「どこを見ればよいか」を即答する地図だ。インシデント対応の初動を、推測から確定情報に変える。
規制がSBOMを義務化へ押し上げている
SBOMはベストプラクティスから法的要件へと移行しつつある。米国では2021年の大統領令14028が、連邦政府に納入するソフトウェアへのSBOM提出を求めた。前述のNTIA最小要素は、この大統領令を実装するための基準として生まれている。
EUのサイバーレジリエンス法（CRA）はさらに踏み込み、デジタル要素を持つ製品にSBOMの作成・維持を義務付ける。主要な義務は2027年12月から本格適用される見込みで、EU市場に製品を出す事業者は対応を迫られる。
・米国：大統領令14028で連邦調達ソフトにSBOM必須化、NTIA最小要素が事実上の基準
・EU：CRAで対象製品にSBOMを義務付け、2027年12月から本格適用
・日本：経産省・IPAがソフトウェア管理手法としてSBOM導入の手引きを公開し、普及を後押し
規制対応として捉えると「面倒な書類仕事」に見えるが、本質は同じだ。何を使っているか分からなければ、守ることも証明することもできない。規制はその当たり前を制度化したにすぎない。
SPDX vs CycloneDX——2大SBOMフォーマットの違いと選び方
SBOMの標準フォーマットは事実上、SPDXとCycloneDXの2つに収束している。どちらも機械可読で、主要な生成ツールは両方を出力できる。違いは「設計思想」にある。
SPDXはLinux Foundationがホストするオープン標準で、ISO/IEC 5962:2021として国際標準化されている。最新のSPDX 3.0.0は2024年4月にリリースされ、Security・Build・Dataset・AIといったプロファイルが追加された。ライセンスや来歴（provenance）の網羅性に強みがある。
CycloneDXはOWASP FoundationとEcma Internationalが共同で維持し、技術委員会TC54のもとでECMA-424として2025年12月に標準化された。仕様バージョンは1.7（2025年10月）。SBOMだけでなくSaaSBOM・HBOM（ハードウェア）・ML-BOM・CBOM（暗号資産）・VEXなど、セキュリティ運用向けの拡張が豊富だ。
| 観点 | SPDX | CycloneDX |
|---|---|---|
| 主管 | Linux Foundation | OWASP + Ecma International |
| 標準 | ISO/IEC 5962:2021 | ECMA-424（2025-12） |
| 最新版 | 3.0.0（2024-04） | 1.7（2025-10） |
| フォーマット | JSON / YAML / RDF / tag-value | JSON / XML / Protobuf |
| 設計の重心 | ライセンス・来歴の網羅 | 脆弱性・セキュリティ運用 |
| 拡張 | Security/Build/Dataset/AIプロファイル | SaaSBOM/HBOM/ML-BOM/CBOM/VEX |
| 向く用途 | コンプライアンス・OSSライセンス管理 | 脆弱性管理・CI連携・VEX運用 |
選び方の指針はシンプルだ。OSSライセンス監査や規制対応で網羅性を求めるならSPDX、脆弱性スキャンやVEX（影響評価）とつなぐセキュリティ運用ならCycloneDXが扱いやすい。
迷う場合は両方生成しておけばよい。後述するSyftやTrivyは、1回のスキャンで両形式を同時に出力できる。フォーマット選定でプロジェクトを止める必要はない。
VEXで「影響なし」を伝える
SBOMがあっても、含まれるパッケージに脆弱性が見つかるたびに大量のアラートが出る。だが、その脆弱性が実際に悪用可能とは限らない。呼び出されない関数の脆弱性や、攻撃経路が塞がれているケースは多い。
ここで使うのがVEX（Vulnerability Exploitability eXchange）だ。VEXは「このCVEは自社製品では悪用不可」といった影響評価を機械可読で配布する仕組みで、CycloneDXはこのVEXをネイティブに表現できる。SBOMが「何が入っているか」を示すのに対し、VEXは「そのうちどれが本当に危ないか」を示す。両者を組み合わせると、利用側は無意味なアラート対応に時間を奪われずに済む。
SBOM生成ツール——Syft・Trivy・cargo-sbomの使い方
SBOMは手書きするものではなく、ツールがソースやコンテナをスキャンして自動生成する。ここでは定番の3ツールを、実際のコマンド付きで紹介する。
Syft——コンテナ・ファイルシステムの定番
Anchoreが開発するSyftは、コンテナイメージやファイルシステムからSBOMを生成するCLIだ。Alpine・Debian・RPMといったOSパッケージから、Go・Python・Java・JavaScript・Ruby・Rust・PHP・.NETなど数十のエコシステムに対応する。
# コンテナイメージの中身を一覧表示
syft alpine:latest
# プロジェクトディレクトリをスキャン
syft ./my-project
# CycloneDX JSON形式で標準出力へ
syft <image> -o cyclonedx-json
# SPDXとCycloneDXを同時にファイル出力
syft <image> -o spdx-json=./spdx.json -o cyclonedx-json=./cdx.json
-oフラグでフォーマットを指定し、=パスを付ければファイルに保存できる。Syftは脆弱性スキャナのGrypeと組み合わせると、生成したSBOMをそのまま脆弱性照合に回せる。
Trivy——脆弱性スキャンとSBOMを一体運用
Aqua SecurityのTrivyは脆弱性スキャナとして広く使われるが、SBOM生成も担う。スキャンとSBOMを同じツールで完結できるのが強みだ。
# CycloneDX形式でSBOM生成
trivy image --format cyclonedx --output result.json alpine:3.15
# SPDX-JSON形式で生成
trivy image --format spdx-json --output result.json alpine:3.15
# 脆弱性情報も含めたCycloneDXを生成
trivy image --scanners vuln --format cyclonedx --output result.json alpine:3.15
# 既存のSBOMファイルを入力に脆弱性スキャン
trivy sbom ./sbom.spdx
CycloneDX出力はデフォルトでは脆弱性を含まないため、--scanners vulnを明示する。trivy sbomは生成済みSBOMを入力として受け取り、新たな脆弱性が公表されたときの再評価に使える。
cargo-sbom——Rustプロジェクト向け
Rustエコシステムではcargo-sbomとcargo-cyclonedxが定番だ。cargo-sbomはSPDXとCycloneDXの両方を、cargo-cyclonedxはCargo.lockとcargo metadataからCycloneDXを出力する。
# cargo-sbom のインストールと実行
cargo install cargo-sbom
cargo sbom --output-format=cyclone_dx_json_1_6
# cargo-cyclonedx で JSON 出力
cargo install cargo-cyclonedx
cargo cyclonedx --format json --output sbom.json
cargo-cyclonedxはCargo.lockだけに依存するツールでは扱えないフィーチャーフラグの組み合わせやクロスコンパイル対象も反映できる。下表に3ツールの特徴を整理する。
| ツール | 主な対象 | 出力形式 | 開発元 |
|---|---|---|---|
| Syft | コンテナ・ファイルシステム | SPDX / CycloneDX / Syft-JSON | Anchore |
| Trivy | コンテナ・FS・既存SBOM | SPDX / CycloneDX | Aqua Security |
| cargo-sbom | Rust（Cargo） | SPDX / CycloneDX | OSS（crates.io） |
GitHub ActionsとSigstoreでSBOM生成・署名・検証を自動化する
SBOMは一度作って満足するものではない。依存は更新のたびに変わるため、ビルドのたびに自動生成し、署名して成果物に残し、配布側で検証する——この一連をCI/CDで自動化して初めて運用が回る。まずはGitHub Actionsでの生成から見ていく。
GitHub ActionsでSBOM生成を自動化する
下記はAnchore公式のsbom-actionを使い、ビルドしたイメージからSBOMを生成してアーティファクトに残すワークフローの例だ。
name: generate-sbom
on:
push:
tags: ["v*"]
jobs:
sbom:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write # keyless署名のOIDCに必要
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapp:${{ github.sha }} .
- name: Generate SBOM (CycloneDX)
uses: anchore/sbom-action@v0
with:
image: myapp:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Upload SBOM artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cdx.json
ポイントは2つある。リリースタグのpushを契機にすること、そしてid-token: write権限を付けておくことだ。後者は次のSigstore署名でkeyless方式を使うために必要になる。
運用のコツ：SBOMはリリース成果物（GitHub Releasesやコンテナレジストリ）に添付して配布する。CI内に置きっぱなしにすると、配布先の利用者が検証できない。生成したSBOMを「製品に同梱する成果物」として扱うことが、サプライチェーン透明性の前提になる。
GitHub Actionsの権限設計やCI/CDの安全化は、サプライチェーン防御の重要な一部だ。タグのSHA固定や最小権限の徹底とあわせて運用したい。
Sigstoreでの署名連携とSBOM検証フロー
SBOM自体が改ざんされれば、安心するための文書がむしろ危険になる。そこで生成したSBOMに署名し、利用側で検証する仕組みが要る。これを担うのがSigstoreのcosignだ。
cosignはSBOMを「attestation（証明）」としてコンテナイメージに添付する。署名はDSSE仕様に従い、検証側は署名と証明書の正当性を確認できる。
# SBOMをattestationとして署名・添付（鍵あり方式）
cosign attest --predicate sbom.cdx.json --type cyclonedx \
--key cosign.key <image>
# attestationを検証
cosign verify-attestation --key cosign.pub <image>
--predicateに署名対象のSBOMを、--typeにその種別を指定する。検証側はcosign verify-attestationで署名と証明書をチェックし、信頼できるSBOMだけを採用できる。
keyless署名でCIから鍵を排除する
鍵ファイルの管理は漏洩リスクを伴う。Sigstoreのkeyless署名は、CI環境のOIDC認証から一時証明書をFulcioが発行し、署名記録をRekor透明性ログに残す方式だ。長期保管する秘密鍵が不要になる。
# keyless署名（CI環境のOIDC IDを利用、--keyを省略）
COSIGN_EXPERIMENTAL=1 cosign attest \
--predicate sbom.cdx.json --type cyclonedx <image>
# keyless検証（証明書のIDと発行元を指定）
cosign verify-attestation --type cyclonedx \
--certificate-identity-regexp ".*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com <image>
先のGitHub Actionsでid-token: writeを付けたのは、この一時IDを取得するためだ。CI内で完結し、鍵を一切持たずに署名できる。
生成から検証までのフロー
ここまでの工程を1枚の図にまとめる。生成・署名・配布・検証が一本のパイプラインでつながることが、SBOM運用のゴールだ。
Syft / Trivy / cargo-sbom] B --> C{フォーマット選択} C -->|ライセンス・来歴重視| D[SPDX] C -->|脆弱性・運用重視| E[CycloneDX] D --> F[cosign attest で署名
keyless / OIDC] E --> F F --> G[Rekor 透明性ログに記録] F --> H[成果物に添付して配布
レジストリ / Releases] H --> I[利用側で cosign verify-attestation] I --> J{署名・証明書は正当か} J -->|Yes| K[SBOMを信頼して脆弱性照合] J -->|No| L[破棄・調査] K --> M[Trivy sbom で再スキャン
新規CVE公表時に再評価]
検証に通ったSBOMは、新たな脆弱性が公表されるたびにtrivy sbomで再スキャンすれば、過去にビルドした成果物の影響範囲も後追いで判定できる。SBOMは生成して保管し、署名で守り、検証して使い、CVE公表のたびに再評価する——この循環で初めて防御の道具になる。
まとめ——SBOMは「作る」より「運用する」
SBOMの価値は、文書を1枚作ることではなく、依存の全量を機械可読で持ち続け、インシデント時に即座にクエリできる体制にある。Log4Shellやnpmワームが繰り返し示したのは、影響範囲を即答できるかどうかが被害を左右するという現実だ。
・フォーマットはSPDXとCycloneDXの2択。迷えば両方生成
・生成はSyft・Trivy・cargo-sbomをCIに組み込み、ビルドごとに自動化
・署名はSigstore cosignのkeyless方式で鍵管理を排除
・検証は配布側でverify-attestation、CVE公表時はtrivy sbomで再スキャン
まずは手元のコンテナにsyft <image> -o cyclonedx-jsonを一度走らせ、自分が何を使っているのかを可視化するところから始めたい。攻撃の地図を持つ第一歩になる。
参照ソース
・NTIA — The Minimum Elements For a Software Bill of Materials (SBOM), 2021
・CISA — 2025 Minimum Elements for a Software Bill of Materials (PDF)
・SPDX — Overview（Linux Foundation / ISO/IEC 5962:2021）
・CycloneDX — Specification Overview（OWASP / Ecma ECMA-424）
・Anchore Syft — GitHub リポジトリ
・Aqua Trivy — SBOM ドキュメント
・Sigstore cosign — Attestation ドキュメント
