CRACIとDependency-Trackの比較

Dependency-Trackの強み

OWASP Dependency-Trackは、コンポーネント分析の有力な選択肢です。Apache 2.0ライセンスのオープンソースで、ポートフォリオ内のすべてのアプリケーションのすべてのバージョンにわたってコンポーネントの使用状況を追跡し、National Vulnerability DatabaseやGitHub Advisoriesを含む複数の情報源から脆弱性情報を取得します。ポリシーエンジンはセキュリティ、ライセンス、運用のルールをカバーし、CycloneDX VEXドキュメントの取り込みと生成に対応しています。APIファーストの設計はCI/CDに適しており、パイプラインは/api/v1/bomにSBOMをアップロードします。

透明性が高く、セルフホストでき、標準フォーマットを中心に構築されていることから、規制業界のチームに好まれています。弱点は解析そのものではなく、そこに投入されるものにあります。

解析は入力次第

Dependency-TrackはSBOMを取り込むものであり、生成はしません。すべての検出結果、ポリシー違反、ポートフォリオのビューは、パイプラインが送るSBOMに依存します。SBOMが依存関係を見落としていれば、Dependency-Trackはそれを指摘できません。2つの生成ツールの結果が食い違っても、Dependency-Trackが表示するのはアップロードされたほうです。

実際には、SBOM生成ツールの結果は大きく食い違い、その理由は各ツールのドキュメントに書かれています。

• 共通の基準がない。各生成ツールは、何をコンポーネントとみなし、どのファイルを信頼するかを独自に判断するため、同じリポジトリを対象にしても、重なりつつも異なる一覧が返ってきます。
• 明らかなものを見落とす。ロックファイルから依存関係を解決するツールは、express 5.2.1のようにロックファイルをコミットしていないリポジトリでは、解決するものがありません。それでもGitHub Actionsやワークフローファイルなど、それ以外に認識できるもので一覧を返すことがあります。
• 設定で結果が揺れる。Syftはスキャンの種類に応じてカタロガーを選ぶため、フラグ1つで、同じバージョンの同じツールが同じチェックアウトから報告する内容が変わります。
• マニフェストがなければSBOMもない。依存関係のマニフェストがまったくないリポジトリでは、ファイルベースのスキャナーは何も手がかりを得られず、各ツールの結果はプロジェクトよりもツール自体について多くを物語ります。
• メタデータが乏しい。ほとんどの生成ツールにはNTIAのサプライヤーフィールドの情報源がないため、リポジトリの内容にかかわらず空のまま出力されます。

CRACIはこの方法では比較できません。ディレクトリをスキャンするのではなくビルドを記録するため、同じ方法で実行できないのです。要点は、これらのツールのどれかが悪いということではありません。リポジトリの静的スキャンはビルドが使うものの推定にすぎず、その推定はツール、その設定、存在するファイルによって変わる、ということです。

CRACIが出どころで変えること

SBOMはビルドから生まれる

CRACIはGitHub Actions互換のランナーです。runs-onをcraciに変更すると、ジョブはCRACIの隔離された仮想マシンで実行されます。各ジョブの実行中、パッケージを認識するプロキシがパッケージソースへの通信を記録します。対象はnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースと、ダウンロードプリセットです。依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュから復元されたパッケージも記録に残ります。CycloneDXまたはSPDXのSBOMには、ビルドが実際に使用したすべての推移的依存関係が含まれます。

不完全なときはそう伝える

CRACIのすべてのSBOMには、ジョブごと・キャッシュごとの完全性の状態（Complete、Complete with connections、Incomplete、Unavailable、Not recorded）が付きます。各SBOMが完全な記録なのか、欠落があるのかがわかります。インベントリが完全であることをどう確認しているのかを監査人に問われたとき、これが重要になります。

ビルドの内部でSBOMを記録する

CRACIは、ジョブが取得したものから、CRACI自身のランナー内でSBOMを生成します。APIはSBOM、ネットワークトレース、来歴を返します。

ビルドの到達先を制御する

CRACIはジョブを実行するため、ネットワークのエグレスポリシーを適用できます。デフォルト拒否またはデフォルト許可を選べ、24の組み込みソフトウェアソースプリセットと型付きカスタムソースを使えます。ポリシーはジョブ開始前に検証され、フェイルクローズで動作します。Dependency-Trackは事後にコンポーネントのリスクを教えてくれますが、エグレスポリシーはそもそもビルドがどのソースから取得できるかを制限します。

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

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

Dependency-TrackからCRACIへの置き換え

CRACIは、これまで生成ツールとDependency-Trackが分担していた役割の両方をカバーします。ビルド内でSBOMを生成し、新たな脆弱性の公開に応じて監視対象のSBOMを再評価し続け、ビルドとリポジトリをまたいで検出結果を集約し、セキュリティチームがそれらをトリアージして修正を担うチームに割り当てられるようにします。維持すべきアップロード工程も、運用すべきサーバーもありません。

失うものも明確にしておきましょう。Dependency-Trackのポリシーエンジンは成熟しています。CRACIにはビルドをブロックするポリシーゲートとライセンスポリシーがあり、コメントとしきい値アラートはロードマップに掲載されています。またDependency-Trackはオープンソースでセルフホストできますが、CRACIは現在マネージドサービスで、顧客ホスト型ランナーはEnterprise向けにロードマップに掲載されています。それらがインベントリの質よりも重要なら、Dependency-Trackを使い続けてください。

規制業界でこれが重要な理由

EU Cyber Resilience Actのもとで、メーカーは製品の各リリースに何が含まれているかを把握し、その脆弱性に対処する必要があり、実際に悪用されている脆弱性の報告義務は2026年9月から始まります。SBOMがコンポーネントを見落としていたために見えなかった脆弱性も、お客様の脆弱性であることに変わりはありません。

CRACIは、企業がより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化し、脆弱性を含めてSBOMをCycloneDXまたはSPDXでエクスポートします。インベントリと監視は、各リリースが何からビルドされたかという同じ記録から生まれます。CRAコンプライアンス、産業用IoT、通信をご覧ください。