比較
CRACI vs 自作SBOMスタック
サプライチェーンセキュリティスタックのどの層にも、優れたオープンソースツールがあります。手間がかかるのは、ツールを選び、つなぎ合わせ、動かし続け、スキャン結果とビルドの記録との間にあるギャップを埋める作業です。
更新日
要点
SyftまたはTrivy、Grype、Dependency-Track、Cosign、Renovateで構築する自作スタックは、ライセンスが無料で、どこでも動作し、有能なプラットフォームチームに完全な制御を与えます。CRACIはマネージド型のGitHub Actionsランナーで、各ビルドが取得したものを記録し、接続先を制御し、出荷したものを監視し、エビデンスをエクスポートします。違いは機能よりも、SBOMがどこから生まれるのか、そしてツール間のつなぎ目を誰が保守するのかにあります。GitLab、Jenkins、Windowsでビルドしている場合や、すべてを自社のインフラで動かす必要がある場合、現時点で率直におすすめするのは自作です。
スタックの全体像
完全な自作構成には、通常7つの層があります。それぞれが独自の保守を伴う本格的なプロジェクトです。
- 生成。Syft(「コンテナイメージとファイルシステムからソフトウェア部品表(SBOM)を生成」)、Trivy、cdxgen(「ソースとコンテナイメージから」CycloneDX BOMを作成するOWASPプロジェクト)、またはMicrosoft SBOM Toolです。Microsoft SBOM ToolはSPDXを出力し、コマンドラインでビルドのドロップフォルダー、パッケージ名、バージョン、サプライヤーを指定する必要があります。
- 照合。Grypeはイメージ、ファイルシステム、SBOMをスキャンし、EPSS、KEV、リスクスコアリングを提供します。OSV-Scannerはロックファイル、SBOM、コンテナイメージをOSV.devと照合します。
- 管理。OWASP Dependency-TrackはCycloneDXのSBOMを取り込み、長期にわたって監視します。APIサーバーには最低2 GBのRAMと2 CPUコア(推奨は8 GBと4コア)が必要で、ドキュメントでは本番環境向けに、別のデータベースを用いたDocker Composeでのデプロイを案内しています。
- 署名。Cosignはイメージ、BLOB、SBOMのアテステーションに署名し、Fulcioによるキーレス署名とRekor透明性ログに対応しています。GitHubのアーティファクトアテステーションはSigstoreを基盤とし、SLSA v1.0 Build Level 2の来歴を提供します。
- アップデート。RenovateまたはDependabotが、依存関係を最新に保つためのプルリクエストを作成します。
- エグレス制御。StepSecurity Harden-Runnerは、GitHub Actionsのジョブからの外向き接続を監査またはブロックできます。CommunityプランはGitHubホステッドランナー上のパブリックリポジトリでは無料ですが、プライベートリポジトリとセルフホストランナーにはEnterpriseプランが必要です。代替手段は、セルフホストランナーの周囲に自前のプロキシとファイアウォールルールを設けることです。
- レポート。上記すべての出力を、監査人、顧客、CRAの技術文書が必要とするドキュメントにまとめる担当者が必要です。
| 機能 | CRACI | 自作スタック |
|---|---|---|
| ビルドを実行 | ジョブはCRACIランナーで実行 | ツールはCIのステップとして実行 |
| ビルドから記録したSBOM | キャッシュされたパッケージを含め、観測した取得 | 事後にファイルから再構成 |
| SBOMの完全性 | ジョブごと・キャッシュごとに明示 | 生成ツール、その設定、事前にインストールしたかどうかに依存 |
| ランナーでのエグレスポリシー | デフォルト拒否または許可、フェイルクローズ | Harden-Runnerまたは自前のプロキシ |
| 署名付きの来歴 | 署名付きの来歴なし | CosignまたはGitHubのアーティファクトアテステーション |
| 出荷済みSBOMの監視 | 監視対象のSBOMを継続的に再評価 | Dependency-Track(自社でホストする場合) |
| ポートフォリオのポリシー、VEX、トリアージ | トリアージ、VEX、ライセンスポリシー | Dependency-TrackのポリシーとVEX |
| CRAのエビデンスとレポート | CycloneDXまたはSPDXのSBOM、APIによる記録、CRA通知の内容の準備に対応。レポートのエクスポートはなし | 各ツールの出力からレポートを自分で作成 |
| 他のCIシステム、Windows、macOS | 現在はGitHub Actions上のLinux。他のCI、Windows、macOSはロードマップに掲載 | 生成ツールとスキャナーはどのCIでも動作 |
| 自社インフラ上での実行 | 現在はマネージド型。顧客ホスト型ランナーはロードマップに掲載(Enterprise) | 自社でホストするオープンソースツール |
| コスト | 1 vCPU分あたり$0.002(2 vCPUで$0.004)、秒単位で計測。月額料金なし、SBOMごとの課金なし | ライセンスは無料。エンジニアの工数、ホスティング、保守のコストがかかる。 |
- 対応
- 一部対応
- 非対応
- ロードマップに掲載
コストはつなぎ目にある
生成ツールを選ぶことは、その死角を選ぶこと
複数のSBOM生成ツールを同じリポジトリに対して実行しても、含まれるものについての結果は一致しません。各ツールが読み取るファイルの組み合わせも、その解決方法も異なるため、得られるコンポーネント一覧はプロジェクトの性質であると同時に、選んだツールの性質でもあります。NTIAのサプライヤーフィールドは、同じことを逆の側から示しています。ほとんどの生成ツールにはその情報源がないため、リポジトリの内容にかかわらず空欄になります。
これらのツールが壊れているわけではありません。それぞれが、何をコンポーネントとみなし、どのファイルを信頼するかについて、異なる、文書化された判断を下しています。しかし自作スタックは選んだツールの判断をそのまま引き継ぎ、パイプラインの残りの部分(照合、監視、レポート)の完全性は、最初のステップを上回ることはできません。
つなぎ込みは自分で
各ツールには独自のリリースサイクル、脆弱性データベース、出力形式、設定があります。誰かがバージョンを固定し、データベースを更新し、Dependency-Trackとそのデータベースにパッチを当て、署名用のIDをローテーションし、どのSBOMをどこに送るかを決め、あるステップの出力が知らないうちに減り始めたら気づかなければなりません。これは一度きりのセットアップではなく、継続的なプラットフォーム業務です。
ツールもまた依存関係
セキュリティツールはシークレットにアクセスできる状態でビルド内で実行されるため、脅威モデルに含める必要があります。2026年3月、Aqua Securityはアドバイザリを公開し、侵害された認証情報を使って悪意あるTrivyのリリースが公開され、trivy-actionのタグの大半が約12時間にわたり認証情報を盗むコードへ強制プッシュされた経緯を説明しました。Aquaはこれを公に記録しており、広く使われているプロジェクトならどこでも起こりえたことです。この事例は、ランナーでのエグレス制御が重要である理由を示しています。デフォルト拒否のポリシーは、侵害されたステップがデータを送信できる先を制限します。ただし、すべての経路を防げるわけではありません(アドバイザリには、被害者のGitHubアカウントにリポジトリを作成するフォールバックも記載されています)。
自作が適している場合
- CIがGitHub Actionsではない場合。CRACIは現在GitHub Actionsのみに対応しており、GitLab CIとJenkinsはロードマップに掲載されています。GitLab、Jenkins、CircleCIを使うチームは、上記のオープンソースツールをすべて実行できます。
- WindowsまたはmacOSでビルドしている場合。CRACIのランナーは現在Linux(x86-64とARM64)です。WindowsとmacOSはロードマップに掲載されています。
- すべてを自社のインフラで実行する必要がある場合。CRACIは現在、欧州のインフラ上でマネージドランナーを運用しており、顧客ホスト型ランナーはEnterprise向けにロードマップに掲載されています。
- 自ら運用したいプラットフォームチームがいる場合。スタックの保守が意図的な投資であり、すでにDependency-Trackをうまく運用しているなら、そのまま使い続けてください。
- 1つの質問票のためにSBOMが1つ必要なだけの場合。重要度が低く、たまにしか発生しない依頼であれば、生成ツールを手動で実行するだけで十分かもしれません。
CRACIが置き換えるものと、置き換えないもの
CRACIは、ビルドを起点に複数の層を1か所でカバーします。runs-onをcraciに変更するだけで、実行結果は引き続きGitHubのUIに表示されます。パッケージを認識するプロキシが、各ジョブがnpm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットから取得したものを記録し、依存関係のエビデンスはCIキャッシュと一緒に引き継がれます。すべてのジョブとキャッシュには完全性の状態が付与されます。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。
- 生成:記録したビルドから、推移的依存関係を含むCycloneDXとSPDXを生成。
- 監視:ビルドとリポジトリをまたいで検出結果を集約し、監視対象のSBOMを継続的に再評価。
- 来歴:APIからSBOM、ネットワークトレース、来歴を取得可能。CRACIは来歴に署名しません。
- エグレス:24の組み込みソフトウェアソースプリセットを備えたジョブ単位のポリシー。ジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信。
- エクスポート:脆弱性を含めたCycloneDXまたはSPDXのSBOM。レポートのエクスポートはなし。
すべてを置き換えるわけではありません。パッケージのブロックリストはロードマップに掲載されています。署名付きの来歴が必要な場合は、CosignまたはGitHubのアーティファクトアテステーションを使い続けてください。脆弱なものだけでなくすべての依存関係を最新に保つには、引き続きRenovateやDependabotが有効です。セキュリティチームがDependency-Trackで作業している場合は、CRACIのREST APIからCycloneDXのSBOMをダウンロードして取り込めます。
どこに何がデプロイされているかのインベントリ
CRACIのインベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかを、グローバルに正確に把握できます。新しい脆弱性が公開されたとき、リリースノートやスプレッドシートをつなぎ合わせなくても、影響を受けるバージョンを実行している製品がわかります。
Cyber Resilience Actへの対応
CRAはメーカーに対し、「ソフトウェア部品表の作成を含め、デジタル要素を持つ製品に含まれる脆弱性とコンポーネントを特定し、文書化する」ことを求めています(附属書I、第II部)。実際に悪用されている脆弱性の報告義務は2026年9月から適用され、最初の通知は24時間以内に行う必要があります。各リリースからそのSBOMまでのエビデンスの流れを誰かが担当する限り、自作スタックでも対応は可能です。CRACIは、企業がより広範なCRAコンプライアンスプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化し、CRAの通知の内容を作成します。提出はお客様が行います。どちらを選ぶにしても、何が実際に悪用されているかの判断は自社のチームに委ねられます。CRAコンプライアンスとビルド時SBOM生成をご覧ください。
記録したビルド1つで、現在のスタックと比較
デモをご予約いただければ、お客様のGitHub ActionsワークフローをCRACIで1つ実行し、そのSBOMを現在のツールが生成するSBOMと並べてお見せします。
デモを予約