CRACIとHarnessの比較

結論から言うと

2017年に創業し、サンフランシスコに本社を置くHarnessは、コードが書かれた後のすべてを担うプラットフォームを提供しています。継続的インテグレーション、継続的デリバリー、フィーチャーフラグ、クラウドコスト管理、カオスエンジニアリング、セキュリティテストです。Supply Chain Security（SCS）モジュールは、SBOM生成、SLSAの来歴、OPAのポリシーゲート、リポジトリとパイプラインのポスチャーチェックを追加します。複数のGitプロバイダーにまたがるデリバリーパイプライン全体を1つのベンダーでまかないたいなら、Harnessはそのために作られています。

CRACIの対象はより狭く、その分ビルドの奥深くまで踏み込みます。CRACIはGitHub Actionsのランナーです。各ジョブの実行中に、ビルドが取り込むすべての外部依存関係を記録し、ビルドのネットワークにエグレスポリシーを適用し、その記録からSBOM、来歴データ、脆弱性監視を生み出します。Harnessはパイプラインにサプライチェーンのステップを追加し、CRACIはランナーそのものをセキュリティの記録にします。

まず実務上のポイントがあります。CRACIは現在GitHub Actionsのみに対応しており、GitLab CIとJenkinsはロードマップに掲載されています。Harness CIのパイプラインをCRACIで実行するには、GitHub Actionsへの移行が必要です。

一覧で比較

Harnessの強み

デリバリーのための1つのプラットフォーム。HarnessはCI、CD、GitOps、フィーチャーフラグ、Infrastructure as Code、カオスエンジニアリング、クラウドコスト管理をカバーし、それらすべてにOPAベースのポリシー適用を備えています。GitHub、GitLab、Bitbucket、Azure Repos、そして独自のHarness Codeリポジトリに対応しており、1,000社以上のエンタープライズ顧客にサービスを提供し、従業員は1,200人以上としています。

ビルドインフラの選択肢。Harness Cloudは、Harnessが管理するLinux、Windows、macOSのマシンでビルドを実行します。Linux AMD64は2～96コア、ARM64は同じ料金で2～64コア、macOSはApple M4です。Linux AMD64ではネストされた仮想化を利用できます。自社のKubernetesクラスター、VM、ベアメタルでビルドを実行することもできます。Test Intelligenceは変更の影響を受けるテストだけを実行し、Build Intelligenceとキャッシュ機能は変更のない出力と依存関係を再利用します。

パイプライン内のサプライチェーン機能。SCSモジュールのSBOM Orchestrationステップは、SyftまたはcdxgenでコンテナイメージやコードリポジトリのSBOMをSPDXまたはCycloneDXで生成し、他のツールのSBOMを取り込むこともできます。Harnessは、すべてのビルドでSBOMを生成・更新するとしています。OPAポリシーにより、コンポーネント、ライセンス、来歴に基づいてビルドとデプロイをブロックでき、修正トラッカーが脆弱なアーティファクトを追跡します。

SLSAの来歴。HarnessはSLSA v1.0のSLSA Build Level 1、2、3について文書化しており、来歴はin-totoの構成証明とcosignで署名されます。ドキュメントによると、Level 3には強化されたビルドインフラか、ビルドプロセスを相互に隔離するHarness Cloudが必要です。

ポスチャーとパイプラインのチェック。SCSは、リポジトリとパイプラインをOWASP Top 10 CI/CD Security RisksとCISベンチマークに照らして監査し、ピン留めされていない、検証されていない、過剰な権限を持つGitHub Actionsを検出します。HarnessはSCSのステップをGitHub ActionsとGitLab CI/CDのコンポーネントとしても提供しているため、このモジュールはHarness CIに縛られません。ただし、これらのステップにはSCSライセンスを持つHarnessアカウントが必要です。

CRACIの違い

SBOMは出力のスキャンではなく、ビルドから生まれる

Syftとcdxgenはスキャナーです。事後にイメージやリポジトリを読み取り、ロックファイル、マニフェスト、パッケージデータベースから中身を推定します。それらのファイルがすべてを語っている場合はうまくいきます。しかし、ビルドはそれ以上のことをよく行います。インストールスクリプトがコードをダウンロードし、Rustのビルドスクリプトがビルド時に取得を行い、キャッシュがどのロックファイルにも記載されていないパッケージを復元します。

