SOC 2プラットフォームはコントロールの運用を示し、CRACIはビルドの中身を記録します。

このページが扱う構成

多くのSaaSチームが同じ構成にたどり着きます。SyftやTrivyなどの生成ツールがCIでSBOMを作成し、脆弱性スキャナーがリポジトリを監視し、コンプライアンス自動化プラットフォームがGitHubやクラウドアカウントに接続してSOC 2のエビデンスを収集する、という構成です。これは機能します。監査人も受け入れますし、監査前の1週間をスクリーンショット撮りに費やす必要もありません。

こうしたプラットフォームはこの用途に優れています。Vantaは「クラウド、ID、コード、デバイスのツールに読み取り専用で接続」し、「エビデンスを自動的に取得してコントロールにマッピング」するとしており、1,200件を超える自動テストを1時間ごとに実行しています。Drataは「クラウドインフラ、IDプロバイダー、人事システム、コードリポジトリ、チケット管理ツールなど」に接続し、エビデンスを収集してSOC 2のコントロールにマッピングします。目的がきれいなSOC 2レポートであれば、それが適切なツールです。

このページが扱うのは、もっと絞られた問いです。そのエビデンスは、SBOMそのものについて何を語っているのでしょうか。

SOC 2のチェックが実際に問うこと

SOC 2の検証は、AICPAのトラストサービス規準（Trust Services Criteria）に照らして報告されます。SBOMに最も近い規準はCC7.1です。

「目的を達成するため、事業体は検知および監視の手続を用いて、（1）新たな脆弱性をもたらす構成の変更、および（2）新たに発見された脆弱性への影響を受けやすい箇所を特定する。」

AICPA, 2017 Trust Services Criteria, CC7.1

この規準が示すのは結果です。方法や、その裏付けとなるコンポーネント一覧の深さは、お客様と監査人に委ねられています。そのため自動テストが通常問うのは、コントロールが整備され運用されているかどうかです。スキャナーは接続されているか、実行されたか、検出結果はポリシーどおりに処理されたか。これは妥当な問いであり、まさにチェックボックスです。

チェックが問わないのは、スキャンの元になったSBOMが、リリースに含まれていたものをすべて記載していたかどうかです。SBOMに一度も記載されなかったコンポーネントにある脆弱性は何とも照合できないため、スキャン結果は問題なしとなり、コントロールは緑のままです。

緑のチェックと完全なSBOMが分かれるところ

SBOM生成ツールは目の前にあるファイルをもとに動作し、その欠落がどこに生じるかは各ツール自身のドキュメントが示しています。

• ロックファイルをコミットしていないexpressjs/express 5.2.1では、ロックファイルから依存関係を解決する生成ツールには解決する対象がありません。それでもドキュメントは返せます。GitHub Actionsやワークフローファイルなど、ほかに認識したものは記載されますが、package.jsonで宣言されたnpmの依存関係は1つも含まれません。
• 生成ツールはそれぞれ何をコンポーネントとみなすかを独自に決めるため、同じチェックアウトからでも異なる一覧を返します。GitHubの依存関係グラフのエクスポートはさらにかけ離れています。GitHubがリポジトリについて把握している情報から作られ、固定したコミットではなくデフォルトブランチを読み取るためです。
• NTIAのサプライヤー項目は、ほとんどのドキュメントで空欄になります。ほとんどの生成ツールにはその情報源がないためです。

どのツールも壊れているわけではありません。それぞれ指示されたファイルを読み取り、標準フォーマットで有効なドキュメントを予定どおり作成しました。コンプライアンステストから見れば、コントロールは運用されています。それでもSBOMはソフトウェアを記述していなかったのです。

CRACIがエビデンスに加えるもの

CRACIはGitHub Actionsのランナーを置き換えます。runs-onをcraciに変更するだけで、実行結果は引き続きGitHubのUIに表示されます。SBOMはビルド中にそのランナー内で生成されます。パッケージを認識するプロキシがパッケージソースへの通信を監視するため、記録にはファイル上で取り込むはずのものではなく、ジョブが実際に取り込んだものが反映されます。

完全性は推定ではなく明示

すべてのジョブとキャッシュに、Complete、Complete with connections、Incomplete、Unavailable、Not recordedの5つの完全性の状態のいずれかが付きます。依存関係のエビデンスはキャッシュと一緒に引き継がれるため、ウォームキャッシュから復元されたパッケージも黙って抜け落ちることなく記録に残ります。記録が不完全な場合は、そのことが明示されます。

これは標準の方向性とも一致しています。CISAとそのパートナーによる2026年版のSBOM最小要素は、項目を黙って空欄にするのではなく、SBOM作成者に「その情報がSBOM作成者にとって不明であるかどうかを明示する」ことを求めています。

監査人が受け取れるフォーマットのエビデンス

SBOMは、コンポーネントで見つかった脆弱性を含めてCycloneDXまたはSPDXでエクスポートできます。公開REST APIからはSBOM、ジョブのネットワークトレース、来歴データを取得できるため、同じ記録を監査エビデンスの保管先にそのまま渡せます。

どこに何がデプロイされているかのインベントリ

CRACIのインベントリビューでは、どのソフトウェアのバージョンがどの製品にデプロイされているかを、グローバルに正確に確認できます。新たな脆弱性が公開されたとき、リリースノートやスプレッドシートをつなぎ合わせなくても、影響を受けるバージョンを実行している製品がわかります。

SOC 2プラットフォームはそのままに

CRACIはコンプライアンス自動化プラットフォームではなく、その代わりにもなりません。ポリシー、アクセスレビュー、デバイスチェック、ベンダー質問票は管理しません。両者は異なる問いに答えます。コンプライアンスプラットフォームは、コントロールが存在し運用されていることを示します。CRACIは、ビルドが何を取り込んだかを記録し、その記録が完全かどうかを示します。

EUでソフトウェアを販売するようになると、この違いはさらに大きくなります。Cyber Resilience Actはメーカーに対し、「一般的に使用される機械可読なフォーマットで、少なくとも製品のトップレベルの依存関係を対象とするソフトウェア部品表を作成すること」によってコンポーネントを特定し文書化するよう求めています（附属書I、パートII）。附属書VIIはSBOMを技術文書に含め、市場監視当局がその提出を求められるようにしています。SOC 2レポートは組織がコントロールをどう運用しているかを証明するものです。CRAのSBOMは特定の製品を記述するものです。スケジュールはCRAの概要で、CRACIが自動化する内容はCRAコンプライアンスのページでご覧いただけます。CRACIは、より広いCRAコンプライアンスのプロセスに必要なサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけでコンプライアンスが達成されるわけではありません。

同じエビデンスはISO 27001とNIS2にも役立ちます。管理策ごとの対応表はISO 27001、SOC 2、NIS2のエビデンスとしてのSBOMをご覧ください。

監査に影響を与えずに試す方法

1. SBOMがすでにSOC 2のエビデンスに使われているリポジトリを1つ選びます。
2. runs-onをcraciに変更して、そのリリースワークフローをCRACIに向けます。
3. 記録されたSBOMと現在生成しているSBOMをコンポーネント単位で比較し、ジョブの完全性の状態を確認します。
4. その違いをエビデンスに含めるべきかを判断します。

ビルド時のSBOM生成やCRAのエビデンスについて詳しくご覧いただけるほか、セキュリティのページでは当社自身のコントロールをどう文書化しているかをご確認いただけます。