近年、欧州サイバーレジリエンス法（EU Cyber Resilience Act：CRA）への対応検討をきっかけに、調達要件やセキュリティ監査の場面で、SBOM（Software Bill of Materials）の提出を求められるケースが増えています。SBOMを調べるとまず目にするのが「NTIAが定義したSBOMの最小要素（Minimum Elements）」[i]です。これは大統領令14028（2021年）を受けて取りまとめられたSBOMに最低限含めるべき項目と運用上の考え方を示した文書で、その後のガイダンスの基礎となっています。
SPDXやCycloneDXなどの標準フォーマットに対応したツールを使えば、最小要素の大半は出力の時点でカバーされるため、日常的にSBOMを扱っている方が原文をわざわざ確認する機会はほとんどありません。問題になるのは、「このSBOMは本当に正しいのか」を説明しなければならない場面です。そのときの判断基準になるのが、最小要素の「実務・プロセス」の観点です。
本記事では、SBOMの最小要素について概要を説明し、なぜ実務では最小要素を意識しないのか、どのような場面で必要になるのか、ツールの出力と最小要素のギャップをどう埋めるか、そして2025年の最新ガイダンスで何が変わったのかを順に整理します。
最小要素とは、SBOMを組織やツール間で共有・活用できるものにするために、NTIAが定めた最低限の要件です。
「SBOMに入れるべきデータ項目の一覧」と思われがちですが、実は3つの観点で構成された枠組みです。表に各観点と主な要件を示します。
|
観点 |
主な要件・内容 |
|
データフィールド （Data Fields） |
サプライヤー名、コンポーネント名、バージョン、一意識別子（CPE/PURL等）、依存関係、SBOMデータの作成者、タイムスタンプの7項目を記録すること |
|
自動化対応 （Automation Support） |
SPDX、CycloneDX、SWIDのいずれかの機械可読な形式で出力し、ツール間で処理・連携できること |
|
実務・プロセス （Practices & Processes） |
SBOMの作成頻度、SBOMの深さ（依存関係の記載範囲）、既知の未知（Known Unknowns）の明示、SBOMの共有方法、アクセス管理、誤りの許容に関する運用方法を定めること |
実務でSBOMを生成・共有するうえで、最小要素を意識する場面はほとんどありません。主要フォーマットに対応したツールが、最小要素で定められた内容の多くをすでに取り込んでいるためです。
コンポーネント名、バージョン、依存関係、作成日時など「データフィールド」の項目はツールが自動で出力し、形式もJSON/XMLなど機械可読な形式で出力されるため「自動化対応」の要件も満たされます。3つの構成要素のうち「データフィールド」と「自動化対応」は、ツールを選んだ時点でおおよそ解決済みです。ただし、サプライヤー名など一部の項目は出力されないこともあるため、出力結果の確認は必要です。
さらに、日常のSBOM生成・活用の場面では「最小要素の定義に沿っているか」ではなく、「脆弱性管理プロセスに組み込めるか」が重視されます。そのため、定義より先に、互換性のあるSBOMを作れるツールとフォーマットを選定するほうが実務では有効です。
ツールの進化がSBOM導入のハードルを下げてくれたのは間違いありません。その反面、ツールが出した結果をそのまま信用することが常態化し、出力内容を疑う発想が抜け落ちやすくなっているのも事実です。
最小要素が必要になるのは、ツールの出力が本当に正しいのか判断しなければならない場面です。日常的にはツールがSBOM生成を担ってくれますが、その出力をどこまで信用してよいかは、ツール自身が保証してくれるものではありません。
たとえば、脆弱性スキャンで脆弱性が検出されたため、SBOM上の依存関係を確認したところ、推移的依存が含まれていなかったとします。それが「意図的に除外した」のか「ツールが拾えなかった」のかで、対応はまったく変わります。SBOMに記載のない依存関係が「本当に存在しない」のか「検出できなかった」のかが区別できないのも、同じ問題です。
ツールは「SBOMの中身」は生成してくれても、「このSBOMをどう読むべきか」という前提条件までは付けてくれません。
そこで最小要素の「実務・プロセス」が判断基準になります。依存関係の範囲や不明情報の扱いを作成者が明示しておけば、受け取った側は「推移的依存は含まれていない」「この項目はツールが検出できなかった」と判断できます。最小要素はSBOMの抜けをなくすためのものではなく、抜けの意味を伝えるためのものです。なぜ記載がないのかが明示されていれば、受け取った側は根拠を持って判断できます。
ギャップを埋める方法は、ツールの出力に「作成の前提条件」を人が補記することです。何を対象に解析したか、不明情報はなぜ不明なのか。こうした情報はツールが自動で付けてくれないため、作成者が判断して記録する必要があります。
ツールが「何を対象に解析したか」を記録しておきます。ソースコード解析なのか、ビルド成果物の解析なのか、対応する言語やパッケージマネージャの範囲も含めて残しておくことで、受け取った側が対象を正確に判断できます。ツールによってはメタデータに出力される場合もありますが、組織をまたいだやり取りでは別途補足を添えておくと伝わりやすくなります。
ツールが「不明」「未検出」と出力した項目について、なぜ不明なのかを明示します。
技術的にツールが検出できなかった（例：非標準のパッケージマネージャを使っている）
ビジネス上の理由で意図的に非公開としている
コンポーネントの性質上、その情報が存在しない（例：特定のサプライヤーを持たないOSS）
この区別がないと、「不明」と書いてある部分がリスクとして対処すべきなのか、そもそも心配する必要がないのか、受け取った側は判断が困難です。
「直接依存だけ含めるのか」「推移的依存も含めるのか」「開発用ツールの依存も対象か」を組織としてルール化しておきます。用途によって粒度を変える場合は、それぞれの基準を文書化しておくことが重要です。
NTIAがSBOMの最小要素を公開したのは2021年[ii]です。それから4年、SBOMの普及が進み、実運用でぶつかる課題が見えてきたことを受けて、CISAが2025年に新たなガイダンスのドラフト（2025 Minimum Elements for a Software Bill of Materials (SBOM) [iii]）を公開しました。
大きな方向転換ではなく、3つの構成要素（データフィールド・自動化対応・実務プロセス）の枠組みは維持されています。変わったのは、要求される透明性の水準です。
|
観点 |
2021 (NTIA) |
2025 (CISA Draft) |
|
データフィールド |
7項目 |
4項目を新規追加し11項目に拡充 |
|
不明点の扱い |
UnknownとRedactedの区別なし |
UnknownとRedactedを明示的に区別 |
|
SaaS / AI の扱い |
ほぼ言及なし |
SBOMが扱える範囲の限界を明文化※ |
※SBOMが扱える範囲の限界をDiscussionとして言及
特に大きな変化としては、不明情報の区別が厳格になった点です。2021年版では「わからなければ不明と書く」程度でしたが、2025年版では以下の区別を求めています。
Unknown（不明）：SBOM作成者が把握できていない情報
Redacted（非開示）：把握しているが、意図的に開示しない情報
「把握できていない」のと「開示しない」のとでは、受け取った側の対応がまったく違います。前者であれば技術的な問題として、後者であれば開示の是非を判断する問題として、それぞれ切り替えられます。
この区別を明確に求めるようになったのは、SBOMが「作れるようになった段階」から「使って判断する段階」へ移行しているためです。
日常のSBOM生成・活用の場面では、ツールとフォーマットが最小要素の大部分をカバーしてくれるため、最小要素を意識する機会はほとんどありません。その一方で、依存関係の抜けや不明情報の扱いについて確認が必要な場面などでは、最小要素の考え方が判断の拠り所になります。
ツールは「SBOMの中身」を生成してくれますが、「このSBOMをどう読むべきか」という前提条件までは付けてくれません。その部分を人が補い、作成の前提条件を説明できる状態にしておくことが、実務での信頼性につながります。
最小要素は「データ項目のチェックリスト」ではなく、SBOMをどう解釈すべきかを示すものです。ツールがSBOMの生成を担ってくれる今だからこそ、その前提を整えることが重要になると考えています。
SBOMの導入や運用設計についてご検討の際は、お気軽に当社までご相談ください。
[i] The Minimum Elements For a Software Bill of Materials (SBOM) | National Telecommunications and Information Administration
[ii] Executive Order 14028 – Improving the Nation’s Cybersecurity (2021)
[iii] 2025 Minimum Elements for a Software Bill of Materials (SBOM) | CISA