CRACIとAikidoの比較

統合か、エビデンスか

チームがAikidoを検討するのは、たいていセキュリティツールの数を減らしたいからです。Aikidoはオープンソースの依存関係、自社コード、シークレット、Infrastructure as Code、コンテナ、クラウドのセキュリティ態勢、動的テスト、実行時保護を1つの製品でカバーし、検出結果のトリアージも1か所で行えます。幅広いカバー範囲をすばやく必要とする小規模チームにとって、これは魅力的な提案です。

チームがCRACIを検討する理由は、より限定的です。ビルドが実際に何をしたかを把握し、ビルドの到達先を制御し、顧客や監査人の前でも通用する各リリースのエビデンスを作成する必要があるのです。CRACIは、CIランナーそのものになることでそれを実現します。

Aikidoの強み

最大の特長は幅広さです。Aikidoのすべてのプランに、SCA、SAST、シークレット検出、IaC、クラウドのセキュリティ態勢、コンテナスキャン、DAST、ライセンススキャン、SBOM生成が含まれています。SCAは関数レベルの到達可能性でノイズを削減し、AutoFixはパッチ適用済みバージョンでプルリクエストを作成します。CIでは重大なリスクのあるプルリクエストをブロックでき、GitHub、GitLab、Jenkins、Bitbucket、CircleCIなどと連携します。CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。

AikidoはSafe Chainも提供しています。npmとPyPIのパッケージマネージャーの前段でローカルプロキシを動かし、既知のマルウェアを含むパッケージをインストール前にブロックする無料ツールで、ローカルでもCIでも動作します。CRACIは現在、個々のパッケージをブロックしません。組織全体のパッケージブロックリストはCRACIのロードマップに掲載されていますが、製品にはまだ含まれていません。

コンプライアンス面では、Aikidoの上位プランにSOC 2とISO 27001のコンプライアンスレポートが含まれ、DrataやVantaなどのコンプライアンスプラットフォームと同期できます。主な目的がアプリケーションセキュリティの検出結果をSOC 2プログラムに提供することなら、Aikidoはそのために作られています。

CRACIの違い

CRACIはCIの実行環境

Aikidoの実行時保護は、稼働中のアプリケーションを守ります。CRACIが対象とするのは別の実行環境、つまりビルドジョブです。GitHub Actionsのジョブは、CRACIの隔離された仮想マシンで、1～32コンピューティングユニットのx86-64またはARM64ランナー上で実行されます。設定はruns-onをcraciに変更するだけです。ワークフローはそのままで、実行結果はこれまでどおりGitHubのUIに表示されます。

CRACIはジョブを実行するため、ジョブの実行中にエグレスポリシーを適用できます。ポリシーはデフォルト拒否またはデフォルト許可で、24の組み込みソフトウェアソースプリセットと、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソースを使えます。ジョブ開始前に検証され、フェイルクローズで動作します。スキャナーはリスクのあるパッケージの存在を教えてくれます。ネットワークポリシーは、ビルドが到達すべきでない場所への到達を阻止します。

決定論的なビルドのエビデンス

Aikidoはマニフェストとロックファイルから依存関係のビューを作成し、AIによる悪用可能性のチェックなどの分析を加えます。作業の優先順位付けとしては理にかなった方法です。

CRACIのSBOMは推測ではありません。パッケージを認識するプロキシがジョブがパッケージソースから取得したものを記録し、依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュから復元されたパッケージも数えられます。各SBOMは、ジョブごと・キャッシュごとに自らの完全性（Complete、Complete with connections、Incomplete、Unavailable、Not recorded）を明示します。推定ではなく実際に起きたことの記録であり、欠落がどこにあるかも示します。

これが重要なのは、静的なSBOMツールの結果は多くの人が思う以上に食い違い、その理由が構造的なものだからです。ツールごとに読み取るファイルが異なり、解決方法も異なるため、リポジトリに何が含まれているとされるかは、どのツールをどう設定して使ったかに左右されます。express 5.2.1のようにロックファイルをコミットしていないプロジェクトでは、ロックファイルを読むツールには解決するものが何もありません。CRACIはディレクトリをスキャンするのではなくビルドを記録するため、その条件では比較できません。そしてそれこそが要点です。ビルドの記録は、たまたまどのファイルが存在するかに左右されないのです。

APIで来歴データを取得

CRACIは独自のランナー内で、ジョブが取得したものからSBOMを生成します。APIはSBOM、ネットワークトレース、来歴を返します。

その記録に基づくコンプライアンスの成果

EU Cyber Resilience Actで難しいのは、各リリースに何が入ったか、そしてその脆弱性を長期にわたってどう追跡しているかを示すことです。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを継続的に再評価します。SBOMは脆弱性を含めてCycloneDXまたはSPDXでエクスポートでき、APIはSBOM、ネットワークトレース、来歴を返します。企業がより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。CRAコンプライアンスとCRAのエビデンスをご覧ください。

どこに何がデプロイされているかのインベントリ

CRACIのインベントリビューは、どのソフトウェアバージョンがどの製品にデプロイされているかを、全世界にわたって正確に表示します。新たな脆弱性が見つかったとき、リリースノートやスプレッドシートをつなぎ合わせなくても、影響を受けるバージョンを使っている製品を確認できます。

それぞれの適所

• コード、依存関係、クラウド、稼働中のアプリを1つのツールでカバーしたい場合、現在GitHub Actions以外のCIシステムを使っている場合、またはコンプライアンスの焦点がアプリケーションセキュリティの検出結果に基づくSOC 2やISO 27001のレポートである場合は、Aikidoを選んでください。
• GitHub Actionsでビルドしており、各ビルドが何を取得したかを正確に把握し、ビルドのネットワークアクセスを制御し、CRAや顧客の監査に向けてリリースのエビデンスを保管する必要がある場合は、CRACIを選んでください。
• Aikidoのスキャンとプルリクエストのゲートに加えて、CRACIのビルド実行環境の制御とエビデンスも欲しい場合は、両方を使ってください。AikidoのCIチェックとSafe Chainはワークフローのステップとして実行され、それらのステップは他のステップと同じようにCRACIランナーで実行できます。