CRACIとChainguard

結論から

Chainguardはオープンソースソフトウェアをソースからビルドし、堅牢化して提供しています。既知の脆弱性がほとんど、またはまったくない最小構成のコンテナイメージ、再ビルドされた言語ライブラリ、VMイメージ、堅牢化されたGitHub Actionsで、いずれも署名付きのSBOMと来歴が付いています。出発点となるベースイメージやパッケージに含まれるCVEが多すぎることが課題なら、Chainguardはまさにその課題に正面から取り組みます。

CRACIはGitHub Actions向けのCIランナーです。ジョブはCRACI上で実行され、実行中に取得するすべての外部依存関係を記録し、エグレスポリシーを適用します。Chainguardは入力を保護します。CRACIはビルドを保護し、記録します。重なる部分はごくわずかで、両者は自然に組み合わせられます。

一覧で比較

Chainguardが得意なこと

Chainguard Containersは、Chainguardの言葉を借りれば、ソースからビルドしたゼロCVEのコンテナイメージカタログです。すべてのイメージに、SPDX形式の署名付きSBOM構成証明と、ビルド環境を記述するSLSA 1.0の来歴構成証明が付いており、いずれもcosignで検証できます。新しいビルドでは、顧客はCycloneDXのSBOMも入手できます。

CVEポリシーも具体的です。発注済みの顧客に対し、Chainguardはサポート対象のバージョンストリームのイメージについて、適格なパッチが公開されてから重大なCVEは7暦日以内、高・中・低のCVEは14暦日以内に修正することを約束しています。

Chainguard Librariesは、同じアプローチを言語パッケージに適用します。ビルド済みの成果物としてダウンロードするのではなく、検証済みのソースから再ビルドしたJava、Python、JavaScriptの依存関係のカタログで、JFrog Artifactory、Sonatype Nexus Repository、Cloudsmithのアップストリームとして提供されます。各パッケージにはSigstoreの署名、署名付きのSBOM、SLSA Level 3の来歴が付いています。Chainguard Actionsは、人気のGitHub Actionsをソースからビルドし継続的にスキャンした堅牢化版を提供し、Chainguard VMsはこのモデルを仮想マシンイメージに適用します。

CRACIは堅牢化されたイメージやライブラリは作らず、取り込むもののCVE件数についても何も約束しません。それはChainguardの役割です。

CRACIの違い

Chainguardのビルドではなく、自社のビルドを見る

ChainguardのSBOMと来歴が記述するのは、Chainguardのファクトリーでビルドされた、Chainguardの成果物です。自社のビルドもどこかで実行されており、ベースイメージ以外にも多くのものを取り込んでいます。自社の依存関係、ツールチェーン、インストールスクリプトが取得するツール、そしてワークフローのステップがダウンロードするあらゆるものです。CRACIはそれを記録します。ランナー上のパッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースへの通信を監視します。エビデンスはCIキャッシュと一緒に引き継がれ、各SBOMにはジョブごと・キャッシュごとにComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかで完全性が示されます。

ビルドがアクセスできる範囲を制限する

堅牢化された入力が役立つのは、ビルドが実際にそれを使う場合だけです。CRACIのエグレスポリシーはデフォルト拒否またはデフォルト許可で、24種類の組み込みソフトウェアソースプリセットと、OCIレジストリやGitを含むレジストリ向けの型付きカスタムソースを備えています。ポリシーはジョブ開始前に検証され、フェイルクローズで動作します。Chainguardのレジストリと自社の成果物リポジトリだけを許可し、それ以外をほとんど許可しないポリシーを設定すれば、「Chainguardを使っている」が単なる取り決めから、ランナーが強制するルールに変わります。

出荷したものを監視し続ける

APIからSBOM、ネットワークトレース、来歴を取得できます。CRACIは監視対象のSBOMを新たな脆弱性について再評価し続けます。SBOMは脆弱性を含めてCycloneDXまたはSPDXでエクスポートできます。

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

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

組み合わせて使う

一般的な構成は次のとおりです。

• Chainguardがベースイメージを提供し、成果物リポジトリを通じて再ビルドされたライブラリを提供します。
• CRACIがそれらを使ってビルドするGitHub Actionsのジョブを、承認済みのソースを許可するエグレスポリシーのもとで実行し、各ジョブが取得したものを記録します。

OCIはCRACIが検出するエコシステムの1つであり、CRACIはnpmとPyPIのJFrog Artifactoryミラーにも対応しているため、その経路で届くイメージやPython、JavaScriptのパッケージもビルドの記録に含まれます。Java向けのChainguard LibrariesをカバーするMavenへの対応はロードマップに掲載されています。

どちらが適しているか

• スキャナーがベースイメージのCVEを指摘し続ける場合：Chainguardが、それらのイメージを堅牢化されたイメージに置き換えます。
• 各リリースに何が入ったかのエビデンスが必要な場合：CRACIがビルドから記録します。
• 承認済みのソースにしかアクセスできないビルドにしたい場合：CRACIのエグレスポリシーがランナーで強制します。
• クリーンな入力と記録されたビルドの両方が欲しい場合：上記のように両者を組み合わせます。

Cyber Resilience Actへの対応

既知の脆弱性が少なく、修正SLAが文書化され、署名付きSBOMを備えたコンポーネントから出発すれば、メーカーの脆弱性対応は容易になります。Chainguardはその点で役立ちます。CRACIは、企業がより広いCRAコンプライアンスのプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンス、つまり各リリースに何が入ったかと継続的な脆弱性トラッキングのかなりの部分を自動化します。どちらも、それだけで製品をコンプライアンスに適合させるものではありません。CRAとはとCRAコンプライアンスをご覧ください。

Chainguardの構成にCRACIを追加する

CRACI GitHub Appをインストールし、記録したいワークフローでruns-onをcraciに変更します。Dockerfileやパッケージの設定はそのままです。CRACIは現在GitHub Actionsに対応しており、GitLab CI、Jenkins、その他のCIシステムはロードマップに掲載されています。ビルド時のSBOM生成とCI/CD連携について詳しくご覧ください。