CRACIとGitLab CIの比較

結論

GitLabは包括的なDevSecOpsプラットフォームです。ソース管理、マージリクエスト、計画、CI/CDを1つの製品にまとめ、Ultimateプランでは幅広いセキュリティスキャナーと脆弱性管理を提供します。ソフトウェアライフサイクル全体を1社のベンダーにまとめたいなら、GitLabはまさにそのために作られています。

CRACIの対象はより絞られています。GitHub Actions互換のランナーとして、ビルドが取得するすべての外部依存関係を記録し、ビルドの到達先を制御し、その記録をSBOM、来歴データ、CRAのエビデンスに変換します。根本的な違いは、スキャナーを付け加えた従来型のCIか、ランナー自体がセキュリティの記録となるCIか、という点です。

まず実務上の注意点があります。CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。パイプラインがGitLab CIにある場合、CRACIランナーを使うにはGitHub Actionsへ移行するか、ロードマップに掲載されているGitLab CI対応を待つ必要があります。

GitLabの強み

1つのプラットフォーム。コード、レビュー、パイプライン、セキュリティの検出結果、計画が同じ場所にあり、権限モデルも1つです。多くの組織にとっては、それだけで決め手になります。

プランごとのセキュリティスキャン。各プランに何が含まれるかは正確に把握しておく必要があります。GitLabによると、基本的なSAST、シークレット検出、コンテナスキャンはFreeを含む全プランで実行できます。FreeとPremiumでは、これらのスキャンはJSONレポートの成果物を生成します。Ultimateではその周辺のワークフローが加わります。マージリクエスト内の検出結果、脆弱性レポート、依存関係リスト、セキュリティ承認、そしてGitLab Advanced SASTです。依存関係スキャン、継続的な脆弱性スキャン、DASTはUltimateの機能です。コンテナスキャンは全プランでCycloneDXのSBOMレポートも生成できます。

来歴。GitLab Runnerは、全プランでSLSA 1.0形式の成果物の来歴ステートメントを生成できます。署名付きのSLSA Level 3構成証明もありますが、GitLabはこれをGitLab.comのUltimate向けの実験的機能と位置付けており、デフォルトで無効の機能フラグの背後にあります。

ランナーの選択肢。GitLabホスト型ランナーは、x86-64（2～32 vCPU）とarm64のLinuxに対応し、WindowsとmacOSはベータ版です。自社のランナーをどこでも実行することもでき、GitLabによれば自社ランナー上のジョブはコンピューティング分を消費しません。GitLab Dedicatedでは、選択したリージョンでのデータ所在地も指定できます。

CRACIの違い

SBOMはロックファイルではなくビルドから

GitLabのSBOMベースの依存関係スキャンは、対応するロックファイルや依存関係グラフのエクスポートから依存関係を検出します。ロックファイルがすべてを物語っている場合、これは堅実な方法です。しかし実際のビルドは、それ以上のことをよく行います。インストールスクリプトを実行し、ツールチェーンをダウンロードし、キャッシュを復元し、ベースイメージを取得します。

CRACIはランナーそのものなので、そうした動作を見ています。パッケージを認識するプロキシが、ジョブの実行中にパッケージソースへの通信を観測します。対象はnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースと、ダウンロードプリセットです。依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュから復元されたパッケージも記録から漏れません。すべてのジョブがCycloneDXまたはSPDXのSBOMを生成します。

完全性は前提ではなく明示される

各SBOMには、ジョブごと・キャッシュごとの完全性の状態（Complete、Complete with connections、Incomplete、Unavailable、Not recorded）が付きます。記録に欠落があれば、それを確認できます。

ビルドのネットワークをポリシーで管理

CRACIのエグレスポリシーはデフォルト拒否またはデフォルト許可で、24の組み込みソフトウェアソースプリセットと、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソースを使えます。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。GitLabでは、ビルドのネットワーク制御は自社ランナーの周囲に自分で構成するものに限られます。

来歴

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名せず、SLSAレベルも主張しません。

出荷したものの監視

CRACIはビルドとリポジトリをまたいで脆弱性を集約し、新しいアドバイザリの公開に応じて監視対象のSBOMを継続的に再評価します。

どちらが適しているか

• コードとパイプラインがGitLabにあり、1つのプラットフォームにまとめたい場合、またはSAST、DAST、シークレット検出を同じ製品で必要とする場合は、GitLabを使い続けてください。
• コードがGitHubにあってGitHub Actionsを使っており、各リリースに何が入ったかのエビデンス、ビルドの到達先の制御、監査で説明できるSBOMが必要な場合は、CRACIを選んでください。
• 組織で両方のプラットフォームを使っている場合は、両方を使ってください。GitLabはそのプロジェクトとスキャナーを引き続き担い、CRACIはGitHub Actions側を実行してそのビルドを記録します。

Cyber Resilience Actへの対応

EUのCyber Resilience Actのもとで、メーカーは製品の各リリースに何が含まれているかを把握し、その脆弱性に対処する必要があります。脆弱性の報告義務は2026年9月から適用され、規則は2027年12月から全面適用されます。GitLab Ultimateは、プロジェクト全体での脆弱性の発見と管理を支援します。CRACIは各リリースが何からビルドされたかを記録し、監視を続け、SBOMをCycloneDXまたはSPDXでエクスポートします。企業がより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、どちらのツールもそれだけで準拠させるものではありません。

CRACIの追加

GitHub上のリポジトリでは、CRACI GitHub Appを組織にインストールし（全リポジトリまたは選択したリポジトリ）、ランナーのラベルを変更します。

runs-on: craci

ワークフロー、アクション、GitHubのUIはそのままです。CRACIが置き換えるのはランナーであり、GitHub Actionsではありません。ビルド時のSBOM生成とCRAのエビデンスについて詳しくご覧いただくか、料金をご確認ください。