CRACIとApiiroの比較

結論から

Apiiroは、アプリケーションセキュリティポスチャ管理（ASPM）のプラットフォームです。Deep Code Analysisがコードからランタイムまでソフトウェアアーキテクチャをマッピングし、Risk GraphがApiiro自身のスキャナーとサードパーティツールの検出結果を相関分析します。ソフトウェアサプライチェーンセキュリティ（SSCS）モジュールは、リポジトリとパイプラインのインベントリを作成し、脆弱なブランチ保護、パイプラインの設定ミス、異常なコミットなどのリスクを検知します。

CRACIは、同じ「ソフトウェアサプライチェーンを守る」予算を、異なる立場から争います。CRACIはお客様のGitHub Actionsのジョブを実行します。Apiiroは、コードとパイプラインの設定から何が起こるはずかを推論します。CRACIはビルドが実際に何をしたかを記録し、ネットワークのエグレスを制御し、出荷したものを監視し続けます。大規模なAppSecプログラムでは両方を運用することもあります。各リリースに何が含まれたかのエビデンスが最優先のチームは、CRACIから始めるとよいでしょう。

概要

Apiiroの強み

• CIを変更せずにアーキテクチャのコンテキストを把握。ApiiroはAPI連携でソースコード管理システムに接続し、CI/CDの設定や保守は不要としています。Deep Code AnalysisはAPI、機密データ、生成AIフレームワーク、コードの所有者をマッピングし、コミットや重要な変更のたびに更新します。
• AIコーディングのセキュリティ。2026年1月に提供が始まったGuardian Agentは、AIコーディングアシスタントと連携し、脅威モデル、コンプライアンスポリシー、アーキテクチャに基づくセキュリティガイドラインを開発者のプロンプトに追加することで、アシスタントが脆弱なコードを書く前に方向修正します。AI Threat Modelingは2026年3月に続いて提供されました。
• 幅広さ。Apiiroは、ネイティブのAI SAST、AI SCA、SSCS、シークレット、Infrastructure as Code、コード内のAPIセキュリティ、コード向けDSPM、AI脅威モデリングを掲げています。CRACIはこのリストにあるコードスキャンをいずれも行いません。
• 優先順位付け。Risk Graphは検出結果を取り込み、重複を排除し、相関分析したうえで、それらを「有害な組み合わせ」として連鎖させます。Apiiroの例では、PIIを保持するリポジトリが、脆弱なパイプラインでビルドされ、必須レビュアーのいないブランチにコミットを受けている場合、3つの中程度の検出結果が1つの重大なリスクになります。
• ソフトウェアファクトリーのインベントリ。SSCSは、シャドーパイプラインを含むリポジトリとCI/CDパイプラインのインベントリを、コントリビューター、権限、プラグイン、依存関係とともに作成します。パイプラインの依存関係の脆弱性をライフサイクル全体で追跡し、ガードレールでリスクのあるコミットやマージをブロックできます。
• 依存関係の分析と修正。AI SCAは、脆弱な関数が実際に呼び出されているかを確認し、依存関係をデプロイ済みのコンテナや公開エンドポイントと照合し、悪意あるパッケージを検知し、ライセンスポリシーを適用します。AutoFixは、ApiiroによればAPI互換性が事前検証されたバージョンアップを提供します。
• 連携。ソース管理ではGitHub、GitLab、Azure DevOps、Bitbucket、Perforce、パイプラインの態勢ではJenkinsとGitHub Actions、さらに多数のスキャナー、レジストリ、チケット管理ツールに対応しています。

CRACIの違い

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

ApiiroのXBOMはコードの解析によって構築されます。すべてのパッケージ、API、AIモデル、ライセンスを含み、コード変更のたびに更新されます。これは、コードが宣言し使用しているものの優れた全体像です。しかしビルドは、コードが示す以上のことをしばしば行います。インストールスクリプトを実行し、ツールチェーンをダウンロードし、キャッシュを復元し、ベースイメージを取得し、リリースバイナリを取得します。

