CRACIとSonatypeの比較

結論

Sonatypeが最も得意とするのはオープンソースのガバナンスです。許可するコンポーネントを決めるポリシー、問題のあるパッケージをリポジトリで止めるファイアウォール、そしてアプリケーションに最終的に何が含まれたかを示す分析を提供します。CRACIはGitHub Actions互換のCIランナーで、ビルドが取り込むすべての外部依存関係を記録し、その記録からSBOM、来歴、コンプライアンスのエビデンスを生成します。Sonatypeはスキャナーでありゲートキーパーです。CRACIは記録装置であり、そのポリシーゲートは検出結果に基づいてビルドをブロックすることもできます。両方が必要なチームの多くは、両者を並行して運用することになるでしょう。

Sonatypeの各製品

Sonatypeは複数の製品を販売しており、この比較では製品名が重要です。

• Sonatype Lifecycleは、ソフトウェアコンポジション解析（SCA）とポリシーの製品で、セルフホストまたはSaaSで動作します。
• Sonatype Repository Firewallは、ポリシーに違反するコンポーネントがリポジトリに入る前にブロックし、隔離します。Sonatype Nexus Repository向けに設計されています。Sonatype Firewall Proは、JFrog Artifactory、Cloudsmith、GitHub Packagesなど他のリポジトリマネージャーを、npm、Maven、PyPI、NuGetについてカバーします。
• Sonatype SBOM Managerは、VEXのワークフローを備え、SBOMをインポート、監視、共有します。

製品構成は変わりつつあります。Sonatypeの料金ページによれば、Lifecycleのすべての機能は現在Sonatype Guideに含まれ、新規顧客はSCAとガバナンスのためにGuideを購入し、GuideにはSBOM Managerのコンプライアンス機能も含まれています。

一覧で比較

Sonatypeの強み

大規模なポリシー管理。Lifecycleには18個のデフォルトポリシーと、セキュリティ、法務、アーキテクチャのルールをカバーする30以上のカスタマイズ可能な制約が用意されています。ライセンスポリシーは2,000以上のオープンソースライセンスに対応します。到達可能性、破壊的変更、アップグレードの可否のデータで検出結果に優先順位を付け、推奨アップグレードを含むGolden Pull Requestを作成できます。

ビルドが生成したものを確認。Lifecycleの連携機能はデフォルトでAdvanced Binary Fingerprintingを使います。これはビルド後にアプリケーションに含まれるすべてのものを、組み込まれた依存関係も含めて調べ、名前が変更されたり改変されたりしたコンポーネントも識別できます。それができない場合にのみ、ロックファイルとマニフェストに頼ります。すべてのスキャンレポートはCycloneDXまたはSPDXのSBOMとしてエクスポートできます。

問題のあるパッケージを入り口で阻止。Repository Firewallは、ダウンロードの時点でセキュリティ、ライセンス、品質の基準を適用し、疑わしいコンポーネントを隔離します。CRACIには現在これに相当する機能はなく、パッケージのブロックリストはロードマップに掲載されています。

あらゆるパイプラインに対応。SonatypeはJenkins、GitHub Actions、GitLab CI、Azure DevOps、Bambooと連携するほか、Maven、Gradle、その他のCIサーバー向けのCLIも備えています。CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。

CRACIの違い

出力を分析するのではなく、ビルドを記録する

バイナリフィンガープリンティングは、完成したアプリケーションの中に何があるかを教えてくれます。しかし、ビルドが途中でダウンロードしたもの、つまりコンパイラやツールチェーン、インストールスクリプト、ベースイメージ、curlで取得したリリースバイナリ、キャッシュから復元したパッケージはわかりません。CRACIはランナーそのものなので、それらが見えます。パッケージを認識するプロキシがジョブの実行中にパッケージソースへの通信を観測し、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースに加え、ソースまたはダウンロードのプリセットをカバーします。依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュされたパッケージも記録に残ります。

すべてのSBOMは、ジョブごと・キャッシュごとに自らの完全性を示します。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。記録に欠落があれば、それがわかります。

ビルドの接続先を制御する

Repository Firewallは、リポジトリを通過するものを管理します。CRACIのエグレスポリシーは、ビルドがそもそもどこに到達できるかを管理します。ポリシーはデフォルト拒否またはデフォルト許可で、24種類の組み込みソフトウェアソースのプリセットと、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソースを備えています。ジョブの開始前に検証され、フェイルクローズで動作します。両者を組み合わせれば、ビルドジョブが承認したソースからのみパッケージを取得し、そのソースが許可したパッケージだけを提供するようにできます。

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

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名しません。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを再評価し続けます。

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

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

両方を使うべき場合

• すでにNexus RepositoryとFirewallを運用している。それをゲートとして残してください。CRACIを加えれば、すべてのビルドに取得したものの記録が残り、エグレスポリシーによってビルドを承認済みのソースに限定できます。
• 法務チームがLifecycleのライセンスポリシーに頼っている。そのまま維持してください。CRACIはSBOMのエクスポートに宣言ライセンスのメタデータを含め、ライセンスポリシーも適用します。
• SBOM ManagerでSBOMを収集している。SBOM ManagerはCRACIがエクスポートするのと同じCycloneDXとSPDXをインポートできるため、ビルド時SBOMをすでに管理しているSBOMと並べて扱えます。
• パイプラインがJenkinsやAzure DevOps上にある。現時点ではSonatypeが適しています。CRACIを使うには、まずそれらのパイプラインをGitHub Actionsに移す必要があります。Jenkinsはロードマップに掲載されています。

Cyber Resilience Actへの対応

SonatypeはCRAのユーザーガイドとCRAチェックリストを公開しており、SBOM Managerを自社のCRA向け製品と位置付けています。そのガイドでは、SBOM内の既知の脆弱性について報告するためのVEXファイルの生成と、セキュリティアップデートを配布するアップデートサイトとしてのNexus Repositoryが紹介されています。

CRACIはビルドを起点にエビデンスの側面をカバーします。完全性が明示された各リリースのSBOM、来歴、継続的な脆弱性監視、そしてCycloneDXまたはSPDXでのSBOMエクスポートです。企業がより広いCRAコンプライアンスプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。どちらのツールも単独で製品をコンプライアンスに適合させるものではありません。CRAコンプライアンスとCRAとはをご覧ください。

SonatypeにCRACIを追加する

CRACIが置き換えるのはランナーであって、GitHub Actionsではありません。ワークフローのruns-onをcraciに変更しても、実行結果は引き続きGitHubのUIに表示されます。Sonatypeのステップもワークフローにそのまま残ります。まず1つのリリースパイプラインから始め、CRACIのSBOMをLifecycleのレポートと比較して、一方にしか見えていないものを確認してください。