SBOMとは？必要性・記載項目を解説

SBOM（Software Bill of Materials）は、ソフトウェアを構成するコンポーネントや依存関係を一覧化した「ソフトウェア部品表」です。

米国NISTはSBOMを、ソフトウェアを構築するために使われる各コンポーネントの詳細とサプライチェーン上の関係を記録したものと定義しています。米国CISAも、SBOMによってソフトウェアに何が含まれているかを可視化し、新たな脆弱性が公表された際に自社製品や利用ソフトウェアが影響を受けるかを確認しやすくなるとしています。

SBOMは単なるOSS一覧ではありません。ソフトウェアの開発、調達、運用、脆弱性対応をつなぐための基礎データとして利用できます。

SBOMとは

SBOMは「Software Bill of Materials」の略称です。

製造業で製品を構成する部品をBOM（Bill of Materials）として管理するのと同じように、SBOMではソフトウェアを構成するライブラリ、パッケージ、モジュールなどを記録します。

米国NTIAはSBOMを「ソフトウェアを構成する材料の一覧」に例えています。NISTでは、オープンソースと商用コンポーネントを組み合わせて開発される現代のソフトウェアについて、その構成要素を列挙する正式な記録と整理しています。

SBOMを利用すると、例えば次の情報を追跡しやすくなります。

• ソフトウェアに含まれるコンポーネント
• コンポーネントのバージョン
• コンポーネント間の依存関係
• ソフトウェアを識別するための識別子
• ライセンス情報
• SBOMの生成日時
• SBOMを生成したツール
• コンポーネントのハッシュ値

SBOMを作る目的は、一覧を作成すること自体ではありません。脆弱性やサプライチェーン上の問題が判明した際に、「自社のどの製品・システムが影響を受けるのか」を確認できる状態にすることが中心です。

なぜSBOMが必要なのか

企業が利用・開発するソフトウェアは、自社で書いたコードだけで構成されているとは限りません。

OSS、商用ライブラリ、フレームワーク、コンテナイメージ、パッケージなど、多数の外部コンポーネントが組み込まれています。そのため、あるコンポーネントに重大な脆弱性や改ざんが見つかった場合、自社がそのコンポーネントを直接導入した記憶がなくても、依存関係を通じて影響を受けている可能性があります。

英国National Cyber Security Centre（NCSC）は、ソフトウェアサプライチェーンは大規模かつ複雑であり、まず何を利用しているかを把握するインベントリが必要だと説明しています。SBOMは、その把握を支援する手段の一つです。

広く使われるコンポーネントでは影響範囲の確認が難しくなる

セキュリティ対策Labでは、広く利用されるソフトウェアやパッケージに問題が発生し、多数の利用者が短時間で影響確認を迫られた事例を継続的に取り上げています。

2026年3月には、JavaScriptで広く利用されるAxiosのnpmパッケージが侵害され、悪意ある依存パッケージが組み込まれた事例が確認されました。対象となったAxios 1.14.1は週次約1億ダウンロード規模とされ、開発者が直接選択したパッケージだけでなく、依存関係を含めた確認が必要になりました。

関連記事：GitHubがnpm v12のセキュリティ変更3件を発表―2026年7月リリース予定

2025年には、ReactベースのフレームワークNext.jsで認証回避につながるCVE-2025-29927が公表されています。Next.jsのように多数のWebサービスで利用されるフレームワークでは、脆弱性情報を確認した後、自社のどのシステムで対象バージョンを利用しているかを特定する作業が発生します。

関連記事：Next.jsが危険度の高い脆弱性を修正 早期適用を（CVE-2025-29927）

SBOMが整備されていれば、コンポーネント名やバージョンを基に影響対象を検索しやすくなります。

SBOMに記載する主な情報

CISAは2025年に「Minimum Elements for a Software Bill of Materials（SBOM）」を更新し、SBOMに含めるデータ項目や運用上の要素を整理しました。

主なデータ項目は次の通りです。

2025年版では、ハッシュ値、ライセンス、ツール名、生成コンテキストなどがデータ項目として追加されています。

CISAはデータ項目だけでなく、SBOMを機械処理できること、ソフトウェア更新に合わせてSBOMを更新すること、既知・未知の範囲を明示すること、受け渡し方法を定めることなども扱っています。

