比較
CRACIとDependabot
Dependabotは、GitHubを使うチームが最初に有効にするサプライチェーンツールであることが多く、有効のままにしておくべきです。CRACIは、Dependabotが本来見るようには設計されていないもの、つまりビルドが実際に行ったことを補います。
更新日
Dependabotは使い続けてください。カバー範囲は次のとおりです。
コードをGitHubで管理しているなら、おそらくすでにDependabotを使っているでしょう。Dependabotは3つの便利な機能を提供します。Dependabotアラートは、リポジトリ内の依存関係が既知の脆弱性に該当すると通知します。セキュリティアップデートは、脆弱な依存関係をアップグレードするプルリクエストを作成します。バージョンアップデートは、脆弱性がない場合でも依存関係を最新に保ちます。
これらはすべて、リポジトリ内のマニフェストとロックファイルを解析するGitHubの依存関係グラフの上に成り立っています。GitHubはこのグラフをSPDX形式のSBOMとしてエクスポートできます。Go、Gradle、Mavenなどのエコシステムでは、既製のアクションを使って、ビルド時に解決された依存関係を依存関係送信APIから送信できます。
少ない手間で依存関係にパッチを当て続けるという点では、Dependabotに勝るものはなかなかありません。CRACIはプルリクエストを作成しません。CRACIが加えるのはもう半分、つまり各ビルドが実際に取り込んだものの記録であり、それに新たな脆弱性がないか監視します。そのため、新しいアドバイザリが出荷済みのどのビルドに影響するか、どの更新プルリクエストを先にマージすべきかがわかります。
Dependabotでは答えられない問い
Dependabotはリポジトリを中心に設計されています。デフォルトブランチをスキャンし、マニフェストとロックファイルに依存します。GitHubのドキュメントもこの点を率直に述べています。アラートですべてのセキュリティ問題を検出できるわけではなく、正確な検出のためにはマニフェストとロックファイルを最新に保つ必要があり、アラートのトリガーとなるのはGitHubがレビューしたアドバイザリだけです。
そのため、セキュリティやコンプライアンスの責任者がいずれ問われる問いが残ります。
- リリース4.2のビルドは、どのマニフェストにもないツールやイメージを含め、実際に何をダウンロードしたのか?
- ビルドは実行中に、インターネット上の任意のホストにアクセスできたのか?
- 顧客が受け取ったバイナリがそのビルドから生成されたものだと証明できるか?
- そのエビデンスを、数か月後に監査人に提示できるか?
これらに答えるには、ビルドの内側からの視点が必要です。CRACIが動作するのはまさにそこです。
| 機能 | CRACI | Dependabot |
|---|---|---|
| ビルドを実行 | ジョブはCRACIランナーで実行 | ビルドではなくリポジトリのデータを読み取る |
| ビルドから記録した依存関係 | CIキャッシュからの復元を含め、実際の取得を観測 | マニフェストとロックファイル、および依存関係送信API |
| SBOMのエクスポート | CycloneDXとSPDX、ジョブごと・キャッシュごとの完全性 | 依存関係グラフのSPDXエクスポート |
| ビルドのネットワークエグレスポリシー | デフォルト拒否または許可、フェイルクローズ | 対象範囲外 |
| 脆弱性アラート | ビルドとリポジトリをまたいで集約 | GitHubがレビューしたアドバイザリに基づく |
| 新しいアドバイザリの監視 | 監視対象のSBOMを継続的に再評価 | アドバイザリ追加に応じたデフォルトブランチのアラート |
| 更新プルリクエストの作成 | セキュリティアップデートとバージョンアップデート | |
| トリアージと担当チームへの振り分け | ビルドとリポジトリをまたいで | リポジトリごとのアラート |
| ランナーを変更せずに利用可能 | ジョブをCRACIで実行する必要あり | GitHubリポジトリに組み込み |
| コンプライアンスのエビデンス | CycloneDXまたはSPDXのSBOM、APIで記録を取得。レポートのエクスポートなし | GitHubのアラートビューとSPDXエクスポート |
- 対応
- 一部対応
- 非対応
CRACIが加えるもの
ビルド時の可視性
CRACIはGitHub Actions互換のランナーです。runs-onをcraciに変更すると、ジョブはCRACI上の隔離された仮想マシンで実行され、実行結果は引き続きGitHubのUIに表示されます。各ジョブの実行中、パッケージを認識するプロキシがパッケージソースへの通信を記録します。対象はnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースと、ダウンロードプリセットです。依存関係のエビデンスはキャッシュと一緒に引き継がれるため、CIキャッシュから復元されたパッケージも記録に残ります。
各SBOMには、ジョブごと・キャッシュごとに完全性の状態が示されます。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。これは、解析するファイルの質に精度が左右されるグラフとは異なります。
この違いは実際に表れます。GitHubの依存関係グラフのエクスポートは、GitHubがリポジトリについて把握している情報から構築されるため、ファイルベースのスキャナーでは見つからないコンポーネントが含まれることもあり、ビルドしたコミットではなくデフォルトブランチを反映します。どちらの挙動も、グラフ本来の目的からすれば誤りではありません。ただ、リポジトリのビューとビルドの記録が別物であることを示しています。(CRACIはディレクトリをスキャンするのではなくビルドを記録するため、同じ方法では比較できません。)
実行時の制御
Dependabotは、脆弱なパッケージがマニフェストに入った後でそれを知らせます。ビルドの接続先については関与しません。CRACIはビルドを実行するため、それを制御できます。エグレスポリシーはデフォルト拒否またはデフォルト許可で、24の組み込みソフトウェアソースプリセット、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソース、明示的なTLS、TCP、UDP、ICMPルールを備えています。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを発します。
来歴
CRACIは、ジョブが取得したものから、CRACI自身のランナー内でSBOMを生成します。APIからはSBOM、ネットワークトレース、来歴を取得できます。
コンプライアンスのエビデンス
EUのCyber Resilience Actなどの規制は、製造者に対し、製品の各リリースに何が含まれているかを把握し、その脆弱性に対処することを求めています。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、新しいアドバイザリが公開されるたびに監視対象のSBOMを再評価し続け、脆弱性を含めてSBOMをCycloneDXまたはSPDXでエクスポートします。企業がより広範なCRAコンプライアンスプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。詳しくはCRAとはとCRAのエビデンスをご覧ください。
どこに何がデプロイされているかのインベントリ
CRACIのインベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかを、グローバルに正確に把握できます。新しい脆弱性が公開されたとき、リリースノートやスプレッドシートをつなぎ合わせなくても、影響を受けるバージョンを実行している製品がわかります。
両方を使い分ける方法
- Dependabotは、デフォルトブランチの依存関係にパッチを当て続け、アドバイザリが公開されるとプルリクエストを作成します。
- CRACIは、GitHub Actionsのジョブを実行し、各ビルドが取得したものを記録し、ビルドの接続先を制限し、各ビルドが取り込んだものに新たな脆弱性がないか監視し、リリースのエビデンスを保持します。
移行作業は何もありません。Dependabotはリポジトリ上で動作し続け、ワークフローもGitHub Actionsで動き続けます。変わるのはランナーだけです。
CRACIは現在GitHub Actionsに対応しています。Dependabotが動作するのと同じ場所です。ビルド時SBOM生成、脆弱性トラッキング、料金もご覧ください。
CRACIとDependabot:よくあるご質問
各ツールのカバー範囲、SBOM、料金、コンプライアンス
CRACIはDependabotの代わりになりますか?
いいえ。Dependabotは有効のままにしてください。Dependabotはリポジトリ内の脆弱な依存関係を検出し、それをアップグレードするプルリクエストを作成します。CRACIはGitHub Actionsのジョブを実行して各ビルドが実際に取り込んだものを記録し、ビルドの接続先を制御し、出荷したものに新たな脆弱性がないか監視します。
CRACIの脆弱性ビューはDependabotのアラートの代わりになりますか?
いいえ。答える問いが異なります。Dependabotのアラートは、1つのリポジトリのデフォルトブランチを対象としています。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを再評価し続けるため、どのビルドが脆弱な依存関係を共有しているかがわかり、セキュリティチームは検出結果をトリアージして修正を担当するチームに送れます。ポリシーゲートでビルドをブロックでき、しきい値アラートはロードマップに掲載されています。
CRACIはDependabotのようにプルリクエストを作成しますか?
いいえ。プルリクエストを作成するのはDependabotのセキュリティアップデートとバージョンアップデートであり、CRACIは作成しません。CRACIが加えるのはビルドの記録です。新しいアドバイザリが公開されたときに、出荷済みのどのビルドが影響を受けるか、どの更新プルリクエストを先にマージすべきかがわかります。
GitHubとCRACIのSBOMはどう違いますか?
GitHubは依存関係グラフをSPDX形式のSBOMとしてエクスポートします。これはリポジトリ内のマニフェストとロックファイル、および依存関係送信APIから構築され、デフォルトブランチを反映します。CRACIは各ビルドの実行中にSBOMを記録してCycloneDXまたはSPDXでエクスポートし、ジョブごと・キャッシュごとの完全性の状態で、記録に欠落があったかどうかを示します。
依存関係がどのマニフェストにも記載されていない場合、CRACIは役立ちますか?
はい。ビルドがそれをパッケージソースから取得する場合は役立ちます。CRACIはジョブ中の通信を記録するため、スクリプトがダウンロードしたツールやキャッシュから復元されたパッケージもビルドの記録に現れ、記録できなかったものがあればSBOMの完全性の状態でわかります。
DependabotとCRACIの料金はいくらですか?
Dependabotのセキュリティアップデートとバージョンアップデートは、Freeを含むすべてのGitHubプランに含まれています(2026年9月時点)。CRACIの課金はビルド時間のみで、1 vCPU分あたり$0.002(デフォルトの2 vCPUランナーでは$0.004)、秒単位で計測され、月額料金もSBOMごとの課金もありません。最新の条件は料金をご覧ください。
CRACIはコンプライアンス要件のあるチーム専用ですか?
いいえ。ただし、エビデンスが最も役立つのはそうした場面です。EUでソフトウェアを販売する場合、Cyber Resilience Actにより、リリースごとのコンポーネントインベントリと脆弱性対応が業務の一部になります。それ以外の企業にとっても、ビルドが何を取得しているかを把握することは、サプライチェーンのインシデント対応の基盤です。デモを予約して、自社のワークフローのビルド記録をご覧ください。