SBOMフィールド実践ガイド：NTIAの7要素を超えて何を記載すべきか

7要素は入口であり、上限ではない

SBOMの記載方法を議論するとき、話はたいていNTIAの7要素リスト――サプライヤー、コンポーネント名、バージョン、一意識別子、依存関係、SBOM作成者、タイムスタンプ――で止まってしまう。この7項目を確認し終えると、作業は完了したと判断されがちである。

2021年の行政命令 EO 14028 が施行されたばかりの時期には、その判断もかろうじて成立していたかもしれない。しかし、FDAが2023年3月から医療機器の市販申請に完全なSBOMの添付を義務付け、EU CRAが2027年12月に全面適用されて最大1,500万ユーロまたはグローバル売上高の2.5%の制裁金を課す体制となり、自動車分野でUN R155 / ISO 21434および国内強制規格GB 44495が相次いで発効した今、「最低限の要件」という7要素の位置付けはますます機能しなくなっている。

問題は7要素が誤っているということではない。実務では極めて記載ミスが生じやすく、かつ7要素を埋めた後もSBOMの実用的価値を左右する多くのフィールドが見過ごされているという点にある。本稿では「必須」から「強く推奨」の順に各フィールドを解剖し、高頻度の落とし穴を明示する。SBOMの生産または消費を担当するエンジニアやコンプライアンス担当者の実務参考として活用されたい。

---

各フィールド解剖：7要素でよくある記載ミス

1. サプライヤー名（Supplier Name）――最も曖昧になりやすいフィールド

実務で最も解釈の揺れが生じやすいフィールドである。同一コンポーネントに対して、上流には複数の「サプライヤー」としての立場が存在しうる：オリジナル作者、パッケージメンテナー、ミラー配布者、社内での二次ラッパー担当者などである。

典型的な落とし穴：パッケージレジストリ名（例：npmjs.com）をサプライヤーフィールドに記載したり、Gitユーザー名と法人主体を混在させたりするケースがある。社内フォークやプライベートミラーの場合、サプライヤーフィールドには上流名称をそのまま転記するのではなく、内部識別子を明記すべきである。そうしなければ、脆弱性対応時に「このコンポーネントは誰がメンテナンスしているのか」を迅速に判断することができない。

SPDX（ISO/IEC 5962）では PackageSupplier フィールドが Organization: と Person: のプレフィックスをサポートしており、CycloneDX（Ecma標準）は supplier と author をより細かく区別している。下流の消費側と選定方針をすり合わせ、パース時の曖昧さを排除することが重要である。

2. コンポーネントバージョン（Version）――「バージョンなし」は空欄の免罪符にならない

ソースコードからビルドされtagが付いていない社内コンポーネントの場合、バージョンフィールドを空にすると脆弱性マッチングが完全に機能しなくなる。正しい対処は、Gitコミットのショートハッシュ（最低12桁）を記載し、補足フィールドでバージョン取得元の種別を説明することである。

3. 一意識別子（Unique Identifier）とハッシュ――両者は相互代替できない

一意識別子（PURLまたはCPE）は「これはどのコンポーネントか」という問いに答え、ハッシュは「コンポーネントのどのビルド成果物か」という問いに答える。両者は不可欠であるにもかかわらず、混同されたり片方だけ記載されたりすることが多い。

PURL（pkg: 形式）は、npm・Maven・PyPI・Cargoなど主要パッケージマネージャーをカバーするエコシステム横断の事実上の標準となっている。CPEは政府調達やNVDの脆弱性マッチングシナリオでは依然として代替不可能な地位を持つ。

ハッシュアルゴリズムの選定も重要である。MD5とSHA-1は完全性検証の用途としてはすでに不十分であり、SHA-256が現在の最低要件であり、高セキュリティレベルの場合はSHA-512を使用すべきである。ハッシュの対象が圧縮アーカイブなのか展開後のファイルツリーなのかを明記しておかないと、両端での検証が必ず食い違う。スニペットレベルSCAとマニフェストレベルSCAの違いはここで特に重要になる――マニフェストは宣言バージョンを示すにすぎず、実際に使用されているコードが宣言と一致することを証明できるのはハッシュだけである。

4. 依存関係（Dependency Relationships）――深さが不十分では記載したも同然

7要素の中で情報密度が最も低く、最も形式的に済まされやすいフィールドである。直接依存のみを宣言して推移的依存を展開しないと、SBOMの脆弱性カバレッジは大幅に低下する。Log4Shell（CVE-2021-44228、2021年12月）が広範に拡散した大きな理由のひとつは、多くの組織が自分たちのアプリケーションスタックの何層もの推移的依存を通じてlog4j-coreが持ち込まれていることを把握していなかった点にある。

実践上の推奨事項：

• 推移的依存は少なくとも3層まで展開すること。セキュリティ上重要なシステムでは全量展開を推奨する
• DEPENDS_ON で一律に記載するのではなく、DYNAMIC_LINK・STATIC_LINK・CONTAINS などの関係種別を区別して記載する
• 開発依存（devDependency）とランタイム依存は必ず別々に標記する。買い手がリスク評価を行う際の着眼点がまったく異なるためである

5. SBOM作成者とタイムスタンプ――ライフサイクル管理の出発点

タイムスタンプは「SBOMがいつ生成されたか」を示すだけでなく、この文書がいつ失効とみなされるべきかを決定する。created（初回生成日時）と documentNamespace 内のバージョン識別子を併記し、CI/CDパイプラインと連携してビルドごとに自動更新する運用を推奨する。一度きりの手動管理文書として扱ってはならない。

---

7要素を超えて：実用性を左右するフィールド