CRACIはランナーそのものなので、その通信が見えます。パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットにわたって、各ジョブがパッケージソースから取得したものを記録し、依存関係のエビデンスはCIキャッシュと一緒に引き継がれます。ロックファイルベースのツールが見落とす隠れた依存関係を記録し、各SBOMはジョブごと、キャッシュごとにどれだけ完全かを、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかで示します。

事後の検知ではなく、ビルドのネットワークに対するポリシー

Harnessは、同社のモジュールがネットワーク呼び出しや権限昇格を含むCIランナーの異常な挙動を検知するとしています。CRACIは別の道を取ります。ランナーでのエグレスポリシーが、ジョブがアクセスできるホストを決めます。ポリシーはデフォルト拒否またはデフォルト許可で、24種類の組み込みのソフトウェアソースプリセットと型付きのカスタムソースを備え、ジョブ開始前に検証され、フェイルクローズで動作します。デフォルト拒否のポリシーは、既知の悪意あるホストを探すのではなく、ビルドに必要なものだけを許可するため、誰も見たことのない攻撃であっても、攻撃者のサーバーへの持ち出しをブロックします。違反時にはアラートが送られます。

同じ記録から来歴と監視を

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名せず、SLSAレベルも主張していません。Harnessは来歴に署名し、Level 1～3を文書化しています。署名付きの来歴やSLSAレベルが調達要件であれば、それはHarnessの強みになります。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、アドバイザリが公開されるたびに監視対象のSBOMを再評価し続け、脆弱な依存関係を含んでいた過去のビルドを表示するため、影響を受けていた期間がわかります。

わかりやすい料金

CRACIの課金はビルド時間のみです。1vCPU分あたり$0.002（デフォルトの2 vCPUランナーでは$0.004）で、秒単位で計測され、月額料金もSBOMごとの課金もありません。HarnessはHarness Cloudの料金を公開しており、2コア・7 GBのLinuxマシンで1分あたり$0.005、32コアで$0.080、最も近い分単位で請求されます。一方、有料プランとSCSモジュールの料金は営業経由です。CRACIの定価は、どちらのサイズでも1分あたり20%低くなります（$0.004対$0.005、$0.064対$0.080）。なお、Harnessのマシンはコアあたりのメモリがより多くなっています。

どちらが適しているか

• Harnessを使い続けるべきケース：CI、CD、フィーチャーフラグ、コスト管理を1つのベンダーでまかないたい場合、コードがGitLab、Bitbucket、Azure Repos上にある場合、Windows、macOS、または自社のビルドハードウェアが必要な場合、あるいは文書化されたSLSA Build Level 3が要件である場合。
• CRACIを選ぶべきケース：コードがGitHub上にあり、GitHub Actionsを使っている、または使う予定で、SBOM、ネットワークポリシー、来歴をビルドを実行したランナーから得たい場合。料金はビルド時間単位です。

CRACIを選ぶことで失うものも明確にしておきます。CRACIはソフトウェアのデプロイ、フィーチャーフラグの運用、クラウドコストの管理は行わず、リポジトリやパイプラインのポスチャーベンチマークに照らしたチェックやソースコードのスキャンも行いません。現在はLinuxのジョブのみを実行し、WindowsとmacOSはロードマップに掲載されています。顧客ホスト型ランナーはEnterprise向けにロードマップに掲載されています。

規制対象の製品について

EUのCyber Resilience Actなどのフレームワークは、メーカーが各リリースに何が含まれているかを把握し、その脆弱性に対応することを求めており、報告義務は2026年9月から適用されます。HarnessはパイプラインのステップからSBOM、来歴、ポリシーの結果を提供します。CRACIはビルドの記録からエビデンスを生成し、SBOMをCycloneDXまたはSPDXでエクスポートします。企業がより広範なCRAのプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、どちらのツールもそれだけで製品を準拠させるものではありません。

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

CRACIが置き換えるのはランナーであり、GitHub Actionsではありません。実行結果は引き続きGitHubのUIに表示されます。パイプラインがGitHub Actionsのワークフローとして動くようになれば、1行でCRACI上で実行できます。

runs-on: craci

詳しくはビルド時SBOM生成をご覧ください。CI/CDプラットフォームの比較、Harnessの代替ツール、料金もあわせてご確認ください。