SBOMの代表的な形式

SBOMは人が読む一覧だけではなく、ツール間で交換・処理できる形式で運用することが想定されています。

NTIAはSBOMに関連する代表的な形式として、SPDX、CycloneDX、SWIDを整理しています。

企業がSBOMツールを選ぶ場合は、「SBOMを出力できるか」だけでなく、自社や取引先が利用する形式へ対応しているかを確認する必要があります。

SBOMとSCAの違い

SBOMとSCA（Software Composition Analysis）は同じものではありません。

SBOMは、ソフトウェアに含まれるコンポーネントと依存関係を記録したデータです。

SCAは、ソフトウェアに含まれるOSSなどを解析し、脆弱性、ライセンス、依存関係などを調査する手法・ツールを指します。

SCAツールによってSBOMを生成できる場合がありますが、役割は次のように分けられます。

SBOMを作成しただけでは、脆弱性への対応は完了しません。

SBOMとVEXの違い

VEX（Vulnerability Exploitability eXchange）は、ある脆弱性が特定の製品やコンポーネントへ実際に影響するかを伝達するための情報です。

例えばSBOM上に脆弱なライブラリが記録されていても、その製品では脆弱な機能を呼び出しておらず、実際には影響を受けない場合があります。

SBOMが「何が入っているか」を示すのに対し、VEXは「その脆弱性がその製品へ影響するか」を補足する役割があります。

イスラエル国家サイバー総局（INCD）は2025年の公開資料で、ソフトウェアの各バージョンについてサプライヤーへSBOMとVEXの提供を求めることを推奨しています。INCDはSBOMを、コンポーネント、ライブラリ、依存関係を含む機械可読の一覧として説明し、VEXを組み合わせることで既知の脆弱性が実際に対象製品へ影響するかを判断しやすくするとしています。

SBOMを脆弱性管理でどう使うのか

NISTは、SBOMリポジトリと脆弱性検出機能を連携し、サプライチェーン上のサイバーリスクについて自動的に通知できる仕組みを示しています。

基本的な流れは次の通りです。

1. 利用・開発しているソフトウェアのSBOMを取得または生成する
2. コンポーネント名とバージョンを管理する
3. CVEなどの脆弱性情報と照合する
4. 該当する製品・システムを特定する
5. VEXや利用状況を確認して実際の影響を評価する
6. 更新、緩和策、利用停止などの対応につなげる
7. ソフトウェア更新時にSBOMも更新する

SBOMは脆弱性管理の代替ではなく、脆弱性管理に必要な「どのソフトウェアを使っているか」という情報の精度を高めるための基盤です。

SBOMは開発企業だけでなく購入企業にも関係する

SBOMはソフトウェアベンダーだけの仕組みではありません。

NISTはソフトウェアを調達する組織について、購入ソフトウェア、OSS、内製ソフトウェアを含めてSBOMをカタログ化し、必要に応じてサプライヤーから機械可読なSBOMを取得する考え方を示しています。

イスラエルのINCDも、サプライヤーにSBOMとVEXを要求する考え方を示しています。

調達時には、例えば次の点を確認できます。

• SBOMを提供できるか
• SPDXやCycloneDXなど、どの形式に対応するか
• ソフトウェア更新時にSBOMも更新されるか
• VEXを提供できるか
• OSSや第三者コンポーネントをどこまで収録しているか
• SBOMの提供方法と更新通知方法
• 脆弱性発見時の連絡方法

従業員数の多い企業では、購入ソフトウェアやSaaSの数も増えます。自社開発だけでなく、調達・委託先管理の観点からSBOMを扱う設計が必要です。

SBOMの作り方

SBOMの作成方法は大きく分けると、開発工程で生成する方法と、完成したソフトウェアを解析して生成する方法があります。

代表的には次の方法があります。

• ビルド時に依存関係情報から生成する
• パッケージマネージャーの情報から生成する
• ソースコードをSCAツールで解析する
• コンテナイメージを解析する
• バイナリやインストールパッケージを解析する
• ソフトウェアベンダーから提供を受ける

