SBOM
SBOMとは？
SBOM（ソフトウェア部品表）とは、ソフトウェアに含まれるコンポーネントを機械可読な形で一覧にしたものです。すべてのライブラリ、パッケージ、依存関係が、バージョン、提供元、ライセンスとともに記載されます。食品でいえば原材料表示にあたります。新たな脆弱性が公開されたとき、SBOMがあれば、影響を受けるコンポーネントを出荷しているかどうかを数分で確認できます。
更新日
SBOMは何の略か
SBOMはSoftware Bill of Materials（ソフトウェア部品表）の略です。この用語は製造業に由来し、部品表（Bill of Materials）は製品を構成する部品を一覧にしたものです。CISAはSBOMを、ソフトウェアコンポーネントを構成する要素を並べた入れ子構造のインベントリと説明しています。
現代のアプリケーションのコードの大半は他者が書いたもので、その多くは間接的に入ってきます。パッケージを1つ追加すると、それが数十もの推移的依存関係を連れてきます。SBOMはそのすべてを書き留めるため、リポジトリを1つも読まずに「影響を受けるか」に答えられます。
SBOMには何が含まれるか
有用なSBOMは2つの部分で構成されます。SBOM自体に関するデータと、各コンポーネントに関するデータです。2026年7月29日にCISA、NSA、FBIが国際的なパートナーとともに公表した2026 Minimum Elementsは、2021年のNTIAのリストに代わるもので、現在多くの購入者が参照する基準となっています。
| 区分 | フィールド |
|---|---|
| SBOMについて | 作成者と作成者の署名、タイムスタンプ、データフォーマットの名称とバージョン、ツールの名称とバージョン、SBOMのバージョン、生成のコンテキスト |
| 各コンポーネントについて | 名称、バージョン、提供元、パッケージURLやCPEなどの識別子、ハッシュ値とアルゴリズム、ライセンス、依存関係のつながり |
生成のコンテキストは見た目以上に重要です。SBOMがいつ作成されたか、つまりビルド前、ビルド中、完成した成果物から、またはその後のいずれかを示します。同じリリースの2つのSBOMが異なるのは、まさにこの理由によることがあります。実際のファイルでこれらのフィールドがどう見えるかはSBOMの例をご覧ください。受け取ったファイルはSBOM品質チェックリストで確認できます。
SBOMのフォーマット
使われているSBOMのほぼすべては2つのフォーマットでカバーされます。OWASPのCycloneDXはセキュリティ分野から始まり、脆弱性やサービスも記述できます。Linux FoundationのSPDXはライセンスコンプライアンスから始まりました。どちらも最小要素を記載でき、多くのツールは両方を出力します。選び方についてはCycloneDXとSPDXの比較をご覧ください。
SBOMが重要な理由
- インシデント対応の迅速化。Log4Shellのような脆弱性が公開されたとき、問題はどの製品にそれが含まれているかです。SBOMがあれば検索1回で済みますが、なければ一大プロジェクトになります。
- リリース後の脆弱性監視。出荷時には問題のなかったソフトウェアも、明日には脆弱になりえます。保存したSBOMを新しいアドバイザリと照合し直せば、何も再ビルドせずにそれを検出できます。
- ライセンスリスク。各コンポーネントの宣言ライセンスにより、コピーレフトや商用の条件が製品に入り込む前にわかります。
- 顧客や規制当局からの質問。調達時にSBOMを求める購入者は増えており、いくつかのフレームワークはコンポーネントのインベントリを想定しています。
SBOMが必要なのは誰か
ソフトウェアを出荷するすべての企業、そしてその中身について説明責任を負うすべての人です。要件は通常、次のいずれかを通じて求められます。
- 医療機器。FDAのセクション524Bは、サイバーデバイスの市販前申請にSBOMを求めています。
- EUで販売される製品。Cyber Resilience ActはメーカーにSBOMを求めています。CRAのSBOM要件とツールをご覧ください。
- 米国連邦政府の調達。2026年1月のOMBメモM-26-05により、要求するかどうかは各機関が判断することになったため、ケースバイケースで求められると考えてください。
- 決済ソフトウェア。PCI DSS 4.0の要件6.3.2は、独自開発ソフトウェアとそのサードパーティコンポーネントのインベントリを求めています。SBOMを指定しているわけではありませんが、SBOMはその要件を満たします。
SBOMの生成方法
作成方法は3つあり、どの方法を選ぶかでファイルの中身が決まります。
| 方法 | 読み取る対象 | よくある欠落 |
|---|---|---|
| ソースをスキャン | リポジトリ内のマニフェストとロックファイル | ビルドが取得するもののうち、どのロックファイルにも記載されないもの |
| 出力をスキャン | 完成したコンテナイメージまたはバイナリ | コンパイル済みのコードは判別が難しく、ビルドツールは痕跡を残さない |
| ビルドを記録 | ビルドが実行中に実際に取得したもの | 記録を迂回する通信（フラグを立てるべきもの） |
Syft、Trivy、cdxgenなどのオープンソースの生成ツールは、最初の2つの方法を使います。それぞれが何を読み取るかについて独自のルールを持つため、同じコミットに対しても結果が互いに一致しません。選択肢を並べて比較するにはおすすめのSBOMツールをご覧ください。
SBOM、SCA、VEXの違い
- SBOMはインベントリです。何があるかを示すもので、それが安全かどうかは示しません。
- ソフトウェアコンポジション解析は分析です。コンポーネントを見つけてリスクを確認するもので、多くのSCAツールはその過程でSBOMも生成します。
- VEXは影響に関する表明です。既知の脆弱性が実際に製品に影響するかどうかを示し、SBOMだけでは生じるノイズを減らします。
SBOMの生成自体は簡単
誰も読まないファイルは何も変えません。価値は、リリースごとにSBOMを1つ保管し、それらを監視し、必要なときに見つけられるようにして初めて生まれます。その作業がSBOM管理で、運用方法はSBOMのベストプラクティスで解説しています。
CRACIによるSBOMの作成
CRACIはGitHub Actionsのランナーで、各ジョブが取得するすべてのパッケージを、依存関係ツリーのあらゆる階層で、CIキャッシュから復元されたパッケージも含めて記録します。その結果、リリースを生成したビルドのSBOMが得られ、ジョブが見ることのできなかったものを示す完全性の状態が付きます。SBOMはCycloneDXまたはSPDXでエクスポートでき、CRACIは新たな脆弱性が公開されるたびに再評価し続けます。ビルド時SBOM生成をご覧ください。
SBOMに関するよくあるご質問
SBOMを簡単に説明すると何ですか？
SBOMはソフトウェアの原材料表示です。製品に含まれるすべてのコンポーネントを、バージョン、提供元、ライセンスとともに、機械が読み取れる形式で記載します。
SBOMは何の略ですか？
SBOMはSoftware Bill of Materials（ソフトウェア部品表）の略です。
なぜSBOMが必要なのですか？
新たに公開された脆弱性が出荷するものに影響するかをすばやく判断し、リリース前にライセンスリスクを把握し、製品の中身を尋ねる顧客や規制当局に回答するためです。
SBOMの2つの主要なフォーマットは何ですか？
CycloneDXとSPDXです。CycloneDXはOWASP発でセキュリティ分野から始まりました。SPDXはLinux Foundation発でライセンスコンプライアンスから始まりました。どちらも最小要素を記載できます。
SBOMは法律で義務付けられていますか？
製品と市場によって異なります。FDAのセクション524BはサイバーデバイスにSBOMを義務付けており、EUのCyber Resilience ActはメーカーにSBOMを求めています。米国連邦政府の調達では、現在は各機関の判断に委ねられています。多くの企業にとっては、法的な要件というより顧客からの要件です。
SBOMはどのくらいの頻度で更新すべきですか？
ビルドごとに異なるバージョンが取り込まれる可能性があるため、リリースごとに新しいSBOMを生成してください。リリースのSBOMはその後変わりませんが、新たな脆弱性との照合は続けるべきです。
SBOMは誰が作成しますか？
通常はソフトウェアをビルドするチームです。各リリースで自動的に作成されるよう、CIで行うのが理想的です。購入するソフトウェアには、サプライヤーからSBOMが提供されるべきです。