依存関係はすでにスキャンしている。では、スキャナーに見えないものとは。

現在のツール群の強み

SCAとSBOM生成をすでに設定しているなら、組織として最も難しい部分はもう済んでいます。依存関係は追跡され、アドバイザリは開発者に届き、求められたときに渡せるファイルもあります。それは維持してください。

• GitHubの依存関係グラフとDependabotは、多くのチームでデフォルトで有効になっています。GitHubは依存関係グラフを「リポジトリに保存されたマニフェストファイルとロックファイル、および依存関係送信APIを使ってリポジトリに送信された依存関係の概要」と説明しています。Dependabotアラートはこれを基盤とし、新しいアドバイザリが公開されたときや依存関係グラフが変化したときに通知します。
• Snykなどの商用SCAもSBOMを生成します。そのsnyk sbomコマンドはマニフェストファイルとそのロックファイルを読み取り、CycloneDXまたはSPDXを出力します。2026年9月時点で、Snykはこれを「Snyk Enterpriseプランのお客様のみ利用可能」と記載しています。
• Syft、Trivy、cdxgenなどのオープンソースの生成ツールは無料で高速、CIへの追加も簡単です。Syftは自らを「コンテナイメージとファイルシステムからソフトウェア部品表（SBOM）を生成する」ためのツールと説明しています。

これらのツールが最も力を発揮するのは、プルリクエストへの素早いフィードバック、幅広いエコシステムへの対応、そして開発者が使い慣れた修正ワークフローです。CRACIは現時点でそれを置き換えるものではありません。CRACIの脆弱性トラッキングは、ビルドとリポジトリをまたいで検出結果を集約し、新たな脆弱性の公開に応じて監視対象のSBOMを再評価します。セキュリティチームは検出結果をトリアージし、適切なチームに割り当てられます。ポリシーゲートでビルドをブロックでき、脆弱性のWebhookはロードマップに掲載されています。

スキャナーと記録装置

上に挙げたツールはすべてスキャナーです。ソースツリー、ロックファイル、コンテナイメージを指定すると、何が入ったかを推測します。ファイルがすべてを物語っている場合はそれで機能します。しかし、そうでない場合は難しくなります。

• リポジトリにロックファイルがなく、バージョンはインストール時に決まる。
• ビルドが、どのマニフェストにも記載されていないCIキャッシュからパッケージを復元する。
• ビルドステップが、ツール、OSパッケージ、バイナリを直接ダウンロードする。
• npmのインストールフックやRustのビルドスクリプトが、インストール中にさらにコードを取得する。Shai-Huludワームが使った経路です。
• コンテナビルドがベースイメージとそのOSレイヤーを取得するが、どの言語のロックファイルにも記載されない。
• 出荷するものがコンパイル済みバイナリで、その横のマニフェストにはほとんど何も記載されていない。

CRACIは記録装置です。通信を見ているのはCRACIであり、スキャナーではありません。CRACIは自社のGitHub Actions互換ランナーでビルドを実行し、パッケージを認識するプロキシがジョブの実行中にパッケージソースへの通信を観測するため、こうした隠れた依存関係もSBOMに記載されます。キャッシュから復元されたパッケージは、そのエビデンスを引き継ぎます。craci scan ./dirのようなコマンドはありません。事後にディレクトリをスキャンすることこそ、CRACIが避けるために存在する工程だからです。

スキャン結果を左右するもの

スキャナーの出力は、ツールと、何をスキャン対象に指定したかによって変わります。Syft、Trivy、cdxgen、Microsoft SBOM Tool、GitHubの依存関係グラフのエクスポート、Socket CLIは、それぞれ読み取れるものから一覧を導き出します。以下のパターンは、これらのツールのドキュメントに記載された動作に基づくものです。

すべてのツールが検出するコンポーネントは1つもない

各生成ツールは、何をコンポーネントとみなし、どのファイルを信頼するかを独自に判断するため、同じチェックアウトでもツールごとに異なる一覧が得られます。GitHubの依存関係グラフのエクスポートはさらに異なる仕組みで、スキャナーが読むファイルではなく、GitHubがリポジトリについて把握している情報から作られ、固定したコミットではなくデフォルトブランチを読み取ります。

ロックファイルがなければ、依存関係もない

Express 5.2.1はロックファイルをコミットしていません。クリーンなチェックアウトを対象にすると、ロックファイルやインストール済みのツリーから依存関係を解決する生成ツールの前にはそのどちらもなく、package.jsonで宣言されたnpmの依存関係は1つもドキュメントに記載されません。ここで挙げたツールが壊れているわけではありません。SBOMに依存関係が1つでも含まれるかどうかを決めるのはツールではなく、誰かが事前にインストールを実行したかどうかなのです。

フラグ1つで答えが変わる

Syftのデフォルトのディレクトリスキャンは、ディスクにインストールされたものではなく、プロジェクトが宣言したものを報告します。同じexpressリリースのインストール済みチェックアウトでは、カタロガーのフラグ1つで、インストール済みのnpmパッケージが一覧に現れるかどうかが決まります。同じツール、同じバージョン、同じツリーでもです。

製品がバイナリの場合

v2.1.259時点のanthropics/claude-codeリポジトリには、依存関係のマニフェストもロックファイルも一切ありません。公開されているnpmパッケージはランタイム依存関係をゼロと宣言しており、8つのプラットフォームパッケージを通じてビルド済みのネイティブバイナリをラップしています。@openai/codex 0.149.1も同じ構成です。マニフェストを読むツールが記述できるものはほとんどない一方で、実際に動くプログラムはコンパイル済みバイナリです。そのため各ツールの結果は、プロジェクトよりもツール自体について多くを物語ります。

同じパッケージでもバージョンが異なる

2つのツールが同じものを検出した場合でも、それが何であるかについて常に一致するとは限りません。あるツールはGitHub ActionをコミットSHAに固定し、別のツールはリリースタグを報告することがあります。誤ったバージョンをキーにした脆弱性の照合は、自信満々に誤った答えを返します。

既存のSCAとCRACIの組み合わせ方

SCAはプルリクエストで引き続きお使いください。脆弱なバージョンをマージ前に捕捉するには、そこが適切な場所です。差分ではなくビルドについて問う場面に、CRACIを加えてください。

• このリリースには実際に何が含まれていたのか。記録されたSBOMは、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットを、推移的依存関係を含めてカバーします。JFrog ArtifactoryのnpmとPyPIのミラーにも対応しています。
• その一覧は信頼できるのか。ジョブとキャッシュごとに完全性の状態があるため、不完全な記録は気づかれないまま薄くなるのではなく、目に見える形で示されます。
• 新しいアドバイザリの影響を受けるのか。監視対象のSBOMは新たな脆弱性の公開に応じて再評価され、検出結果はビルドとリポジトリをまたいで集約されます。

SBOMは公開REST APIからCycloneDXとしてダウンロードでき、ジョブのネットワークトレースと来歴も取得できます。そのため、現在お使いのSCAを含め、CycloneDXを読み込めるあらゆるツールに渡せます。設定はワークフローの1行だけです。runs-onをcraciに変更してください。現在サポートしているCIはGitHub Actionsで、GitLab CI、Jenkins、その他のCIシステムはロードマップに掲載されています。

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

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

ビルド時のSBOM生成と脆弱性トラッキングについて詳しくご覧ください。

CRACIが置き換えるもの、置き換えないものについては、CRACIが置き換えるものをご覧ください。