CRACIとJFrog Artifactory

同じサプライチェーンを見る2つの視点

多くのエンジニアリング組織は、パッケージの通信をJFrog Artifactory経由にしています。リモートリポジトリは、npmやPyPIなどのパブリックレジストリのキャッシュプロキシとして機能し、必要に応じてパッケージを取得してコピーを保持します。バーチャルリポジトリは、複数のソースを1つのURLの背後にまとめます。自社のビルド成果物はローカルリポジトリに置かれます。これにより、社内に入ってくるものを一か所で把握・管理できます。

CRACIは別の場所に位置します。CRACIはGitHub Actionsのジョブが実行されるCIランナーであり、各ジョブの実行中に、ジョブが取り込む外部依存関係を記録します。Artifactoryが答えるのは「自社のリポジトリを何が流れたか」という問いです。CRACIが答えるのは「この特定のビルドは何を使い、そこからどの成果物が生まれたか」という問いです。

Artifactoryの強み

Artifactoryは成熟したリポジトリマネージャーです。上流パッケージへの信頼性の高いキャッシュ付きアクセス、社内成果物の保管場所、そして多数のパッケージタイプを一元管理するコントロールポイントをチームに提供します。その周囲で、JFrog Platformはさらに機能を加えています。

• Build-info。JFrog CLIを使い、コマンドにビルド名と番号を追加して、解決された依存関係、生成された成果物、環境変数、Gitの詳細を記録したJSONを公開します。この記録はトレーサビリティ、ビルドのプロモーション、Xrayによるスキャンを支えます。
• Xray。成果物とビルドの脆弱性をスキャンし、SPDXとCycloneDXでSBOMをエクスポートします。JFrogのライセンス表では、XrayはPro X、Enterprise X、Enterprise+のサブスクリプションに含まれるとされています（2026年9月時点）。
• Curation。悪意のあるパッケージや脆弱なパッケージを、開発者に届く前にリモートリポジトリでブロックします。リモートキャッシュにすでにあるパッケージも対象です。

レジストリでのパッケージ単位のブロックは確かな強みです。CRACIは現在、個々のパッケージをブロックしません。組織全体でのパッケージのブロックリストはCRACIのロードマップに掲載されています。

CRACIが加えるもの

経路に依存しない可視性

Artifactoryが把握できるのは、Artifactoryを経由したものです。ビルドが常にその経路に従うとは限りません。ジョブはGitHubのリリースからツールチェーンをダウンロードしたり、OSパッケージをインストールしたり、パブリックレジストリからベースイメージを取得したり、バイナリを取得するスクリプトを実行したりします。JFrog自身のドキュメントにも、他のツールが取得した依存関係は build-add-dependenciesで手動登録できると記載されています。つまり、誰かがそれを把握している必要があります。

CRACIはランナーで記録します。パッケージを認識するプロキシが、ジョブ中のパッケージソースへの通信を観測します。対象はnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースに加え、ダウンロードプリセットです。npmやPyPIのインストールがArtifactoryのミラーを経由する場合も問題なく動作し、CRACIはそれらのパッケージも記録します。

追加の手順なしでビルドごとのエビデンス

Build-infoは有用ですが、各パイプラインに追加する必要があります。CRACIでは、ランナーが記録を生成するため、すべてのジョブに記録が存在します。依存関係のエビデンスはCIキャッシュとともに引き継がれるため、キャッシュから復元されたパッケージも記録に含まれます。すべてのSBOMは、ジョブごと・キャッシュごとに完全性の状態を持ちます。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。記録に抜けがあれば、そのことが明示されます。

ビルドを承認済みの経路に留める

CRACIはジョブを実行するため、そのネットワークのエグレスポリシーを設定できます。ポリシーはデフォルト拒否またはデフォルト許可で、24の組み込みソフトウェアソースプリセット、型付きカスタムソース（npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git）、そして明示的なTLS、TCP、UDP、ICMPルールを備えています。ポリシーはジョブの開始前に検証され、フェイルクローズで動作します。Artifactoryのホストを許可し、パブリックレジストリへの直接アクセスを拒否するポリシーにすれば、ビルドが実際に管理された経路を使うことを確実にしやすくなります。ジョブがポリシーに違反すると、CRACIがアラートを送ります。

Artifactoryと並ぶビルドのエビデンス

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名しません。成果物はこれまでどおりArtifactoryに保管し、ビルドが取得したものの記録はCRACIから得られます。

EUのCyber Resilience Actに対応するチームにとって、その記録はリリース単位のエビデンスになります。CRACIはビルドやリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを継続的に再評価し、CycloneDXまたはSPDXとしてエクスポートします。CRAのエビデンスと CRAコンプライアンスをご覧ください。

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

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

両者の組み合わせ方

1. Artifactoryは引き続き、パッケージプロキシ、成果物ストア、リリースの配布拠点として使います。
2. runs-onをcraciに変更して、GitHub ActionsのジョブをCRACIに移行します。ワークフローはそのままで、実行結果は引き続きGitHubのUIに表示されます。
3. npmとPyPIのインストールは、これまでどおりArtifactoryのミラーに向けます。
4. CRACIのエグレスポリシーを使い、ビルドをArtifactoryを含む承認済みのソースに留めます。
5. CRACIのビルドごとのSBOM、来歴、ネットワークトレースを、各リリースのエビデンスとして使います。

現在JFrogのBuild-infoやCurationを利用しているなら、そのまま使い続けてください。CRACIは現在GitHub Actionsのみに対応しており（GitLab CIとJenkinsはロードマップに掲載）、他のCIシステム上のパイプラインはそのままです。

Artifactory自体を置き換える場合は、 JFrog Artifactoryの代替ツールをご覧ください。

よくあるご質問

CRACIはArtifactoryを置き換えますか？

いいえ。CRACIはリポジトリマネージャーではありません。パッケージやリリースバイナリを保管することも、配布することもありません。ビルドを実行し、それに関するエビデンスを記録します。

CRACIはXrayと重複しますか？

一部重複します。どちらもCycloneDXとSPDXでSBOMをエクスポートし、どちらも脆弱性のトラッキングに役立ちます。違いは入力です。XrayはJFrogが把握している成果物とビルドをスキャンします。CRACIのSBOMと脆弱性ビューは、ビルドやリポジトリをまたいで、各ビルドが実行中に取得したものから得られます。Xrayがリリースプロセスに組み込まれているなら、それを維持し、CRACIのビルドごとの記録を独立した第2の情報源として扱ってください。

どのArtifactoryリポジトリタイプがCRACIで動作しますか？

ArtifactoryのnpmとPyPIのミラーは、CRACIのビルドで動作することが確認されています。その他のパッケージタイプについては、該当するパイプラインを移行する前に、構成についてご相談ください。