CRACIとCircleCIの比較

結論

CircleCIは成熟した柔軟なCI/CDプラットフォームです。GitHub、GitLab、Bitbucketに接続し、DockerコンテナからmacOS、GPUまで幅広いマシンでジョブを実行し、再利用可能な設定をorbとしてパッケージ化できます。セキュリティ面では、CircleCIは認証情報を保護し、スキャンはorbとサードパーティのツールに任せています。

CRACIは別のアプローチを取ります。ランナーそのものがセキュリティの記録になるのです。CRACIはGitHub Actionsのジョブを実行し、各ビルドが取得するすべての外部依存関係を観測し、ビルドネットワークにエグレスポリシーを適用し、観測した内容からSBOM、来歴データ、CRAのエビデンスを生成します。これが、従来型のCIとセキュリティを意識したCIの違いです。

CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。CircleCIにはまだ対応していません。CircleCIを利用しているチームがCRACIのランナーを使うには、パイプラインをGitHub Actionsに移行するか、ロードマップに掲載されているその他のCIシステムへの対応を待つ必要があります。

CircleCIが優れている点

幅広いコンピューティング。CircleCIはDocker、Linux VM、Arm、Windows、macOS、GPUのリソースクラスを提供しており、1つのプラットフォームでバックエンド、Windowsクライアント、iOSアプリをビルドできます。セルフホストランナーにより、それを自社のLinux、Windows、macOSのマシンやKubernetesにまで広げられ、ランナーでのジョブ時間はクレジットを消費しません。

高速化機能。Dockerレイヤーキャッシュは全プランで利用できます。テスト分割は、名前、ファイルサイズ、過去の実行時間データに基づいてテストスイートを並列エグゼキューターに分散し、大規模なテストスイートの実時間を短縮します。

再利用可能な設定。orbはジョブ、コマンド、エグゼキューターをパッケージ化し、チームがプロジェクトをまたいで再利用できるようにします。セキュリティスキャナーを含むサードパーティのツールも簡単に組み込めます。

認証情報の衛生管理。CircleCIのサプライチェーンに関するガイダンスは、シークレットの保護が中心です。シークレットをコンテキストに分割し、デプロイ鍵や署名鍵はVCSのグループで管理される制限付きコンテキストに置き、OIDCトークンを使って、CircleCIに長期間有効な認証情報を保存せずにジョブがクラウドサービスにアクセスできるようにします。

CRACIの違い

ビルドが信頼できる情報源

従来型のCIプラットフォームでは、SBOMはパイプラインに追加したツールが生成し、通常はマニフェストとロックファイルを読み取ります。CRACIは代わりにビルドを観測します。ジョブの実行中に、パッケージを認識するプロキシがパッケージソースへの通信を記録します。対象はnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットです。依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュから復元されたパッケージも漏れなく数えられます。

SBOMの完全性が分かる

すべてのジョブが、ジョブごと・キャッシュごとの完全性の状態を付けたCycloneDXまたはSPDXのSBOMを生成します。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。

ビルドネットワークにポリシーがある

CircleCIのIP範囲機能は、ジョブを既知のCircleCIのアドレス経由でルーティングし、自社システムで許可リストに登録できるようにします。これはインバウンドのアクセスを解決するものです。CRACIは逆方向の制御を加えます。ジョブごとのエグレスポリシーで、デフォルト拒否またはデフォルト許可を選べ、24種類の組み込みソフトウェアソースプリセット、型付きカスタムソース、明示的なTLS、TCP、UDP、ICMPのルールを設定できます。ポリシーはジョブの開始前に検証され、フェイルクローズで動作します。CRACIは固定のエグレスIP範囲も提供します。

同じ記録から来歴と監視

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

どちらが適しているか

• CircleCIを使い続けるのが適しているのは、コードがGitLabやBitbucketにある場合、Windows、macOS、GPUのビルドに依存している場合、または自社のハードウェアでジョブを実行している場合です。
• CRACIを検討すべきなのは、コードがGitHubにあり、GitHub ActionsとCircleCIを比較検討していて、各リリースに何が含まれたかを示す必要のあるソフトウェアを出荷している場合です。
• 両方を併用するのは段階的に移行する間です。macOSとWindowsのパイプラインはCircleCIに残し、ビルドのエビデンスが最も重要なLinuxのGitHub ActionsワークフローをCRACIで実行します。

Cyber Resilience Actへの対応

EUのCyber Resilience Actは、製造業者に各リリースの中身を把握し、その脆弱性に対処することを求めており、報告義務は2026年9月から、全面適用は2027年12月からです。CircleCIでは、そのエビデンスはパイプラインに組み込んだスキャナーやorbから得られます。CRACIはビルド記録からエビデンスを生成し、SBOMを脆弱性を含めてCycloneDXまたはSPDXでエクスポートします。企業がCRAコンプライアンスのプロセス全体で必要とする、ソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。

パイプラインをCRACIに移行する

CRACIはGitHub Actionsのワークフローを実行するため、CircleCIのパイプラインにはまずGitHub Actions版が必要です。それができたら、組織にCRACI GitHub Appをインストールし、ランナーラベルを設定します。

runs-on: craci

実行結果はこれまでどおりGitHubのUIに表示されます。ジョブではDocker Engine、Buildx、Compose v2が使え、ランナーサイズは1～32 vCPU（1 vCPUあたり3 GBのRAM）で、GitHub Actionsのキャッシュにも対応しています。詳しくはビルド時のSBOM生成をご覧いただくか、料金とスタートアッププログラムをご確認ください。