CRACI vs Syft・Grype

結論

Syftは広く使われているオープンソースのSBOMジェネレーターで、Grypeはそれと組み合わせて使う脆弱性スキャナーです。2つを合わせれば、任意のパイプラインで生成と照合を無料で行えます。CRACIはGitHub Actionsランナーで、各ビルドが取得したものを記録し、その記録が完全かどうかを示し、ビルドの接続先を制御し、出荷したものを監視し続けます。違いを一言で言えば、SyftはファイルからSBOMを再構成し、どれだけ見つかるかはその設定と実行時にディスク上にあるものに依存します。CRACIはSBOMを観測し、記録したものの脆弱性を追跡するため、1つの製品で両方の役割を果たします。

SyftとGrypeの強み

Syftは「コンテナイメージとファイルシステムからSoftware Bill of Materials（SBOM）を生成するためのCLIツールおよびGoライブラリ」です。Alpine、Debian、RPMからGo、Python、Java、JavaScript、Ruby、Rust、PHP、.NETまで、数十のパッケージングシステムを認識します。CycloneDX、SPDX、独自のSyft JSONを書き出し、フォーマット間で変換でき、in-toto仕様を使って署名付きのSBOM構成証明を作成できます。

Grypeは、コンテナイメージ、ファイルシステム、SBOMをスキャンして既知の脆弱性を検出します。EPSS、KEV、リスクスコアリングで検出結果に優先順位を付け、結果のフィルタリングにOpenVEXをサポートしています。--fail-onフラグを使うと、指定した重大度以上の脆弱性が見つかったときにパイプラインを失敗させます。Anchoreによれば、Grypeはデータベースのダウンロードを除き、「完全にローカルで動作し、外部サービスにデータを送信しません」。

どちらもApache-2.0で、Anchoreがスポンサーとなっています。同社の商用プラットフォームであるAnchore Enterpriseは「オープンソースのSyftとGrypeを基盤として構築」されています。このページで扱うのはオープンソースのツールです。

Syftは、適切なファイルが手元にあるときに力を発揮します。ollama/ollamaのように依存関係をコミットしているソースツリーを対象にすると、デフォルトのスキャンで依存関係をバージョン、パッケージURL、依存関係同士のエッジとともに解決します。

フラグ1つで答えが変わる

Syftはスキャンの種類に応じてカタロガーを選択し、その理由をドキュメントで説明しています。「ソフトウェアをインストールする意図を示すファイルには、正確なバージョンを特定するのに十分な情報が含まれていない」ためです。カタロガーにはdeclared、installed、image、directoryなどのタグが付いており、--select-catalogersや--override-default-catalogersといったフラグでその組み合わせが変わります。

v1.51.1のsyft cataloger listでは、node_modulesを読み取るJavaScriptカタロガーはイメージスキャンとインストール済みスキャン向けのタグが付いており、ディレクトリスキャンのデフォルトセットには含まれていません。そのため、インストール済みのチェックアウトでは、フラグ1つでnode_modules内のnpmパッケージがそもそも読み取られるかどうかが決まります。同じツール、同じバージョン、同じツリーでもです。

その裏返しも同じくらい重要です。どこでも正しい単一の設定は存在しません。

• ロックファイルのないexpress 5.2.1のクリーンなチェックアウトでは、デフォルトのスキャンには解決すべきnpmの依存関係がなく、GitHub Actionsやワークフローファイルなど、それ以外に認識できるものを返します。
• インストール済みのカタロガーを有効にして、まだ何もインストールされていないコミット時点のソースツリーを対象にすると、読み取るものがほとんどありません。
• 依存関係のマニフェストがまったくないリポジトリでは、設定にかかわらず、スキャンが読み取れる依存関係ファイルがありません。

これらはいずれもバグではありません。Syftは設計どおり、目の前にあるファイルが裏付ける内容を報告します。実務上の結果として、SBOMは、すべてのパイプラインで誰かが正しく判断しなければならない2つの決定に依存します。どのカタロガーを実行するか、そしてスキャンの前に依存関係がインストールされていたかどうかです。そして、Grypeが照合できるのはSyftが記載したものだけです。SBOMから漏れたコンポーネントは脆弱性の照合に届かないため、そのコンポーネントについてのスキャン結果は問題なしと判定されます。

CRACIの違い

CRACIは事後にツリーを読み取らないため、選択すべきカタロガーはありません。runs-onをcraciに変更すると、パッケージを認識するプロキシが、ジョブがnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットから取得するものを記録します。CIキャッシュから復元されたパッケージは、そのエビデンスを引き継ぎます。CycloneDXまたはSPDXで出力される結果には、ビルドが実際に使用した推移的依存関係が含まれます。

• 完全性が明示される。すべてのジョブとキャッシュが、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかとしてマークされます。
• ビルドが制御される。エグレスポリシー（デフォルト拒否または許可、24種類の組み込みソフトウェアソースプリセット）はジョブの開始前に検証され、フェイルクローズで動作します。
• 来歴データ。APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名しません。Syftの構成証明はSBOMに署名します。
• 監視。監視対象のSBOMは継続的に再評価され、検出結果はビルドとリポジトリをまたいで集約されます。

GrypeにはCRACIにできないこともあります。VEXによるフィルタリングと、自社でビルドしていないイメージのスキャンはGrypeの領域です。CRACIのポリシーゲートはビルドを失敗させることができますが、しきい値アラートはロードマップに掲載されています。

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

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

SyftとGrypeからの移行

CRACIでは、SBOMを生成する必要も、スキャンステップを保守する必要もありません。ランナーがビルドの実行中にSBOMを記録し、ビルドの完了後もCRACIが新たな脆弱性についてチェックし続けます。自社でビルドしていないイメージやサードパーティのソフトウェア、GitHub Actions以外のパイプラインには、引き続きSyftとGrypeをお使いいただけます。

Cyber Resilience Actへの対応

CRAは、メーカーに対して、SBOMを含め各製品のコンポーネントを文書化し、その脆弱性に対処することを求めています。SyftとGrypeはそのSBOMを作成・チェックできますが、各リリースからそのSBOMまでをたどるエビデンスの記録は自社で構築する必要があります。CRACIはビルドごとにSBOMを記録し、CycloneDXまたはSPDXでエクスポートします。企業がより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。CRAとはとビルド時SBOM生成をご覧ください。