製品
CRACIがスタックの中で置き換えるもの、併用するもの
CRACIはGitHub Actionsランナーを置き換え、それと同時に、ビルドが何を使ったかを再構成しようとするビルド層のツールも置き換えます。各チームが実行するSBOM生成ツール、サプライチェーンのカバレッジのためのYocto組み込みのSBOM生成、そして単体のSBOMベースの脆弱性トラッキングです。コード、シークレット、稼働中のサービス、完成したバイナリを調べるツールとは併用します。理由はCRACIの位置にあります。CRACIはランナーそのものなので、ビルドが見えます。ソースコードを読んで欠陥を探すことはしません。
更新日
結論：移るものと残るもの
この表で自社のスタックを整理してください。各行は、スタック内のツールが現在担っている仕事、その仕事に必要な情報、そして CRACIがその位置からその仕事を担えるかどうかを示しています。
| スタック内の仕事 | その仕事に必要な情報 | CRACI | 残すものとその理由 |
|---|---|---|---|
| GitHub ActionsのLinuxジョブ用CIランナー：GitHubホステッド、サードパーティのランナープロバイダー、またはセルフホストのフリート | ジョブを実行する場所 | 置き換え | Windows、macOS、GitHub Enterprise Server、GitHub Actions以外のCIシステム向けのランナー。CRACIは現在これらに対応していません |
| 残すランナーに追加したネットワーク監視やエグレスのエージェント | ジョブの送信トラフィック | CRACIランナーでは置き換え | 他の場所で使い続けるランナー上のエージェント |
| チームごとにCIで実行するSBOM生成ツール：SBOMを作るためのマニフェスト、ロックファイル、イメージのスキャナー | ビルドが実際に取り込んだもの | CRACI上のビルドでは置き換え | CRACIでビルドしないソフトウェア向けの生成ツール（プルするだけでビルドしないイメージなど） |
サプライチェーンのカバレッジのためのYocto組み込みのSBOM生成（create-spdx） |
BitBakeビルドが取得したすべてのソースとツール | サプライチェーンのカバレッジでは置き換え | レシピのメタデータ（適用済みパッチ、修正済みとマークされたCVE）に依存している場合はcreate-spdx |
| SBOMベースの脆弱性トラッキング：SBOMのアップロード、アドバイザリとの照合、新しいアドバイザリの監視 | リリースごとの正確で最新のSBOM | CRACI上のビルドでは置き換え。ベンダーのSBOMも追加可能 | CRACIが行わない機能（到達可能性分析、MTTRや重大度ごとの期限などの修正メトリクス）が必要なら専用ツール |
| スプレッドシートで管理しているSBOMやコンポーネント一覧 | リリースごとの正確で最新のSBOM | 置き換え | なし |
| 宣言ライセンスのチェックとライセンスポリシー | 各コンポーネントの宣言ライセンス | 一部 | 全文およびスニペット単位のライセンススキャン、帰属表示 |
| SASTとコードスキャン | ソースコード | 併用 | 残します。CRACIランナー上のワークフローステップとしてそのまま動きます |
| シークレットスキャンとプッシュ保護 | リポジトリとコミット | 併用 | 残します |
| DASTとAPIテスト | 稼働中のサービス | 併用 | 残します |
| サードパーティのバイナリとファームウェアの解析 | 自社でビルドしていない完成済みのバイナリ | 併用 | 残します |
| コピーやベンダリングされたコードのスニペット・シグネチャスキャン | リポジトリ内のファイルの内容 | 併用 | 残します |
| 到達可能性に基づく優先順位付け | コールグラフ | 併用 | 依存している場合は残します |
| IaC、クラスター、設定ミスのスキャン | 設定と稼働中のインフラストラクチャ | 併用 | 残します |
| ワークフロー設定に対するCI/CDのポスチャーチェック | ワークフローファイルと設定 | 併用 | 残します |
| チケット管理、PSIRTのケース管理、アドバイザリの公開 | 業務プロセス | 併用 | 残します |
| コンプライアンス自動化：SOC 2やISO 27001監査のためのエビデンス収集 | システム全体にわたる統制 | 併用 | 残します。CRACIの記録はそのツールが収集できるエビデンスになります |
導入前と導入後
導入前：GitHubホステッドランナー、チームごとのワークフローで異なるSBOM生成ツール、ビルド時間を延ばすYoctoのcreate-spdx、
トラッキングツールやスプレッドシートにアップロードされるSBOMがあり、その周りにコードスキャン、シークレットスキャン、バイナリ解析、
チケット管理があります。導入後：CRACIランナーが各ジョブを実行し、そのエグレスポリシーを強制し、SBOMを記録して監視下に置きます。
コード、リポジトリ、バイナリ、業務プロセスを読むツールは変わりません。
CRACIが置き換えるものとその理由
これらの仕事はすべてビルド中に行われます。CRACIはビルドが実行される場所そのものなので、これらを引き受けられます。 それぞれについて、仕組み、手放すもの、例を示します。
ランナー
CRACIはGitHub Actions用のランナーです。runs-onをcraciに変更するだけで、実行結果は他のActionsジョブと同様にGitHubに表示されます。
各ジョブには専用の仮想マシンが割り当てられ、Linux x86-64またはARM64で、1〜32 vCPUのサイズから選べ、秒単位で計測されます。
ワークフローの書き換えは不要で、スキャンステップを含む既存のステップはそのまま動き続けます。
CRACIの課金はビルド時間のみです。vCPU分あたり$0.002（デフォルトの2 vCPUランナーで$0.004）、秒単位で計測し、月額料金もSBOMごとの料金もありません。 そのため、最も手頃なCIランナーの1つです。高速なハードウェア、短いキュー待ち時間、キャッシュにより、GitHubホステッドランナーの約2倍の速さでビルドを実行します。
| ランナー（1分あたり） | CRACI | GitHubホステッド | 差 |
|---|---|---|---|
| 2 vCPU x64 | $0.004 | $0.006 | CRACIが約33%安い |
| 2 vCPU ARM64 | $0.004 | $0.005 | CRACIが20%安い |
| 32 vCPU x64 | $0.064 | $0.082 | CRACIが約22%安い |
| 32 vCPU ARM64 | $0.064 | $0.050 | CRACIが28%高い |
GitHubの定価は2026年9月時点のものです。GitHubは各ジョブを1分単位に切り上げ、CRACIは秒単位で計測します。 例：GitHubホステッドの2コアx64ランナーで10分かかるビルドは$0.060です。約2倍の速さなので、2 vCPUのCRACIランナーでは5分で終わり、 $0.020、約67%安くなります。料金とCIランナーの料金をご覧ください。
手放すもの：WindowsとmacOSのランナー、他のCIシステム、顧客ホスト型ランナーは現在提供していません。GitLab CI、Jenkins、 Windows、macOS、顧客ホスト型ランナーはロードマップにあります。GitHub Enterprise Serverには対応していません。ランナーはマネージド型で、 ヨーロッパのインフラストラクチャ上で動きます。マネージドランナーと自社のフリートを比較検討している場合は、 マネージドランナーとセルフホストランナーの比較をご覧ください。
残すランナー上のエグレスエージェント
エグレスエージェントは、他者が運用するランナーのトラフィックを監視または制限します。CRACIではランナー自体が エグレスポリシーを強制します。デフォルト拒否またはデフォルト許可、24種類の組み込みソフトウェアソースのプリセット、 パッケージレジストリとGit向けの型付きカスタムソース、明示的なネットワークルールを使えます。ポリシーはジョブの開始前に検証され、フェイルクローズで動作し、 CRACIはポリシー違反をアラートで通知します。CRACIランナーでは別のエージェントは必要ありません。
例：侵害された依存関係が、ビルドが一度も必要としたことのないホストへジョブのシークレットを送信しようとします。 デフォルト拒否のポリシーなら、誰も見たことのない攻撃であっても接続はブロックされます。ポリシーは既知の悪性ホストを探すのではなく、 ビルドに必要なものだけを許可するからです。
手放すもの：ポリシーの対象はCRACIランナー上のジョブです。他の場所で使い続けるランナーには、引き続き独自の制御が必要です。
各チームのワークフローにあるSBOM生成ツール
生成ツールは、マニフェスト、ロックファイル、イメージなど目の前にあるファイルを読み、何が含まれたかを再構成します。 同じチェックアウトからでも生成ツールによって返される一覧は異なり、チームは通常それぞれ独自のツールを選ぶため、 組織には食い違う複数のインベントリが残ります。
CRACIは、各ジョブが実際に取り込んだパッケージを記録します。CIキャッシュから復元されたパッケージも、ロックファイルベースのツールが見落とす隠れた依存関係も含みます。 npmのinstallフックがダウンロードするコード、ビルド時にダウンロードするRustのビルドスクリプト、コンテナビルドのベースイメージとそのOSレイヤーなどです。 SBOMのすべてのコンポーネントは実際にビルドに含まれていたものです。各ジョブのSBOMにはComplete、Complete with connections、Incomplete、 Unavailable、Not recordedのいずれかで完全性が示されるため、欠落は見過ごされずに可視化されます。結果として、CRACIでビルドするすべてのリポジトリに 1つのインベントリができ、CycloneDXまたはSPDXでエクスポートできます。現在記録できるエコシステムは、npm、PyPI、RubyGems、Composer、Cargo、 Go、Nix、OCI、apt、apk、Gitソース、そしてYoctoとOpenEmbeddedのダウンロードです。
例：expressjs/express 5.2.1はロックファイルをコミットしていません。ロックファイルから依存関係を解決する生成ツールにはそこで解決するものがなく、
それでもpackage.jsonで宣言されたnpmの依存関係を1つも載せていないドキュメントを返すことがあります。同じプロジェクトをCRACIでビルドすると、
npm installが取得したパッケージが記録されます。手法の詳細はビルド時SBOMと
SCAツールとSBOMツールの比較をご覧ください。生成ツールを自前で組み合わせる場合は
自作のSBOMスタックをご覧ください。
手放すもの：CRACIがまだ記録していないエコシステムです。MavenとJavaはロードマップにあり、上記の一覧にないものは対象外です。 それらのビルドには生成ツールを残してください。
Yocto組み込みのSBOM生成
Yoctoはcreate-spdxで独自のSPDX SBOMを書き出し、BitBakeがビルドするものについては網羅的です。しかし、BitBakeのメタデータの外で起きることは見えません。
CRACIはBitBakeビルドを実行し、取得されたものを記録します。32 vCPUのネイティブARM64ランナーでcore-image-satoを並べてビルドした比較では、
CRACIのSBOMにはYoctoのSBOMにあるすべてのコンポーネントに加え、Yoctoが見落とした88件がありました。ビルドマシン上の23件のホストパッケージ、
GitHub Actionのactions/upload-artifactを含む10件のGitHubソース、ビルド中に取得された55件のその他のソースとツールです。
653件のRustクレートのバージョンもすべてpkg:cargoのパッケージURL付きで記録されたため、アドバイザリと照合できます。
YoctoのSBOM生成を無効にしたビルドは所要時間が43%短く、CRACIの料金で1ビルドあたり約$9.96に対して$5.68でした。
手放すもの：YoctoのSPDXには、CRACIが記録しないレシピのメタデータ（適用済みのパッチ、修正済みとマークされたCVE）が含まれます。
これらに依存している場合はcreate-spdxを有効のままにしてください。手法と比較の全容は
CRACIでのYoctoビルドにあります。
SBOMを脆弱性トラッキングにつなげる
単体のトラッキングツールにはSBOMを渡す必要があり、渡されたものをそのまま信頼します。CRACIはSBOMを生成し、記録を保持します。 監視対象のSBOMは、新しいアドバイザリが公開されるたびに継続的に再評価されます。ビルド履歴から、脆弱な依存関係（直接または推移的）を含んでいたビルドがわかるため、 プランの保持期間の範囲内で、影響を受けていた期間を把握できます。検出結果は修正を担当するチームにトリアージされ、CRACIは脆弱性とその重大度を関係者に通知し、 ポリシーゲートは検出結果に基づいてビルドをブロックできます。特定のCVEを含むビルドのブロックも可能です。 VEXに対応しています。ベンダーのSBOMも追加できるため、購入したコンポーネントも自社のビルドと並べて監視できます。
例：3か月前にあるサービスに組み込んでコンパイルしたクレートに対してアドバイザリが公開されたとします。 CRACIは監視中のすべてのSBOMと照合し、そのバージョンを含んでいたビルドを示します。誰も再アップロードする必要はありません。
手放すもの：CRACIは到達可能性分析や、MTTR、重大度ごとの期限、バックログの推移などの修正メトリクスを提供していません。 これらに依存している場合は、それを提供するツールを残してください。機能の全体像は脆弱性トラッキングをご覧ください。
スプレッドシート
SBOMツールを持たないチームにとって、CRACIが置き換えるのは手作業での取りまとめです。リリースや監査の前に、誰かが依存関係の一覧をスプレッドシートにコピーしています。 CRACIでのビルドは実行の副産物としてSBOMを生成するため、誰かが思い出したビルドだけでなく、すべてのビルドに一覧が存在します。
CRACIと併用するものとその方法
これらのツールは、CRACIが決して読まないものを読みます。CRACIはソースコードを読んで欠陥を探すことも、稼働中のサービスをテストすることも、 自らビルドしていないバイナリを解析することもしません。これらのツールは今と同じように動き続けます。
コードとリポジトリを読むツール
SAST、シークレットスキャンとプッシュ保護、スニペット・シグネチャスキャン、IaCスキャン、CI/CDのポスチャーチェックは、いずれもコード、コミット、設定を調べます。 ワークフローのステップはCRACIランナー上でそのまま動き、リポジトリレベルの機能はもともとランナー上で動いていないため影響を受けません。 コードスキャンのステップはビルドと同じジョブに置けます。SASTは意図的に対象外としています。CRACIと併用できる優れたSASTツールは数多くあります。 2種類の検出結果の違いはSASTとSCAの比較をご覧ください。
自社でビルドしていないものを調べるツール
サプライヤーのバイナリやファームウェアの解析、プルするだけでビルドしないイメージのスキャナー、稼働中のサービスに対するDASTは、 いずれも別の場所でビルドされたもの、またはすでに稼働しているものを調べます。CRACIはビルドを記録します。サプライヤーから届くバイナリは、 CRACIが見たことのない場所でビルドされたものです。サプライヤーからSBOMが提供されれば、CRACIは自社のビルドと並べてそれを監視できます。
到達可能性に基づく優先順位付けはコールグラフを読みますが、CRACIはコールグラフを解析しません。依存している場合は残してください。 何がわかり何がわからないかは到達可能性分析をご覧ください。
業務プロセスのシステム
チケット管理、PSIRTのケース管理、アドバイザリの公開、コンプライアンス自動化プラットフォームは、多くのシステムにまたがって業務プロセスを動かします。 CRACIは検出結果を担当チームに振り分け、ビルドのエビデンスを保持します。それ以外にはプロセスツールを使い続けてください。 記録はCycloneDXまたはSPDXのSBOMとして、またAPIを通じてCRACIから取り出せます。APIはSBOM、ネットワークトレース、来歴データを返します。 監査面についてはSOC 2のためのSBOMチェックをご覧ください。帰属表示や全文レビューなど、 宣言ライセンスを超えるライセンス業務についてはオープンソースライセンスのコンプライアンスをご覧ください。 CRACIは各コンポーネントの宣言ライセンスを保持し、ライセンスによるビルドのブロックを含むライセンスポリシーのルールを強制します。
自社のスタックで置き換えのポイントを見つける方法
午後のうちに答えられる5つの質問です。それぞれの答えから、スタックのどの行が移るかがわかります。
- ビルドはLinux上のGitHub Actionsで動いていますか？はいなら、ランナーが移ります。いいえなら、現時点でCRACIが置き換えるものはありません。
- 現在誰がSBOMを生成していて、何種類の生成ツールが使われていますか？CRACIに移すリポジトリ上の生成ツールは、1つずつ不要になります。
-
Yoctoイメージをビルドしていますか？はいなら、無効にする前に、
create-spdxの出力にある適用済みパッチと修正済みCVEに 依存している人がいないか確認してください。 - 生成されたSBOMはどこに行きますか？トラッキングツール、スプレッドシート、それともどこにも行きませんか？ そのツールやプロセスが2つ目に不要になるものです。ただし、そこから到達可能性や修正メトリクスを得る必要がある場合は別です。
- セキュリティツールのうち、コード、リポジトリ、サードパーティのバイナリを読むものはどれですか？それらは残ります。 CRACIがそれらを置き換えると誰も期待しないよう、書き出しておいてください。
具体例
実在の企業に基づかない、説明用の機器メーカーの例です。LinuxビルドはGitHubホステッドランナーで動き、2つのチームが異なる2つのSBOM生成ツールを使い、
Yoctoの製品ラインではcreate-spdxが有効で、SBOMは共有スプレッドシートに集められ、コードスキャンのスイートとチケット管理システムがあります。
セキュリティチームは質問1と3に「はい」と答え、質問2では2つの生成ツール、質問4ではスプレッドシートを見つけ、質問5ではコードスキャン、
シークレットスキャン、チケット管理システムを挙げます。YoctoのSPDXにあるパッチのメタデータは誰も使っていません。
| CRACIに移るもの | 残るもの |
|---|---|
| Linuxジョブ用のGitHubホステッドランナー | コードスキャン（CRACIランナー上のステップとして実行） |
| 2つのSBOM生成ツール | シークレットスキャン |
create-spdx（パッチのメタデータを誰も必要としないため） |
チケット管理システム |
| SBOMのスプレッドシート |
ランナーの行では、GitHubホステッドの2コアx64ランナーで$0.060かかる10分のビルドが、高速化によりCRACIでは約$0.020になります。 その他のツールのコストは、その企業自身が記入するものです。
CRACIが適さない場合
- パイプラインがGitLab CI、Jenkins、Azure DevOps、またはその他のCIシステムで動いている場合。CRACIは現在GitHub Actionsのみに対応しており、 GitLab CIとJenkinsはロードマップにあるため、まだ置き換えられるものはありません。
- ビルドにWindowsやmacOSのランナー、GitHub Enterprise Serverが必要な場合、または自社のインフラストラクチャで実行する必要がある場合。
- 主な悩みが自社コードのコードスキャンによるノイズである場合。それはSASTのチューニングの問題です。SASTとSCAの比較と 脆弱性ノイズを減らす方法をご覧ください。
- 主なリスクが、自社でビルドするコードではなく、サプライヤーから受け取るファームウェアやバイナリである場合。
- スタックの大半がJavaとMaven（ロードマップにあります）、または.NET（CRACIが記録するエコシステムの一覧にありません）である場合。
- 到達可能性に基づく優先順位付けやPSIRTのケース管理が今すぐ必要な場合。
製品をステップごとに知るにはCRACIの仕組みを、SBOMそのものについては SBOM生成をご覧ください。
CRACIが置き換えるもの：よくある質問
CRACIは何を置き換えますか？
LinuxジョブのGitHub Actionsランナー、CRACIに移すビルドについてチームがCIで実行するSBOM生成ツール、サプライチェーンのカバレッジのためのYoctoのcreate-spdx、ランナー上のエグレスエージェント、そしてそれらのビルドに対する単体のSBOMベースの脆弱性トラッキングです。コード、リポジトリ、サードパーティのバイナリを読むツールは置き換えません。
CRACIはSCAツールのアドオンですか、それとも何かを置き換えますか？
ビルド層の仕事を置き換えます。ランナー、SBOM生成、そしてSBOMから続くトラッキングです。SCAツールが不要になるかどうかは、その用途によります。コードを読む、スニペットやバイナリの解析を行う、到達可能性分析を提供するといった部分は残ります。
CRACIでビルドを実行する場合も、SBOM生成ツールは必要ですか？
CRACIで実行し、CRACIが記録するエコシステムを使うビルドには不要です。CRACIは各ジョブが取り込んだパッケージを記録し、SBOMをCycloneDXまたはSPDXでエクスポートします。プルするイメージなどCRACIでビルドしないソフトウェアや、MavenなどCRACIがまだ記録していないエコシステムには生成ツールを残してください。
Yocto組み込みのSBOM生成（create-spdx）は引き続き必要ですか？
サプライチェーンのカバレッジについては不要です。core-image-satoを並べてビルドした比較では、CRACIのSBOMにはYoctoのSBOMにあるすべてのコンポーネントに加えYoctoが見落とした88件があり、create-spdxなしのビルドは所要時間が43%短くなりました。CRACIが記録しない適用済みパッチや修正済みとマークされたCVEに依存している場合は、create-spdxを有効のままにしてください。
CRACIはコードスキャンやシークレットスキャンを置き換えますか？
いいえ。CRACIはソースコードやコミットを読んで欠陥やシークレットを探すことはしません。それらのツールは残してください。コードスキャンのステップはCRACIランナー上のワークフローでそのまま動き、リポジトリレベルの機能は影響を受けません。
CRACIはバイナリやファームウェアの解析を置き換えますか？
いいえ。CRACIは自ら実行したビルドを記録します。サプライヤーから受け取るファームウェアやバイナリには、バイナリ解析が適したツールです。サプライヤーからSBOMが提供されれば、CRACIは自社のビルドと並べてそれを監視できます。
CRACIランナー上でも、GitHub Actionsの既存のセキュリティステップを使い続けられますか？
はい。CRACIが置き換えるのはランナーで、GitHub Actionsではありません。runs-onをcraciに設定するだけで、ワークフロー、ステップ、結果はGitHubに残ります。スキャンステップ、テストステップ、その他のステップもこれまでどおり動きます。