CRACIはランナーそのものであるため、こうした動作を把握できます。ジョブの実行中、パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットへの通信を監視します。依存関係のエビデンスはCIキャッシュとともに引き継がれるため、キャッシュから復元されたパッケージも記録に残ります。すべてのSBOMはジョブとキャッシュごとに完全性の状態（Complete、Complete with connections、Incomplete、Unavailable、Not recorded）を持ちます。記録に欠落があれば、それがわかります。

態勢だけでなく、ランナーでの制御

Apiiroは、パイプラインの設定に誤りがある場合や改ざんの余地がある場合に知らせてくれます。CRACIは、ビルドの実行中にそのアクセス先を制限します。エグレスポリシーはデフォルト拒否またはデフォルト許可で、24種類の組み込みソフトウェアソースプリセット、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソース、明示的なTLS、TCP、UDP、ICMPのルールを備えています。ポリシーはジョブ開始前に検証されてフェイルクローズで動作し、違反があればCRACIがアラートを出せます。

APIによるビルドのエビデンス

APIはSBOM、ネットワークトレース、来歴を返します。

出荷後

CRACIは、新たな脆弱性が公開されるたびに出荷したもののSBOMを再評価し続け、ビルドとリポジトリを横断して検出結果を集約します。

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

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

Apiiroが先行している点

率直に言えば、CRACIにはSAST、シークレット、IaC、APIセキュリティのスキャンがなく、他のスキャナーの検出結果を取り込まず、ブランチ保護やリポジトリの権限を監査せず、現在はGitHub Actionsのみに対応しています（GitLab CIとJenkinsはロードマップに掲載）。なお、CRACIはポリシーゲートでビルドをブロックし、ライセンスポリシーを適用します。すべてのコードにわたってリスクに優先順位を付ける1つのプラットフォームが必要なら、Apiiroのほうがはるかに広い範囲をカバーしています。

どちらが適しているか

Apiiroが適している場合

• 多数のスキャナー、リポジトリ、SCMシステムにまたがる単一のASPMプラットフォームが欲しい。
• アーキテクチャのコンテキストが優先事項：どのコードがインターネットに公開され、PIIを扱い、重要な変更があったか。
• GitLab、Azure DevOps、Bitbucket、Jenkinsにわたるリポジトリとパイプラインの態勢管理が必要。

CRACIが適している場合

• GitHub Actionsでビルドしており、ランナー、エグレスポリシー、依存関係の記録を1か所にまとめたい。
• 各ビルドが取得したもののSBOMを、監査人に示せる完全性の状態付きで必要としている。
• 出荷したもののモニタリングとCRAのエビデンスが必要。

両方を使う

Apiiroは現在、自らをエージェント型開発のセキュリティを担うものと位置付けています。Guardian AgentはAIコーディングアシスタントをコードが書かれる前に安全なコードへ導き、XBOMはリポジトリ内のコードの解析から作られます。CRACIはランナーにセキュリティを組み込んだCI/CDであるため、そのSBOMは各ビルドが実際に取得したものを記録します。そこには、インストールスクリプト、ツールチェーン、キャッシュされたパッケージ、ベースイメージといった、コード解析では見えないものも含まれます。Apiiroはコードが書かれる場所で、CRACIはコードがビルドされ出荷される場所で機能します。CRACIが置き換えるのはランナーであり、GitHub Actionsではないため、Apiiroのパイプライン連携はそのまま動作します。

Cyber Resilience Actへの対応

Cyber Resilience Actは、製造業者に対し、各製品に含まれるコンポーネントを把握し、その脆弱性に対処し、エビデンスを保持することを求めています。ASPMプラットフォームは、セキュアな開発と、コード内の脆弱性への対処に役立ちます。CRACIは、企業がより広いCRAコンプライアンスプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。ビルド時SBOM、脆弱性トラッキング、来歴、そしてCycloneDXまたはSPDXでのSBOMエクスポートです。どちらのツールも、単体でコンプライアンス準拠にするものではありません。CRAコンプライアンスをご覧ください。

CRACIの導入

組織にCRACIのGitHub Appをインストールし、ジョブのランナーラベルをruns-on: craciに変更します。実行は引き続きGitHubのUIに表示されます。まずはリリース成果物を生成するワークフローを1つ選び、CRACIのSBOMを現在のインベントリと比較してください。CI/CD連携、ビルド時SBOM生成、料金の詳細もご覧ください。