SBOMとは

SBOM（Software Bill of Materials：エスボム）とは、ソフトウェアを構成するすべてのコンポーネント（ライブラリ、フレームワーク、モジュール等）の一覧を構造化したデータです。日本語では「ソフトウェア部品表」と訳されます。

製造業における「部品表（BOM）」が製品を構成する部品の一覧であるように、SBOMはソフトウェアの「中身」を可視化するものです。どのオープンソースライブラリを使っているか、そのバージョンは何か、ライセンスは何か——これらの情報を機械的に処理可能な形式でまとめたものがSBOMです。

📌 SBOMの一番わかりやすい例え

食品の原材料表示をイメージしてください。加工食品のパッケージには「小麦粉、砂糖、バター、卵……」と原材料が記載されています。SBOMはソフトウェアの「原材料表示」であり、利用者が「このソフトウェアに何が入っているか」を確認できるようにする仕組みです。

なぜ今SBOMが注目されているのか

① ソフトウェアサプライチェーン攻撃の増加

2020年のSolarWinds事件、2021年のLog4Shell脆弱性は、世界中の企業・政府機関に甚大な影響を与えました。これらの事例は、ソフトウェアの構成要素（サプライチェーン）に潜む脆弱性がいかに広範な被害をもたらすかを示しました。

Log4Shellの場合、Apache Log4jというJavaのロギングライブラリに深刻な脆弱性が発見されましたが、多くの企業は「自社のどのシステムにLog4jが含まれているか」を即座に把握できませんでした。SBOMが整備されていれば、影響範囲を数分で特定できます。

② OSS利用の急拡大

現代のソフトウェアは、コードの70〜90%がオープンソースソフトウェア（OSS）で構成されていると言われています。自社で書いたコードだけでなく、依存するOSSの脆弱性やライセンス違反もリスクとなるため、OSSの利用状況を可視化するSBOMの重要性が急増しています。

③ 各国政府の義務化・推奨

米国では2021年の大統領令14028号で、連邦政府に納入するソフトウェアにSBOMの提供を義務化しました。日本でも経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」を公表し、政府統一基準群の令和7年度改定でもSBOM対応が推奨事項に追加されています。

SBOMに含まれる情報

NTIANational Telecommunications and Information Administrationが定義する「SBOMの最小要素」は以下の通りです。

要素内容例
サプライヤー名コンポーネントの提供者Apache Software Foundation
コンポーネント名ライブラリ/パッケージの名称log4j-core
バージョン使用しているバージョン番号2.17.1
一意な識別子CPE、PURLなどの標準識別子pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1
依存関係他のコンポーネントとの依存関係log4j-api 2.17.1に依存
SBOMの作成者SBOMを生成した組織・ツールBTN Consulting / Syft
タイムスタンプSBOMの生成日時2026-02-28T10:00:00Z

主要フォーマット：SPDX vs CycloneDX

項目SPDXCycloneDX
策定組織Linux FoundationOWASP
国際規格ISO/IEC 5962として国際規格化ECMA-424として標準化（2024年）
主な用途ライセンスコンプライアンス重視セキュリティ・脆弱性管理重視
出力形式JSON / XML / RDF / Tag-ValueJSON / XML / Protocol Buffers
脆弱性情報の統合可能（VEX連携）ネイティブサポート（VDR/VEX統合）
採用傾向米国政府、大企業のOSS管理セキュリティ重視の開発チーム
💡 どちらを選ぶべきか

セキュリティ・脆弱性管理が主目的であればCycloneDXが扱いやすく、ライセンスコンプライアンスやOSSガバナンスも含めた包括的な管理にはSPDXが適しています。多くのSBOM作成ツールは両方のフォーマットに対応しているため、まずはどちらかで始めて必要に応じて変換するアプローチが現実的です。

SBOM作成ツール

ツール対応言語/パッケージ出力形式特徴
Syft（Anchore）多言語（Java, Node, Python, Go, Rust等）SPDX / CycloneDXコンテナイメージ対応。CI/CDパイプラインに組み込みやすい
Trivy（Aqua Security）多言語 + OS パッケージSPDX / CycloneDXSBOM生成＋脆弱性スキャンを一体で実行
cdxgen（CycloneDX）多言語CycloneDXCycloneDX公式ツール。evinse（エビデンスモード）で実使用コンポーネントのみ抽出
Microsoft SBOM Tool多言語SPDXMicrosoft製。GitHub Actionsとの統合が容易