7要素で基盤を固めた後、以下のフィールドがSBOMを機械的に消費可能にし、脆弱性対応を支援し、監査要件を満たすかどうかを決める。

ライセンスフィールド（License）

SPDX License Expressionは複合表現（例：Apache-2.0 AND MIT）をサポートしており、パッケージメタデータで宣言された DeclaredLicense と、スキャンツールで実際に確認された ConcludedLicense の両方を記載すべきである。両者が一致しない場合は自動上書きではなく人手によるレビューが必要である。ライセンス競合検出の実践手法は別途詳しく論じる価値がある。

ライフサイクル状態（Lifecycle / EOL）

Python 2は2020年に正式にEOL、AngularJSは2022年にEOL、Log4j 1.xに至っては2015年にすでにメンテナンスが終了している――にもかかわらず、これらのコンポーネントは今日でも本番環境のSBOMに大量に登場し、EOL状態を示すフィールドがまったく記載されていない。CycloneDXの lifecyclePhase フィールドとカスタム属性でこの情報を表現できるため、必須項目として扱うことを推奨する。メンテナンス終了オープンソースコンポーネントのリスクについては専門的な評価が必要である。

VEX連携フィールド――脆弱性悪用可能性のコンテキスト

VEX（Vulnerability Exploitability eXchange）はSBOM本体の構成要素ではないが、SBOMと高度に結合している。VEXを伴わないSBOMが脆弱性アドバイザリに直面したとき、消費者には「コンポーネントにそのCVEが存在する」という事実しか伝わらず、「現在のデプロイ環境で実際に悪用可能かどうか」を判断できない。

VEXの4つのコアステータス――not_affected・affected・fixed・under_investigation――は、影響ステートメント（impact statement）と対処ステートメント（action statement）と組み合わせて初めて完全な脆弱性対応チェーンを構成する。EU CRAの報告義務（2026年9月11日から発効）は、製造者に悪用可能性評価の提供を明示的に求めており、VEXは現時点で最も成熟した機械可読の媒体である。

ビルド情報とSLSA出自（Provenance）

コンポーネントがどのようにビルドされたか、どのパイプラインから生成されたか、ビルド環境は再現可能か――これらの情報は、サプライチェーン汚染シナリオ（2024年3月に発覚したxzバックドア CVE-2024-3094 など）において決定的な遡及調査価値を持つ。CycloneDXの externalReferences および buildMetaData フィールドとSLSA出自文書を組み合わせることが、現時点で最も実行可能な記載経路である。

---

買い手と売り手：非対称な優先事項

SBOMの生産者（ソフトウェア売り手）と消費者（調達側・運用側）では、フィールドの優先度判断に明確な非対称性が存在する。この非対称性を契約段階でアラインしておかなければ、脆弱性対応時に深刻な摩擦を生む。

売り手が通常重視する点：

• フィールドがコンプライアンス提出要件（FDA・CRA・GB 44495）を満たしているか
• 生成ツールチェーンのカバレッジと自動化の程度
• 内部の機密情報（自社開発コンポーネント名、内部トポロジー）の匿名化が必要かどうか

買い手が通常重視する点：

• ハッシュが検証可能かどうか（SBOMと実際の納品物が一致することの担保）
• 推移的依存が完全に展開されているかどうか
• VEXが脆弱性アドバイザリに合わせて継続的に更新されているか、一度きりの添付文書になっていないか
• EOLコンポーネントに明確な標記と移行計画があるかどうか

調達契約または技術附属書において、SBOMフォーマットのバージョン、更新頻度、VEX対応の期限、争点となりやすいフィールド（特にサプライヤー名とバージョン）の記載規則を明示的に取り決めることを推奨する。SBOMをコンプライアンス要件から能力構築へと発展させる経路には、より包括的なガバナンスフレームワークの参考情報が記載されている。

バイナリ納品物を扱う買い手にとって、SBOMの宣言内容だけでは実際の構成を検証することはできない。CleanBinaryのバイナリ成分分析機能は、成果物の側からSBOMの正確性を逆検証することができる。開発フェーズからSBOM生成規範を確立したいチームには、600以上のパッケージ管理エコシステムと3.2億件のコンポーネントフィンガープリントに基づく全量依存解析を提供し、SPDXおよびCycloneDX形式で直接出力できる CleanSource SCA が有効である。軽量な導入にはコミュニティ版の CleanSource SCA CE を選択することもできる。PureStream はコンプライアンスガバナンス層においてAI駆動のポリシーオーケストレーションを提供しており、チームを横断してSBOM品質のベースラインを統一したいシナリオに適している。

---

まとめ：フィールドの品質がSBOMの実質的な価値を決める

SBOMの価値はフィールドの数ではなく、各フィールドが正確であること、機械可読であること、コンポーネントのライフサイクルを通じて継続的にメンテナンスされることにかかっている。7要素が揃っていてもハッシュが検証できず、依存関係が一層しかなく、サプライヤー名が前後で不一致なSBOMは、脆弱性対応時に提供できる情報が極めて限られる。

xzバックドアからShai-Hulud npmワーム（2025年9月）に至るまで、サプライチェーン攻撃の手口は継続的に進化している。防御側の情報品質は、少なくとも攻撃面の複雑さと同等のペースで向上させなければならない。SBOMを一度きりのコンプライアンス文書から継続的に更新されるソフトウェア部品表へと変えるには、フィールド規範が出発点であり、ツールチェーンの自動化が保証であり、買い手と売り手の契約上の取り決めがつなぎとなる。

SBOMの完全な体系構築については「SBOM完全ガイド」を、医療機器分野の具体的なコンプライアンス経路については医療機器SBOMコンプライアンス実践を参照されたい。

---