企業に6つのBOMプログラムは要らない。必要なのは「エビデンスグラフ」ひとつだ

インフラやセキュリティのプログラムで、可視化プロジェクトが決まった道をたどるのを何度も見てきました。最初のダッシュボードが完成すると、成果が出たように感じます。やがてデータが増え、責任の所在があいまいになり、チームは気づきます。IDも対応アクションも伴わない可視化は、運用すべき新たな管理対象にすぎなかったのです。

部品表（BOM）プログラムは、いままさにその段階に差しかかっています。

多くのCIOはソフトウェア部品表（SBOM）をご存じでしょう。SBOMは、ソフトウェアのコンポーネント、ライセンス、脆弱性、サプライヤーのリスクを調査するのに役立ちます。その対象は広がりつつあります。暗号部品表（CBOM）は、アルゴリズム、証明書、プロトコル、鍵管理の依存関係を特定します。AI・機械学習向けのBOMは、モデル、データ、評価、サービング基盤を記述します。登場しつつある認可部品表（Authorization BOM）は、人、ワークロード、サービス、AIエージェントが何を実行できるかを示すことを目指しています。さらに、ワークフロー、バイナリ、振る舞いのインベントリが、プロセス、配布された成果物、ランタイムの視点を補います。

手っ取り早い対応は、インベントリごとに別々のプログラムを割り当てることです。しかし私は、これでは運用モデルとして誤っていると考えます。企業に必要なのは、6つのバラバラなBOMリポジトリではありません。専門分野ごとの記録を組み合わせて、ひとつのビジネス上の問いに答えられるようにする、共通のエビデンス契約です。

インシデントの問いは組織の壁を越える

重大なライブラリの脆弱性が公表されたとき、経営幹部は自社がSBOMをいくつ収集したかを尋ねません。知りたいのは次のような点です。どの製品が影響を受けるのか。そのコードはデプロイされ、到達可能なのか。どの顧客が危険にさらされているのか。そのサービスはどのデータにアクセスし、どんな操作ができるのか。誰が対処の責任を負うのか。組織はどれだけ素早くリスクを封じ込められるのか。

単一のBOMでは、これらに答えられません。判断は、ソフトウェア、暗号、ID、ワークフロー、デプロイ、モデル、ランタイムのエビデンスにまたがるからです。

AIエージェントを例にとると、この溝が分かりやすくなります。モデルのインベントリからは、プロバイダーとバージョンが分かるかもしれません。ところが、そのエージェントが本番環境のツールを呼び出せたり、機微なメモリを読み取れたり、別のエージェントに処理を委任できたり、人の承認なしに実行できたりすれば、リスクは変わります。コンポーネントの一覧が示すのは、何が存在するかです。何が起こり得るかを示すのは、認可とワークフローのエビデンスです。

標準が高めるのはエビデンスの質であり、運用モデルではない

CISAが主導した2026年のSBOM最小要素の更新では、来歴と品質に関する情報が強化されました。具体的には、生成時のコンテキスト、ツールとフォーマットの詳細、コンポーネントのハッシュ、ライセンス、カバレッジ、既知の未知（known unknowns）などです。SPDX 3.0.1はモジュール式のプロファイルを提供します。ECMA-424として標準化されたCycloneDX 1.7は、ソフトウェア、暗号資産、機械学習モデル、サービス、フォーミュレーション、脆弱性、BOM間の関係を表現できます。

規制面の圧力も、議論を任意の可視化から、根拠を示せるエビデンスへと移しつつあります。EUのサイバーレジリエンス法は、デジタル要素を含む製品の製造者に対し、コンポーネントの特定と文書化を求めています。これには、少なくとも最上位の依存関係を網羅した、機械可読なSBOMが含まれます。

とはいえ、相互運用性があるからといって、事実としての正確さや運用での使いやすさが保証されるわけではありません。収集ツールによって、コンポーネントや依存関係のパスの判定が食い違うことがあります。形式上は正しい文書でも、ソースコードを記述していてもリリース済みのバイナリは記述していない場合や、承認済みのアーキテクチャを記述していても実際に稼働中のデプロイは記述していない場合があります。直接の権限は記述していても、推移的な権限は記述していないこともあります。

だからこそ、CIOの旗振りが重要です。エビデンスは、プロダクトエンジニアリング、クラウド基盤、サプライヤー、ID管理チーム、AIガバナンス、マネージドサービスプロバイダーから、それぞれ異なるタイミングで届きます。CIOはこうした境界をまたいで契約を確立できます。どの対象にエビデンスが必要か、どの識別子を正とするか、記録をどの頻度で更新するか、どの署名を信頼するか、どの差異に判断が必要かを定めるのです。

調達にも同じ契約を使うべきです。サプライヤーには、対応するプロファイル、エビデンスの生成方法、変更の頻度、開示しない情報、脆弱性やライフサイクルの更新の伝達方法を明示してもらいます。コンポーネント、暗号の依存関係、モデル、サービス、リモートアクセス経路に重要な変更があれば、年次レビューを待たずに通知を発動させるべきです。