NISTは、ベンダーからSBOMを入手できないレガシーソフトウェアなどについて、技術面・法的な条件が許す場合にはインストールパッケージを解析してSBOMを生成する方法も示しています。

SBOM生成方法によって取得できるコンポーネントや依存関係の範囲は変わります。そのため、ツールを導入しただけで「完全なSBOMができた」と判断せず、カバレッジを確認する必要があります。

SBOM運用の注意点

SBOMにはいくつか注意点があります。

SBOMがあっても脆弱性が自動的に修正されるわけではない

SBOMはインベントリです。

対象コンポーネントに脆弱性が存在することが分かった後は、影響評価、優先順位付け、パッチ適用、緩和策、再確認などの脆弱性管理が必要です。

コンポーネントが記載されているだけでは「脆弱」とは限らない

脆弱性のあるライブラリがSBOMに含まれていても、実際に脆弱なコード経路を利用していない場合があります。

VEXや製品ベンダーのセキュリティアドバイザリを組み合わせて判断します。

SBOM自体を更新する必要がある

ソフトウェアは継続的に更新されます。

依存ライブラリの追加・削除・更新が発生すれば、古いSBOMでは現在の構成を表せません。CISAのMinimum Elementsでも、SBOMデータの更新や生成頻度が運用要素として扱われています。

SBOMのカバレッジを確認する

直接依存するコンポーネントだけを記録し、その先の依存関係が抜けている場合、影響確認に使える範囲が狭くなります。

生成ツール、開発言語、ビルド方式、コンテナ、バイナリ解析の有無などによって取得範囲が変わるため、SBOMの「存在」だけでなく内容を確認します。

米国・英国・イスラエルの公的機関が示すSBOM

米国では、NTIAがSBOMの基本概念、最小要素、ツール分類、生成方法などを整理し、その後CISAがSBOM関連施策を引き継いでいます。

CISAは2025年版Minimum Elementsで、従来のSBOM項目を更新し、ハッシュ、ライセンス、生成ツール、生成コンテキストなどを追加しました。

NISTはSBOMをソフトウェアサプライチェーンリスク管理の一部として扱い、SBOMリポジトリと脆弱性検出機能の連携を示しています。

英国NCSCはSBOMをソフトウェアインベントリを改善する手段として説明する一方、SBOMを持つだけでソフトウェアサプライチェーンの安全性が保証されるわけではないとしています。

イスラエルINCDは、サプライチェーン対策としてサプライヤーからSBOMとVEXを取得することや、サーバーレス環境のソフトウェア構成をSBOMで記録し、脆弱性スキャン・対応プロセスへ組み込むことを推奨しています。

情報システム・セキュリティ部門が確認したいポイント

SBOMを導入する場合、最初に「SBOMを作ること」を目的にしない方が運用を設計しやすくなります。

確認したいポイントは次の通りです。

• どの製品・システムのSBOMが必要か
• 内製・委託開発・購入ソフトウェアをどこまで対象にするか
• SBOMの生成主体は誰か
• SPDX・CycloneDXなど、どの形式を利用するか
• コンポーネントと依存関係をどこまで取得できるか
• ソフトウェア更新時にSBOMをどう更新するか
• CVEなどの脆弱性情報とどう照合するか
• VEXをどのように受け取り、管理するか
• サプライヤーへSBOM提供をどのように要求するか
• 脆弱性が見つかった場合に誰が影響確認と修正判断を行うか

SBOMは「ソフトウェアに何が含まれているか」を可視化する仕組みです。その情報を脆弱性管理、調達、委託先管理、インシデント対応へ接続して初めて、企業の運用で利用できる状態になります。

出典

• Minimum Elements for a Software Bill of Materials (SBOM) – CISA
• Software Security in Supply Chains: Software Bill of Materials (SBOM) – NIST
• Software Bill of Materials – NIST CSRC Glossary
• Software Bill of Materials – NTIA
• The Minimum Elements For a Software Bill of Materials (SBOM) – NTIA
• SBOMs and the importance of inventory – UK National Cyber Security Centre
• Israel National Cyber Directorate CERT-IL Alert 1934 – INCD
• Serverless architecture security – Israel National Cyber Directorate