CRACIとBuildkiteの比較

結論から

Buildkiteはハイブリッド型のCI/CDプラットフォームです。SaaSのコントロールプレーンがオーケストレーションを担い、ジョブを実行するエージェントはオンプレミスやクラウドなど自社のインフラ上に置かれます。Buildkiteは、ソースコードとシークレットが自社環境内にとどまるとしています。自社でエージェントを運用したくない場合のために、フルマネージドのホスト型エージェントも提供しています。

CRACIは、サプライチェーンセキュリティのために作られた、GitHub Actions互換のマネージドランナーです。ビルドが取得するすべての外部依存関係を記録し、ビルドネットワークにエグレスポリシーを適用し、その記録からSBOM、来歴データ、CRAのエビデンスを作成します。簡単に言えば、Buildkiteはインフラを最大限に管理できる従来型のCIであり、CRACIはランナーそのものがエビデンスになるセキュリティを意識したCIです。

CRACIは現在GitHub Actionsのみに対応しているため、Buildkiteのパイプラインは実行しません。BuildkiteのチームがCRACIランナーを使うには、パイプラインをGitHub Actionsに移行するか、ロードマップに掲載されているほかのCIシステムへの対応を待つ必要があります。

Buildkiteが得意なこと

コンピュートの管理。エージェントを自社でホストするため、ハードウェア、OS、ネットワーク、リージョンを自由に選べます。エージェントはHTTPS経由でBuildkiteのエージェントAPIをポーリングするため、受信方向のファイアウォールポートを開ける必要はありません。このモデルは、大規模なモノレポ、特殊なハードウェア、ソースコードを自社の境界内に置くポリシーを持つ組織に適しています。

パイプラインの完全性。署名付きパイプラインでは、ジョブはアップロード時に署名され、エージェントは実行前にその署名を検証します。そのため、アップロード後に指示が改ざんされたジョブをエージェントが実行することはありません。

ビルドを取り巻くツール群。Test Engineは不安定なテストを検出して隔離し、テストを並列ジョブに分割します。Package RegistriesはSLSAの来歴付きで成果物を公開でき、BuildkiteによるとこれはSLSA Build Level 1を満たします。この機能はEnterpriseプランで利用できます。

柔軟な料金体系。2026年9月時点で、BuildkiteにはFreeプランと、アクティブユーザー1人あたり月額$30のProプランがあります。Proにはセルフホストのエージェントが10台含まれ、追加はエージェント1台あたり月額$3.50です。ホスト型のLinuxエージェントは1 vCPU分あたり$0.004で、秒単位で計測されます。

CRACIの違い

セキュリティのエビデンスがランナーに組み込まれている

セルフホストのエージェントでは、ビルド環境のセキュリティ確保は自社の責任です。Buildkite自身のセキュリティガイダンスも、最小構成のOSをインストールし、受信SSHを無効にし、厳格なネットワークのエグレス制御を適用するよう求めています。これは妥当な責任分担ですが、サプライチェーンのエビデンスは、自社チームがエージェントの周りに何を構築するか次第ということになります。

CRACIでは、そのレイヤーがランナーに標準で備わっています。各ジョブの実行中、パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットへの通信を記録します。依存関係のエビデンスはCIキャッシュと一緒に引き継がれます。すべてのジョブがCycloneDXまたはSPDXのSBOMを作成し、ジョブごと・キャッシュごとにComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかの完全性の状態が付きます。

自前で構築しなくてよいエグレスポリシー

CRACIのエグレスポリシーはデフォルト拒否またはデフォルト許可で、24種類の組み込みソフトウェアソースプリセット、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソース、そして明示的なTLS、TCP、UDP、ICMPのルールを備えています。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。

来歴と監視

APIからSBOM、ネットワークトレース、来歴を取得できます。CRACIは来歴に署名しません。ビルドとリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを再評価し続けます。

トレードオフ

CRACIは現在マネージド型で提供しており、顧客ホスト型ランナーはEnterprise向けにロードマップに含まれています。ジョブはCRACIのインフラ上の分離された仮想マシンで実行され、ソースコードはビルドの間だけジョブVM内で処理され、保存されません。Enterpriseプランでは、欧州のベアメタルインフラでビルドを実行するEUデータレジデンシーを提供しています。ポリシーで自社のハードウェア上でのビルドが求められる場合、その要件に合うのはBuildkiteのモデルであり、CRACIのモデルではありません。

どちらが適しているか

• Buildkite：自社のハードウェアやネットワークでビルドする必要がある場合、WindowsやmacOSのビルドを実行する場合、GitLabやBitbucketを使っている場合、あるいはコンピュートを所有するほうが得になる規模で運用している場合。
• CRACI：GitHub Actionsを使っていて、構築や運用の手間をかけずにビルドのエビデンスを得たい場合。記録された依存関係、エグレスポリシー、CRAのエビデンスを1つのランナーから得られます。
• 両方：組織内で分かれている場合。自社のハードウェアにとどめる必要があるパイプラインにはBuildkite、LinuxのGitHub ActionsワークフローにはCRACIを使います。Yoctoイメージのような重いLinuxビルドは、CRACIのYoctoガイドにあるように、最大32 vCPU、96 GBのRAMを備えたCRACIランナーで実行できます。

Cyber Resilience Actへの対応

EUのCyber Resilience Actはメーカーに対し、各リリースに何が含まれているかを把握し、その脆弱性に対処することを求めています。報告義務は2026年9月から、全面適用は2027年12月からです。Buildkiteでは、そのエビデンスはエージェント上で実行するツールから得ることになります。CRACIはビルドの記録からエビデンスを作成し、出荷したものを監視し続け、SBOMを脆弱性を含めてCycloneDXまたはSPDXでエクスポートします。企業がより広いCRAコンプライアンスのプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。

CRACIの導入

GitHub上にあり、GitHub Actionsのワークフローを持つリポジトリであれば、組織にCRACI GitHub Appをインストールし、ランナーラベルを設定します。

runs-on: craci

実行結果は引き続きGitHubのUIに表示されます。ビルド時のSBOM生成やCRACIのセキュリティへの取り組みについて詳しくご覧いただくか、料金をご確認ください。