契約には、保証の尺度も必要です。サプライヤーが自己申告したエビデンス、第三者が検証したエビデンス、顧客が観測したエビデンス、ランタイムでの観測結果を、同じ重みで扱うべきではありません。この区別は、2つの記録が食い違ったときに重要になります。サプライヤーの署名付き声明は出所と完全性を証明しますが、収集ツールがすべてのコンポーネントを見つけたことや、顧客の環境がリリース済み製品と今も一致していることまでは証明しません。エビデンスの区分を記録しておけば、暗号署名が裏付ける範囲を超えた主張にすり替わるのを防げます。

責任の所在も、見える状態を保つ必要があります。コンポーネントのインベントリはプロダクトエンジニアリング、脆弱性の扱いはセキュリティ、実効的な権限はIAM、デプロイ状態は運用が担う、といった分担が考えられます。グラフはこうした責任分担を維持しつつ、インシデント対応のリーダーに、エビデンスをたどるひとつの道筋を与えるものであるべきです。すべてのソースを一元化する必要はありません。ただし、一貫した識別と判断ルールは欠かせません。

連合型のエビデンスグラフを構築する

私が勧めるのは、連合型の設計です。各ドメインのプロファイルはネイティブな形式のまま維持し、元のエビデンスを保存します。そのうえで、小さな共通のエンベロープと関係グラフで結び付けます。

すべての記録で、次の項目を特定できるようにすべきです。正確な対象、バージョン、ダイジェスト。プロファイルとスキーマのバージョン。生成元とツール。ライフサイクルのフェーズ。生成時と観測時のコンテキスト。作成日時、有効期間、失効日時。網羅性と既知の未知。機微度。責任者。暗号による完全性。関係は、型を持ち、方向と範囲があり、期間が限定されたものにします。

既存の仕様で、基盤の多くはまかなえます。CycloneDXとSPDXは、ドメインごとの記録を結び付けられます。SLSAの来歴とin-totoは、成果物がどのようにビルドされたかを記述できます。社内の署名基盤やSigstoreを使えば、声明を生成元と対象に紐付けられます。VEXとCSAFは、悪用可能性と修正状況を記録できます。OpenID AuthZEN 1.0は、認可の相互運用に向けて、サブジェクト、アクション、リソース、コンテキスト、決定のセマンティクスを定めています。OSCALは、機械可読なエビデンスを統制項目に結び付けられます。

目的は、あらゆる技術を導入することではありません。企業全体が尊重する、少数のエビデンスのセマンティクスに合意することです。

90日間のパイロットで構想を検証できる

企業全体の分類体系づくりから始めるのではなく、まずは重要なサービスをひとつ選んでください。

1. 1か月目：ソース、ビルド、成果物、デプロイの各SBOMを収集します。暗号の依存関係を特定し、クラウドとアプリケーションの実効的な権限をエクスポートします。重要なワークフローをひとつ取得し、サービスがAIを使っていればモデルのエビデンスも加えます。安定した識別子と責任者を割り当て、各コレクターが見えない範囲も記録します。
2. 2か月目：プロファイル同士を接続し、エビデンスに署名します。宣言されたコンポーネントを、リリース済みのバイナリおよびデプロイと比較します。承認済みの認可を、実効的な権限や最近行使された権限と比較します。設計上のワークフローを、観測された呼び出しと比較します。成果は、説明のつく差異の短いリストであるべきで、責任者のいない数千件の指摘が並ぶダッシュボードではありません。
3. 3か月目：重要な差異をポリシーに結び付けます。想定外の重要なコンポーネントは、責任ある担当者が期限付きの例外を記録しない限りブロックします。権限の拡大には、承認と有効期限を必須とします。対応する来歴を伴わないモデル、ワークフロー、外部サービスの変更は、レビューの対象とします。

最後に演習を行います。脆弱なコンポーネント、過剰な権限、未承認のワークフロー呼び出しを仕込み、影響を受けるデプロイ、到達可能なリソース、責任者、封じ込めのアクションを特定するまでの時間を測定します。

グラフは機微なインフラとして扱う

つながったエビデンスグラフは、サプライヤー、価値の高いID、信頼関係、モデルの依存関係、運用上の経路を明らかにします。アクセス制御が甘ければ、攻撃者にとっての地図になりかねません。

開示は必要最小限にとどめたビューを使います。認証情報、秘密鍵、生のシークレット、独自のデータセット、制限のない認可パスは、広く配布するインベントリに含めないでください。完全なエビデンスが不要な場合は、ハッシュ、属性、署名付きの証明を共有します。エビデンス基盤そのものにも、分類、保持期間、アクセスログ、職務分掌を適用してください。

文書ではなく意思決定を測定する

CIO向けのダッシュボードが示すべき指標は、重要サービスのカバレッジと鮮度、検証済みエビデンスの割合、プロファイル間のリンクの完全性、影響範囲の特定にかかる時間、想定外の権限やランタイムのドリフト、失効の伝播時間、例外の経過期間、サンプリングによる正確性です。収集したSBOMファイルの数を先頭に掲げるべきではありません。

この取り組みの可能性は、コンプライアンスにとどまりません。つながったエビデンスは、インシデントのトリアージを短縮し、サプライヤーレビューを改善し、AIガバナンスやゼロトラストをより測定しやすくします。監査人にも、運用の実態により近い視点を提供できます。企業に必要なのは、新たなインベントリプロジェクトではありません。何が存在し、何が起こり得て、何が起きたのか、そしてその状態が承認されているのかを確立する、信頼できる方法です。