CI/CDパイプライン（GitHub Actions、Azure DevOps、Jenkins等）にSBOM生成ステップを組み込むことで、ビルドのたびに最新のSBOMが自動生成される運用が実現できます。

SBOMの活用シーン

① 脆弱性管理の高速化

新たな脆弱性（CVE）が公開された際に、SBOMと脆弱性データベースを突き合わせることで、影響を受けるシステムを即座に特定できます。Log4Shellのような緊急脆弱性への対応時間を大幅に短縮できます。

② ライセンスコンプライアンス

利用しているOSSのライセンス条件（MIT、Apache 2.0、GPL等）を把握し、ライセンス違反のリスクを管理します。特にGPLなどのコピーレフト型ライセンスは、自社のプロプライエタリコードの公開義務が発生する可能性があるため注意が必要です。

③ ソフトウェア調達時のリスク評価

取引先やベンダーから提供されるソフトウェアのSBOMを要求し、既知の脆弱性を含んでいないか、サポート切れのコンポーネントを使用していないかを事前に評価します。

④ インシデント対応

セキュリティインシデント発生時に、影響を受けたシステムの構成を正確に把握し、原因究明と影響範囲の特定を迅速に行うための基礎データとして活用します。

政府方針とSBOM

経済産業省の手引

経済産業省は2023年に「ソフトウェア管理に向けたSBOMの導入に関する手引（SBOM導入手引）」を公表しました。本手引では、SBOMの基本概念、導入の進め方、想定される課題と対策がまとめられています。

政府統一基準群での言及

令和7年度版の政府統一基準群では、SBOMの作成・管理が推奨事項として追加されました。政府情報システムを構成するソフトウェアについて、SBOMを管理し、脆弱性情報の迅速な照合に活用することが求められています。

米国の動向

米国では大統領令14028号（2021年）以降、連邦政府に納入するソフトウェアへのSBOM提供が義務化されています。NTIAの最小要素ガイドラインやCISAのSBOMガイダンスが具体的な実装指針として公開されています。

導入の課題と対策

課題内容対策
正確性の確保ツールによって検出されるコンポーネントに差異がある複数ツールの併用、手動確認の組み合わせ
依存関係の深さ直接依存だけでなく、間接依存（推移的依存）の把握が困難ロックファイル（package-lock.json等）を活用したツール解析
運用の継続性一度作って終わりではなく、更新が必要CI/CDパイプラインに組み込み、ビルド時に自動生成
社内の理解不足開発チームがSBOMの価値を理解していない脆弱性対応事例（Log4Shell等）を用いた啓蒙活動
取引先との連携ベンダーからSBOMを入手できない調達契約にSBOM提供義務を明記

BTNコンサルティングの支援

SBOM導入コンサルティング

お客様の開発プロセスに合わせたSBOM導入計画の策定、ツール選定、CI/CDパイプラインへの組み込みを支援します。

脆弱性管理体制の構築

SBOMと脆弱性データベースの突き合わせによる脆弱性管理プロセスの構築を支援します。AWS Inspector、Azure Defender、Google Cloud Security Command Centerなどのクラウドネイティブツールとの連携も対応します。

ソフトウェア調達時のセキュリティ評価

取引先・ベンダーから提供されるソフトウェアのSBOMレビュー、脆弱性評価、ライセンスコンプライアンスチェックを支援します。

💡 関連記事

→ 政府統一基準群の詳細解説（SBOM推奨の背景）
→ GRCとセキュリティマネジメント入門

まとめ

SBOMはソフトウェアの「原材料表示」であり、脆弱性管理、ライセンスコンプライアンス、サプライチェーンリスク管理の基盤となります。Log4Shell事件以降、各国政府がSBOM対応を義務化・推奨する流れが加速しており、日本でも経済産業省の手引と政府統一基準群でSBOM管理が求められています。まずはCI/CDパイプラインにSyftやTrivyなどのツールを組み込み、主要システムのSBOMを自動生成するところから始めましょう。