SBOMの完全性

SBOMが完全であるとは、対象ソフトウェアに入ったすべてのコンポーネントを、依存関係ツリーのあらゆる階層で、ロックファイルやマニフェストに記載されないものも含めて記載していることです。SBOMの完全性とは、この性質を指します。CISAの2026 Minimum Elementsは、情報が不明な場合にはそれを明示するようSBOMの作成者に求め、コンポーネントの重要なデータが伏せられていれば受け手はSBOMを不完全とみなしうると述べています。

完全性、有効性、品質は別のもの

問い	意味	確認するもの	わからないこと
有効	ファイルがCycloneDXまたはSPDXのスキーマに準拠している	スキーマバリデーター	コンポーネントの欠落
フィールド品質	各コンポーネントに名前、バージョン、供給者、識別子、ライセンス、ハッシュがある	品質スコアリングツール	コンポーネントの欠落
完全	ソフトウェアに入ったものが何も欠けていない	ビルドが実際に取り込んだものとの比較	比較で見えなかった入力

2行目の識別子は、通常Package URLかCPEです。ファイルは最初の2つのチェックを完璧に通過しても、ソフトウェアの半分を記載していないことがあります。

完全性を後から測るのが難しい理由

スキャナーは、ロックファイル、マニフェスト、または完成した出力を基に動きます。ポストインストールスクリプトがダウンロードしたパッケージ、バイナリに組み込まれたクレート、見せられたことのないベースイメージのレイヤーについては知りようがありません。いずれも隠れた依存関係です。

ロックファイルに400個のパッケージが載っているNode.jsサービスを考えてみましょう。そのうち1つにpostinstallスクリプトがあり、npm ciの実行中にビルド済みバイナリをダウンロードします。package-lock.jsonから生成したSBOMは有効で、各コンポーネントにバージョンとPackage URLがありますが、そのバイナリは含まれていません。ファイルのどこにも欠けているものを示す手がかりがないため、品質スコアはこれを指摘できません。

後で再ビルドしても答えは出ません。そのビルドが再現可能なビルドでない限り、2回目のビルドは1回目と異なるものを取り込む可能性があります。

完全性を正直に示す方法

• 生成のコンテキストを示します。 SBOMが、ビルド前にソースコードから作られたのか、ビルド中に記録されたのか、ビルド後に出力を解析して作られたのかを明記します。
• 既知の欠落を列挙します。 ベンダリングされたコード、ビルド済みバイナリ、パッケージマネージャー以外でインストールされたコンポーネントなど、ツールが見られなかった部分です。
• スコアより理由付きの状態を優先します。 完全性の割合には総数が必要ですが、その総数こそ誰にもわかりません。「不完全：ジョブが監視されていない通信を許可した」のような表明なら、対応につなげられます。

SBOMが見られなかったものを明示する実務全般は、SBOMのベストプラクティスで扱っています。

CRACIの完全性の状態

CRACIは各ジョブのSBOMに完全性の状態を付け、キャッシュにも状態を付けます。CRACIのドキュメントでの定義は次のとおりです。

• Complete：「CRACIはジョブについて完全な証跡を確認し、復元されたキャッシュもすべて完全でした。」
• Complete with connections：「要件は満たしていますが、ジョブが1つ以上のカスタムネットワーク接続を使用しました。」
• Incomplete：「CRACIは、依存関係がSBOMから漏れる可能性のある条件を検出しました。」
• Unavailable：「CRACIは証跡の評価を完了できませんでした。」
• Not recorded：「このジョブは完全性レポート機能の導入前に実行されました。」

CRACIがこれを示せるのは、各ジョブのパッケージソースへの通信を見ているため、監視していない通信や、自身のSBOMが不完全だった復元キャッシュなど、何かが記録をすり抜けた可能性がある場合にそれがわかるからです。ジョブが不完全な場合は、「Unmonitored traffic was allowed」のようにその理由が表示されます。SBOM生成を参照してください。

これらの状態は、CRACIのランナーで実行されるビルドに適用されます。サプライヤーから受け取ったSBOMや、CRACIで実行されないパイプラインのSBOMについては、上記の比較方法とルールを使ってください。