すべてのビルドから記録する、ソフトウェアサプライチェーンセキュリティ
ソフトウェアサプライチェーンと製品が交わるのは、CIビルドの中です。CRACIはGitHub Actionsのジョブをセキュアなランナーで実行し、取り込まれるすべての依存関係を記録し、各ビルドの接続先を制御し、出荷したものの脆弱性をトラッキングし続けます。
GitHub Actions向けセキュアランナー
runs-onをcraciに変更するだけで、GitHub ActionsのジョブがCRACIのランナーで実行され、実行結果はこれまでどおりGitHubに表示されます。各ジョブは、ヨーロッパでホストされるLinux x86-64またはARM64の専用の隔離された仮想マシンで実行されます。より高速なハードウェア、短い待ち時間、キャッシュにより、ビルドはGitHubホステッドランナーの約2倍の速さで完了します。
すべてのビルドから記録されるSBOM
CRACIはスキャナーではなく、記録ツールです。ランナー上のパッケージを認識するプロキシが、ジョブがnpm、PyPI、RubyGems、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソース、さらにYoctoとOpenEmbeddedのダウンロードプリセットから取り込むすべてのパッケージを、CIキャッシュから復元されたパッケージも含めて捕捉します。各ジョブのSBOMには完全性の状態が付き、推移的依存関係と各コンポーネントの宣言ライセンスを含めてCycloneDXまたはSPDXでエクスポートできます。
ビルドの接続先を制御
エグレスポリシーは、ジョブが接続できるホストを決めます。デフォルト拒否またはデフォルト許可、24種類の組み込みソフトウェアソースプリセット、パッケージレジストリとGit向けの型付きカスタムソース、明示的なネットワークルールを設定できます。ポリシーはジョブの開始前に検証され、フェイルクローズで動作し、違反があればアラートが発生します。侵害された依存関係やビルドステップが、承認していないホストへひそかにデータを送信することはできません。
出荷するものの来歴
公開REST APIは、ジョブごとにSBOM、ネットワークトレース、来歴を返します。いずれも同じビルドから記録されたものです。エビデンスはビルドそのものから得られ、ワークフローに追加のステップは必要ありません。
リリース後の脆弱性トラッキング
CRACIは、新たな脆弱性が公開されるたびに出荷済みのSBOMを再評価し、ビルドとリポジトリをまたいで検出結果を集約します。セキュリティチームは検出結果をトリアージし、修正を担当するチームに振り分けます。ポリシーゲートで検出結果やライセンスに応じてビルドをブロックでき、VEXにも対応し、ベンダーのSBOMも自社のビルドと並べて監視されます。インベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかが分かります。
顧客と監査人のためのエビデンス
顧客、監査人、規制は、リリースごとのSBOMと、脆弱性への対応記録を求めるようになっています。CRACIはSBOMを、コンポーネントで見つかった脆弱性を含めてCycloneDXまたはSPDXでエクスポートでき、公開REST APIはSBOM、ネットワークトレース、来歴を返します。同じエビデンスが、EU Cyber Resilience Act、NIS2、FDAのSBOM要件、ISO 27001のサプライチェーン管理策への対応を支えます。
サプライチェーンインシデントで問われること
パッケージ、CIアクション、レジストリが侵害されたとき、最初の数時間は自社が影響を受けているかの確認に費やされます。ここでは、チームが抱く問いと、CRACIのビルド記録がそれにどう答えるかを示します。
| 問い | CRACIの答え |
|---|---|
| 自社のビルドが、侵害されたバージョンのパッケージを取り込んでいないか？ | すべてのビルドのSBOMに、ジョブが実際に取得したパッケージが記載されているため、リポジトリを再スキャンする代わりに記録済みのビルドを検索できます。 |
| 影響を受けるのはどの製品とリリースですか？ | 監視対象のSBOMは継続的に再評価され、インベントリビューでソフトウェアバージョンとそのデプロイ先の製品を対応付けられます。 |
| ビルドステップがシークレットをどこかに送信した可能性はありますか？ | 各ジョブのネットワークトレースが行われた接続を記録し、エグレスポリシーはポリシー外のホストへの接続を到達前にブロックします。 |
| このSBOMは提出できるほど完全ですか？ | 各ジョブのSBOMは、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかで完全性を示します。 |
| 誰が修正していて、対応したことを証明できますか？ | 検出結果はトリアージされて担当チームに振り分けられ、SBOMはコンポーネントで見つかった脆弱性を含めてCycloneDXまたはSPDXでエクスポートできます。 |
CRACIが対象とするのは、ビルドとそれが出荷するものです。コードスキャン、シークレットスキャン、到達可能性分析は、引き続きアプリケーションセキュリティツールが担います。現在はGitHub Actionsに対応しており、その他のCIシステムはロードマップに掲載されています。
ソフトウェアサプライチェーンセキュリティのよくあるご質問
対象範囲、CI/CDで取り組むべき理由、CRACIの役割
ソフトウェアサプライチェーンセキュリティとは何ですか？
ソフトウェアサプライチェーンセキュリティは、最初のコミットからリリースまでの間にソフトウェアに入り込むすべてのもの、つまりオープンソースの依存関係、ベースイメージ、ビルドツール、サードパーティのCIアクション、CIパイプライン自体、出荷する成果物を守ることです。それらの構成要素が何かを把握し、どこから来るかを制御し、各リリースに何が含まれたかを証明することを意味します。
なぜCI/CDでソフトウェアサプライチェーンを守るのですか？
依存関係が解決され、ダウンロードされ、パッケージ化されるのはリリースビルドです。本番ビルドはノートPC上のビルドとは異なります。バージョン範囲、変更可能なタグ、キャッシュによって、異なるものが取り込まれる可能性があります。リリースビルドの実行中に取得した記録だけが、出荷内容の信頼できる記録です。そして、ビルドの接続先を制御できるのはビルドランナーです。
CRACIはサプライチェーンセキュリティのスキャナーとどう違いますか？
スキャナーは、マニフェスト、ロックファイル、ソースコード、完成したバイナリといったファイルを事後に読み取ります。CRACIはGitHub Actionsのジョブを実行するランナーであるため、ビルドをその場で観測し、各ジョブが実際に取り込んだパッケージを、CIキャッシュから復元されたパッケージも含めて記録します。各SBOMは自らの完全性を示し、エグレスポリシーがビルドの接続先を制御し、APIはSBOM、ネットワークトレース、来歴を返します。
CRACIはGitHub Actionsのワークフローを置き換えますか？
いいえ。CRACIが置き換えるのはランナーであり、GitHub Actionsではありません。runs-onをcraciに変更するだけで、ワークフロー、トリガー、実行履歴はGitHubに残ります。
CRACIはどのCIシステムとプラットフォームに対応していますか？
現在はGitHub Actionsに対応しています。GitLab CIやJenkinsを含むその他のCIシステムはロードマップに掲載されています。ランナーはx86-64とARM64のLinuxで、WindowsとmacOSはロードマップに掲載されています。
CRACIはSAST、シークレットスキャン、到達可能性分析を行いますか？
いいえ。CRACIはビルドを記録・制御し、出荷したものの脆弱性をトラッキングし、エビデンスを生成します。自社コードの欠陥やシークレットのスキャン、到達可能性分析は、アプリケーションセキュリティツールの役割です。
ビルドデータはどこに保存されますか？
CRACIはヨーロッパのベアメタルインフラ上でホストされており、データはデフォルトで180日間保持されます。Enterpriseでは保持期間をカスタマイズできます。CRACIはソースコードを保存しません。CRACIはISO 27001認証を取得しており、詳細はTrust Centerでご確認いただけます。