SBOM
SBOM品質チェックリスト:サプライヤーから届いたSBOMの検証方法
確認すべきことは3つです。ファイルが有効か、フィールドが使えるか、そして何かが欠けていないか。1つ目はスキーマバリデーターが、2つ目はフィールドチェックと品質スコアが検出しますが、3つ目はファイルを読むだけのツールでは証明できません。以下のチェックリストでは、すべてのチェックをNTIAの2021年の最小要素、CISAの2026年のMinimum Elements、BSI TR-03183-2に対応づけ、テスト方法と、サプライヤーに送るフィードバックの文面を示します。
更新日
SBOM品質の3つの層
| 層 | 問い | 何で確認するか | わからないこと |
|---|---|---|---|
| 有効 | ファイルを解析でき、宣言しているフォーマットとバージョンのスキーマに従っているか | スキーマバリデーター | 各フィールドに役立つ値が入っているかどうか |
| 使える | 必要なフィールドがそろっていて、ツールで利用できるか。アドバイザリと照合できる識別子、ライセンス、ハッシュ、関係など | フィールドチェック、コンプライアンスプロファイル、品質スコア | ファイルに何が欠けているか |
| 完全 | 受け取ったソフトウェアに含まれるものをすべて列挙しているか | ビルドとの比較、または納品されたバイナリの解析との比較 | SBOMだけを読むものには答えられません |
受け取る側のチームの多くは、1つ目の層で止まっています。「ファイルが検証を通る」はチェックの出発点であり、結果ではありません。3つ目の層がSBOMの完全性です。
1分でわかるフレームワーク
依頼とフィードバックのたびにフレームワーク名を明記してください。そうすれば基準は公開されたものになり、あなたの意見ではなくなります。
- NTIA、The Minimum Elements for a Software Bill of Materials (2021年7月12日)。7つのデータフィールド(サプライヤー名、コンポーネント名、バージョン、その他の一意な識別子、依存関係、SBOMデータの作成者、タイムスタンプ)、SPDX、CycloneDX、SWIDタグによる自動化のサポート、そしてプラクティスとして、頻度、深さ、既知の未知、配布と提供、アクセス制御、誤りへの対応を定めています。ハッシュ、ライセンス、ライフサイクルフェーズ、署名は、最小要素を超える推奨事項として挙げられています。
- CISA、2026 Minimum Elements for a Software Bill of Materials (2026年7月29日。2025年8月22日の草案を経て公開)。NTIAの要素に代わるものです。CISA、NSA、FBI、ドイツのBSI、日本のMETIとNCOを含む14か国の18組織が作成しました。データフィールドは17あり、そのうち10が新規です。SBOM author signature、data format name、data format version、generation context、tool name、tool version、SBOM version、component hash value、component hash algorithm、component licenseです。「Supplier name」は「Component Producer」(コンポーネントの作成者)になりました。プラクティスは、カバレッジ、不明な情報の明示、機械処理可能なデータ、更新への対応、頻度、配布と提供です。文書は各要素を「should」で記述し、新たな要件を生み出すものではないとしています。購入者は契約に書き込むことで、これを拘束力のあるものにします。
- BSI、TR-03183-2 バージョン2.1.0(2025年8月20日、ドイツ)。3つの中で最も厳格で、MUSTで書かれています。JSONまたはXML、CycloneDX 1.6以降またはSPDX 3.0.1以降、ソフトウェアのバージョンごとに1つのSBOM、各依存関係リストの完全性を明記した依存関係の再帰的な解決、デプロイ可能な各コンポーネントのSHA-512ハッシュ、コンポーネントのファイル名、SPDX識別子による配布ライセンス、そしてpackage URLまたはCPE(「if it exists」)を求めます。また、SBOMに脆弱性情報を含めてはならないとしています。それはVEX文書またはアドバイザリに記載するものです。
- 国際的な連携。 A Shared Vision of SBOM for Cybersecurity (2025年9月3日)には、15か国の18組織が署名しています。SBOMに関するG7の取り組みはAIシステムを対象としており(「A shared G7 vision on SBOM for AI」、2025年、「SBOM for AI – Minimum Elements」、2026年5月)、組み込み機器のサプライヤーSBOMについては要件を定めていません。
- 自動車業界。Auto-ISACは2025年2月11日にSBOM Informational Reportを公開しました。
チェックリスト
セルの読み方:必須は、文書がmustとしていることを意味します。最小要素は、その文書の最小リスト(NTIAのベースライン、またはCISAの「should」要素)に含まれていることを意味します。推奨は、文書が最小要素を超えて挙げていることを意味します。記載なしは、文書が求めていないことを意味します。各チェックのテスト方法と送るべきフィードバックの文面は、次のセクションで説明します。
SBOMレベルのチェック
| チェック | 重要な理由 | NTIA 2021 | CISA 2026 | BSI TR-03183-2 |
|---|---|---|---|---|
| 1. 解析でき、宣言されたスキーマに対して検証を通る | ツールで読めないファイルはSBOMではありません | 必須:SPDX、CycloneDX、またはSWIDタグ | プラクティス:機械処理可能なSPDXまたはCycloneDX | 必須:JSONまたはXML |
| 2. 仕様バージョンが自社の下限を満たす | 古いバージョンでは必要なフィールドを表現できません | 記載なし | 最小要素:データフォーマットの名前とバージョン。非推奨のバージョンは避ける | 必須:CycloneDX 1.6以降またはSPDX 3.0.1以降 |
| 3. SBOMの作成者 | 内容に責任を持つ者がいる | 最小要素:「Author of SBOM Data」 | 最小要素:「SBOM Author」。ツールではなく組織 | 必須:「Creator of the SBOM」、メールアドレスまたはURL |
| 4. タイムスタンプ | どのSBOMが最新かがわかる | 最小要素 | 最小要素 | 必須。UTCを推奨 |
| 5. ツールの名前とバージョン | SBOMが何をカバーしていると信頼できるかがわかる | 記載なし | 最小要素 | 記載なし |
| 6. 生成コンテキスト | 同じリリースでも、ソーススキャンとビルドの記録は異なる | 推奨:ライフサイクルフェーズ(「source」「build」「post-build」) | 最小要素:「before build」「build」「after build」 | フィールドなし。内容はビルド中に利用可能だったものと一致しなければならない |
| 7. SBOMのバージョンまたはシリアル番号 | 修正版を元の版と区別できる | 記載なし | 最小要素:「SBOM Version」 | フォーマットにあれば必須:「SBOM-URI」 |
| 8. 作成者の署名 | ファイルがサプライヤーから改変されずに届いたことを示す | 推奨:署名が奨励されている | 最小要素:「SBOM Author Signature」 | 参考情報のみ:「ideally」署名 |
| 9. トップレベルのコンポーネントが受け取ったものと一致する | 間違ったリリースのSBOMは、ないよりも悪い | 最小要素:主要コンポーネント | 最小要素:対象コンポーネント | 必須:ツリーのルートである主要コンポーネント |
コンポーネントレベルのチェック
| チェック | 重要な理由 | NTIA 2021 | CISA 2026 | BSI TR-03183-2 |
|---|---|---|---|---|
| 10. コンポーネント名 | あらゆる照合で最初に使われる | 最小要素 | 最小要素 | 必須。名前がなければファイル名 |
11. バージョン:latest、unknown、空の値がない |
アドバイザリはバージョン範囲に対して適用される | 最小要素 | 最小要素。不明ならその旨を記載 | 必須。バージョンがなければファイルの日付 |
| 12. 作成者またはサプライヤー | 同じ名前の2つのコンポーネントを区別でき、誰が修正するかがわかる | 最小要素:「Supplier Name」 | 最小要素:「Component Producer」 | 必須:「Component creator」、メールアドレスまたはURL |
| 13. エコシステムにあればpackage URL、なければCPE。どちらも正しい形式 | 識別子(package URL、CPE)がなければ、脆弱性データベースと何も照合できない | 最小要素:「Other Unique Identifiers」。CPE、SWID、PURLなど、存在する場合 | 最小要素:CPEやPURLなど少なくとも1つの識別子。すべてを含める | 存在すれば必須:CPEまたはpurl |
| 14. ハッシュ値とアルゴリズムが、受け取ったファイルと一致する | このSBOMがこのバイナリを記述していることを証明する | 推奨 | 最小要素:実行可能なアーティファクトのハッシュ。NISTなどの機関が承認したアルゴリズムを使用 | 必須:デプロイ可能なコンポーネントのSHA-512 |
15. ライセンスがSPDX識別子または式で記載され、一律のNOASSERTIONがない |
ライセンスの専門家はこれをもとにコピーレフトなどの義務を判断する | 推奨 | 最小要素。可能な限りSPDX識別子 | 必須:配布ライセンス。SPDX識別子を優先 |
| 16. 依存関係と、そのリストが完全かどうか | 脆弱なパッケージを何が取り込んだか、そして欠落を信頼してよいかがわかる | 最小要素。直接の依存関係がすべて列挙されている場合はその旨を記載 | 最小要素 | 必須。各リストの完全性を明記 |
| 17. ファイル名 | エントリをデバイス上のファイルに結びつける | 記載なし | 記載なし | 必須 |
| 18. 実行可能、アーカイブ、構造化の各プロパティ | 各コンポーネントがどのような種類のファイルかがわかる | 記載なし | 記載なし | 必須 |
カバレッジのチェック
| チェック | 重要な理由 | NTIA 2021 | CISA 2026 | BSI TR-03183-2 |
|---|---|---|---|---|
| 19. トップレベルだけでなく、推移的な深さまで | 脆弱なコードの多くは間接的に入り込む | トップレベルは必須、推移的依存関係は推奨 | カバレッジのプラクティス:推移的依存関係を含める。最小の深さは定めない | 必須:再帰的な解決 |
| 20. 既知の未知が明記されている | 欠落を明記したSBOMは、列挙している内容については信頼できる | 必須のプラクティス | プラクティス:不明な情報と開示しない情報を明示 | 完全性の記載を通じて必須 |
| 21. 納品するソフトウェアのバージョンごとに1つのSBOM | 重要なのは実際に稼働しているバージョン | 必須:ビルドまたはリリースごとに新しいSBOM | プラクティス:頻度 | 必須 |
| 22. 修正は新しいSBOMとして送る | 黙って修正された誤りは追跡できない | プラクティス:誤りへの対応 | プラクティス:更新への対応 | 必須:誤りを修正したら更新したSBOM |
| 23. 妥当性:重複がない、コンポーネント数が製品に見合う、Linuxベースのデバイスならオペレーティングシステムのパッケージがある | 完全性を確かめる最も安価な方法 | 記載なし | カバレッジのプラクティス:複数のインスタンスを個別に列挙 | 複数のインスタンスを個別に列挙しなければならない |
各チェックのテスト方法と、サプライヤーへの伝え方
| チェック | 自動テストの方法 | サプライヤーへのフィードバック |
|---|---|---|
| 1、2. スキーマと仕様バージョン | 宣言されたフォーマットとバージョンに対応するスキーマバリデーター。次にspecVersion(CycloneDX)またはSPDXのバージョンを自社の下限と比較 |
「ファイルは、記載したパスでCycloneDX 1.6のスキーマ検証に失敗しています。ジェネレーターで再生成し、送付前に検証してください。」 |
| 3~7. 作成者、タイムスタンプ、ツール、コンテキスト、バージョン | 必要なメタデータがあること。CycloneDXではmetadata.authors、metadata.timestamp、metadata.tools、metadata.lifecycles、serialNumber、version、SPDXでは作成情報 |
「SBOMに、作成したツールと生成コンテキストが記載されていません。どちらもCISA 2026 Minimum Elementsです。」 |
| 8. 署名 | 署名があり、サプライヤーが公開した鍵で検証できること | 「CISA 2026の要素SBOM Author Signatureのとおり、SBOMに署名するか、分離署名を送ってください。」 |
| 9. トップレベルのコンポーネント | metadata.component(CycloneDX)または記述対象のルート要素(SPDX)の名前とバージョンが、受け取った品番とソフトウェアバージョンと一致すること |
「このSBOMはバージョン5.2.0を記述していますが、当社が受け取ったのは5.3.0です。5.3.0のSBOMを送ってください。」 |
| 10、11. 名前とバージョン | 空の名前がないこと。不明と宣言されていない限り、空、latest、unknownのバージョンがないこと |
「14のコンポーネントにバージョンがありません。正確なバージョンを記載するか、不明であることを明示してください。」 |
| 12. 作成者 | 各コンポーネントにサプライヤー、製造者、または作成者があること | 「コンポーネントに作成者がありません。CISA 2026の要素Component Producerが求めているものです。」 |
| 13. 識別子 | すべてのpurlがECMA-427準拠のpackage URLライブラリで解析できること。すべてのCPEがCPE 2.3の正しい構文で、NVDのCPE辞書に存在すること |
「package URLまたはCPEを持つコンポーネントがないため、脆弱性データベースと照合できません。パッケージマネージャー由来のすべてのパッケージにpurlを追加してください。」 |
| 14. ハッシュ | デプロイ可能な各コンポーネントにSHA-512のエントリがあること。受け取ったファイルのsha512sumを計算して比較 |
「SBOMにハッシュがありません。BSI TR-03183-2は、デプロイ可能な各コンポーネントのSHA-512を求めています。」 |
| 15. ライセンス | SPDXライセンスリストで解決できるライセンスIDまたは式。NOASSERTIONと空の値の数を数える |
「コンポーネントの92%がライセンスとしてNOASSERTIONを記載しています。SPDXライセンス識別子を記載してください。」 |
| 16. 依存関係 | dependenciesグラフ(CycloneDX)または依存関係(SPDX)。CycloneDXのcompositions(aggregate値を持つもの)など、完全性の記載 |
「SBOMがフラットなリストになっています。依存関係を含め、各リストが完全かどうかを記載してください。」 |
| 17、18. ファイル名とファイルのプロパティ | BSI TR-03183-2が各フォーマットに定めるプロパティがあること | 「BSI TR-03183-2 v2.1.0の要件に従い、ファイル名と、実行可能、アーカイブ、構造化の各プロパティを追加してください。」 |
| 19~23. カバレッジ | 依存関係グラフの深さ、重複の検出、類似製品とのコンポーネント数の比較、製品タイプごとに想定されるコンポーネント | 「LinuxベースのディスプレイのSBOMに、カーネル、ブートローダー、ベースシステムのパッケージが記載されていません。イメージ全体のSBOMを送ってください。」 |
フィードバック文面の割合や件数は例です。実際の数値を入れ、毎回フレームワークとバージョンを明記してください。
合格スコアでも見逃すもの
ファイルは検証を通り、10点中9点を取っても、製品の半分が抜けていることがあります。品質スコアは存在するフィールドを読むだけで、存在しないコンポーネントは見えません。
具体例。サプライヤーがLinuxベースのディスプレイのSBOMを送ってきました。CycloneDX 1.6として有効で、すべてのコンポーネントにバージョン、package URL、ライセンス、SHA-512ハッシュがあり、依存関係グラフも正しい形式です。ディスプレイのアプリケーションと40のライブラリが列挙されています。しかし、Linuxカーネル、ブートローダー、ベースシステムのパッケージは1つも記載されていません。フィールドチェックはすべて通ります。それでもこのSBOMは、Linuxデバイスで監視が欠かせないカーネルのCVEには役に立ちません。カーネルが含まれていないからです。
受け取る側のチームが完全性を確かめる方法:
- 納品されたファームウェアのバイナリ解析と比較する。サプライヤーのSBOMが十分な品質になるまでの代わりとして、またその後のクロスチェックとして使うOEMもあります。
- 製品タイプごとに想定されるコンポーネントを確認する。Linuxイメージにはカーネル、Cライブラリ、initシステムがあり、産業用コントローラーにはプロトコルスタックがあります。
- 生成コンテキストとツールを尋ねる。ソーススキャンでは、ビルドが取得したものは見えません。
- SBOMが、受け取ったソフトウェアを作成したビルドから得られたものか尋ねる。それが3つ目の層を決める問いです。
小さなSBOMが正当な場合もあります。独自ファームウェアとベンダーのキャリブレーションを搭載したベアメタルのECUなら、正直にコンポーネントが2つということもあります。SBOMがその旨を述べ、既知の未知を明記しているなら、サイズを理由に減点せず受け入れてください。
チェックを自動化するツール
2026年11月11日にGitHubで確認しました。いずれのリポジトリもアーカイブされていません。
| ツール | チェックする内容 | チェックしない内容 | 状況 |
|---|---|---|---|
| CycloneDX CLI | CycloneDX 1.0~1.7のスキーマ検証(JSONまたはXML)。CI向けの--fail-on-errors |
SPDX、フィールドの品質、フレームワークのプロファイル | v0.33.1、2026年7月 |
| sbom-utility | CycloneDX 1.2~1.7とSPDX 2.1~2.3のJSONのスキーマ検証。独自のスキーマバリアントにも対応 | SPDX 3、XML、フレームワークのプロファイル | v0.19.2、2026年6月 |
| SPDX tools-java | SPDX 2.0~2.3と3.0.1に対するVerify |
CycloneDX、フレームワークのプロファイル | v2.0.7、2026年6月 |
| SPDX tools-python | pyspdxtools -i:SPDX 2.2と2.3の完全な検証 |
SPDX 3の読み込み(サポートは実験的) | v0.8.5、2026年3月 |
| SPDX NTIA Conformance Checker | SPDX 2.2、2.3、3.0をNTIA 2021、CISA FSCT3、BSI TR-03183-2 v2.1.0に照らして確認。Web版もあり | CycloneDX。CISA 2026は要望として未対応 | v6.0.0、2026年10月 |
| sbomqs | 識別、来歴、完全性(integrity)、網羅性、ライセンス、脆弱性、構造にわたる0~10のscore。CISA 2026、NTIA 2021、BSI TR-03183-2 v1.1~v2.1.0、FSCT v3、OpenChain Telco向けのcomplianceプロファイル |
欠けているコンポーネントの検出 | v2.1.3、2026年10月。CISA 2026プロファイルはv2.1.0から、v2.1.2で修正 |
| sbom-scorecard | 仕様への準拠、生成情報、パッケージの識別子、バージョン、ライセンスの加重スコア | フレームワークのプロファイル | 0.0.7、2023年4月が最後のリリース |
現時点でCISA 2026 Minimum Elementsをチェックできるのはsbomqsだけです。プロファイルに頼る前に、各ツールのリリースノートを確認してください。sbomqs 2.1.1では、CISA 2026のフラグが誤って2021年のチェックを実行していました。sbomqsでBSI TR-03183-2 v2.1.0を確認するには、--bsi-v21または--bsiを使います。--bsi-v2はv2.0.0をチェックします。
サプライヤーのCycloneDX SBOMを受け入れる最小限のステップ:
# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors
# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json # CISA 2026 Minimum Elements
# 3. Track field quality over time
sbomqs score supplier-sbom.json
# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin
SPDXでは、NTIA Conformance Checkerのsbomcheck -s spdx3 -c bsi supplier-sbom.jsonを使います。コンプライアンスレポートを読み、自社の要件で必須としているチェックに失敗したファイルは差し戻し、上記のフィードバック文面とともにサプライヤーに返してください。
サプライヤー要件への書き込み
サプライヤーが一度も目にしていないチェックリストは、要件ではありません。契約の付属書に盛り込みましょう。
- フレームワークとバージョン:たとえば「BSI TR-03183-2 v2.1.0」や「CISA 2026 Minimum Elements」。1つを明記し、「業界標準」とは書かないでください。
- フォーマットと仕様の最低バージョン:たとえばCycloneDX 1.6以降、またはSPDX 3.0.1以降、JSON。
- 上乗せで求めるフィールド:SHA-512ハッシュや、すべてのパッケージのpackage URLなど。
- 納品:納品するソフトウェアのバージョンごとに1つのSBOMを、ソフトウェアより前か同時に。
- サプライヤーが送付前に行う検証:ツールとプロファイルを明記。
- フィードバックの流れ:誰がフィードバックを受け取り、修正したSBOMをいつまでに出すか。
同じ合意のサプライヤー側についてはサプライヤー向けSBOMガイドをご覧ください。1回限りの依頼に答えるソフトウェアベンダーの場合は、顧客からのSBOM提出依頼をご覧ください。
フィードバックのテンプレート
件名:[品番]、ソフトウェアバージョン[バージョン]のSBOM:修正のお願い
[日付]にお送りいただいたSBOMを、当社のサプライヤー要件[参照番号]に定める[フレームワークとバージョン]に照らして確認しました。スキーマ検証は通りますが、次のチェックに失敗しています:[チェック番号とフィードバック文面]。SBOMの新しいバージョンとタイムスタンプを付けた修正版を、[日付]までにお送りください。それまでは、当社独自のバイナリ解析に基づいてこのソフトウェアを監視します。ご質問は[連絡先]までお願いします。
不合格のSBOMの直し方(サプライヤー向け)
- 手書きのファイル。テキストエディターではなく、ジェネレーターかSBOMライブラリを使ってください。
- package URLがない。手作業ではなく、パッケージマネージャーやビルドから生成してください。手で入力したpurlは推測したpurlです。
- ライセンスがない。パッケージのメタデータから宣言されたライセンスを取得し、SPDX識別子で記載してください。
- ハッシュがない。ビルドの最後に、実際に納品するファイルに対して計算してください。
- リリースが違う。リリースビルドでSBOMを生成し、バージョンにちなんだ名前を付けてください。
- トップレベルだけ。推移的依存関係を解決する方法を使ってください。
完全性と識別子をまとめて直す最も確実な方法は、納品したソフトウェアを作成したビルドからSBOMを生成することです。ビルド時SBOMとSBOMのベストプラクティスをご覧ください。
良いSBOMはどこから生まれるか、そしてCRACIの役割
GitHub Actionsでビルドしているサプライヤー向けに、CRACIはGitHubホステッドランナーを置き換え、ビルド中にSBOMを記録します。そのため、SBOMにはビルドが実際に取り込んだものが列挙されます。
- すべてのパッケージにpackage URL、すべてのコンポーネントに宣言されたライセンス。
- ビルドが到達したあらゆる深さの推移的依存関係。
- すべてのジョブに完全性の状態。ビルドごとに既知の未知の問いに答えます:Complete、Complete with connections、Incomplete、Unavailable、Not recorded。
- CycloneDXまたはSPDXでエクスポート。SBOM APIはCycloneDX 1.7のJSONを返します。
エンジニアリング組織全体についてはSBOM生成の標準化を、組み込みLinuxについてはスキャナーがYoctoビルドの中身を見逃す理由をご覧ください。
OEMは、サードパーティのSBOMをCRACIに追加できます。そのため、購入したコンポーネントも自社のビルドと並べて新たな脆弱性を監視できます。比較についてはSBOM管理ツールをご覧ください。
CRACIが適さない場合
- 受け取ったSBOMの検証とスコアリング。CRACIはSBOMバリデーターや品質スコアを提供していません。上記のツールを使ってください。
- CIを使っていないサプライヤー、またはパッケージを取得しないモデルベースツールでコードを生成しているサプライヤー。ビルドの記録はほとんど役に立たず、ジェネレーターライブラリで作成した検証済みのSBOMが現実的な答えです。
- バイナリでしか受け取らないファームウェア。それにはバイナリ解析が答えます。
- 署名付きSBOM、つまりCISA 2026の作成者の署名。CRACIはSBOMに署名しません。
SBOMの品質と検証:よくあるご質問
サプライヤーから届いたSBOMの品質はどう確認すればよいですか?
3つの層をテストします。ファイルをスキーマに対して検証し、BSI TR-03183-2やCISA 2026 Minimum Elementsなどの特定のフレームワークに照らしてフィールドを確認し、最後に完全性を確かめます。受け取ったもののバイナリ解析と比較し、製品タイプに必ず含まれるはずのコンポーネントがあるかを確認してください。
SBOMにはどのフィールドが必要ですか?
指定するフレームワークによります。CISAの2026年のMinimum Elementsは17のフィールドを挙げており、作成者、タイムスタンプ、ツール、生成コンテキスト、そしてコンポーネントごとの名前、バージョン、作成者、識別子、ハッシュ、ライセンスが含まれます。BSI TR-03183-2はさらにSHA-512ハッシュ、ファイル名、ファイルのプロパティを加え、それらを必須としています。
NTIAの最小要素とCISAの2026年のMinimum Elementsでは何が変わりましたか?
CISAの2026年のリストは、NTIAの7つのフィールドを17に置き換えました。新たに加わったのは、作成者の署名、データフォーマットの名前とバージョン、生成コンテキスト、ツールの名前とバージョン、SBOMのバージョン、コンポーネントのハッシュ値とアルゴリズム、コンポーネントのライセンスです。Supplier nameはComponent Producerになり、深さはカバレッジになりました。
BSI TR-03183-2はSBOMに何を求めていますか?
バージョン2.1.0は、JSONまたはXMLのCycloneDX 1.6以降かSPDX 3.0.1以降、ソフトウェアのバージョンごとに1つのSBOM、完全性を明記した再帰的な依存関係、そしてコンポーネントごとに作成者、名前、バージョン、ファイル名、ライセンス、SHA-512ハッシュ、ファイルのプロパティを求め、package URLまたはCPEが存在すればそれも求めています。
SBOMにハッシュは必要ですか?アルゴリズムは?
NTIAは推奨していました。CISA 2026はハッシュを最小要素とし、NISTなどの機関が承認したアルゴリズムを求めています。BSI TR-03183-2は、デプロイ可能な各コンポーネントのSHA-512を必須としています。SHA-512を求め、受け取ったファイルと比較してください。
CPEとPURLの両方が必要ですか?
必ずしもそうではありません。エコシステムにあればpackage URLを、なければCPEを求めてください。多くの商用コンポーネントや組み込みコンポーネントはCPEになります。CISA 2026は少なくとも1つの識別子と、わかっているものすべてを求めています。BSIは、存在するものはそれぞれ必須としています。
CycloneDXやSPDXのファイルはどう検証しますか?
CycloneDXなら、--fail-on-errorsを付けたcyclonedx-cli validate、またはsbom-utility。SPDXなら、SPDX tools-javaのVerifyコマンド、SPDX 2.2と2.3ならpyspdxtools。そのうえで、sbomqsかSPDX NTIA Conformance Checkerでフレームワークのプロファイルを実行します。
SBOMの品質スコアは何点なら良いのですか?
標準的なしきい値はなく、当社が引用できるベンチマークもありません。スコアが測るのは存在するフィールドであり、完全性ではありません。10点中9点でも製品の半分が抜けていることがあります。代わりにサプライヤー要件でチェックごとの合格基準を定め、スコアは傾向として追ってください。
OEMにSBOMを納品していますか?ビルドから生成しましょう
デモをご予約いただき、GitHub ActionsのビルドをCRACIで実行してみてください。ビルドが取り込んだもののSBOMを、パッケージごとのpackage URLと完全性の状態付きで入手できます。
デモを予約