サプライチェーン攻撃：攻撃者はどう侵入し、どう止めるか

製品そのものではなく、オープンソースパッケージ、CI/CDコンポーネント、ビルドシステムなど、製品を構成するコード、ツール、サービスを狙う攻撃です。1回の侵害が、影響を受けたコンポーネントを使うすべての組織に及びます。

Shai-Huludワーム（2025年以降）は、感染したnpmパッケージを通じて拡散し、CIのシークレットを盗みました。tj-actions/changed-filesの侵害（CVE-2025-30066）では、人気のGitHub Actionが乗っ取られました。xz utilsのバックドア（CVE-2024-3094）は、上流の圧縮ライブラリに仕込まれました。Log4Shell（CVE-2021-44228）は、広く使われているJavaのログ記録ライブラリの欠陥を悪用しました。CodecovのBash Uploader（2021年）はCIの認証情報を外部サーバーに送信するよう改変され、SolarWinds Orion（2020年）はビルドで挿入された悪意あるコードを含んだまま出荷されました。

SolarWindsです。2020年、SolarWinds Orionのビルドプロセスにひそかにアクセスした攻撃者がリリースに悪意あるコードを挿入し、顧客はそれを通常のアップデートとしてインストールしました。この事件は、クリーンなソースツリーだけでは不十分であり、ビルドそのものが信頼でき、検証可能でなければならないことを示しました。

通常は知りませんし、知る必要もありません。ほとんどの攻撃は企業ではなくパッケージを狙います。アドバイザリが公開されると、攻撃者は脆弱なバージョンを実行している可能性のあるあらゆるものにエクスプロイトを試し、何が応答するかを確認します。JavaScriptバンドルやオープンソースのリポジトリに含まれるバージョンなど、公開されている手がかりが狙いを定める助けになります。非対称なのは、防御側には一覧が必要だという点です。影響を受けるかどうかを知るには、ロックファイルの外で取得したものも含め、すべてのビルドが何を出荷したかを把握している必要があります。

1つの対策ですべてを防げるわけではありません。すべてのビルドが出荷するもののSBOMを保持して新しいアドバイザリに対して監視し、依存関係とGitHub Actionsを固定し、脆弱なバージョンをビルドでブロックし、CIジョブの接続先を制限し、ジョブを分離してシークレットを制限し、デプロイした成果物が自社でビルドしたものであることを検証してください。

ロックファイルをコミットしてCIではそこからインストールし、ビルドに不要な場合はインストールスクリプトを無効にしてください（npmの--ignore-scripts）。各ビルドが実際にインストールしたパッケージのバージョンを記録しておけば、Shai-Huludのような新たな攻撃の波が発表されたときにすばやく確認できます。CIジョブの接続先を制限して、悪意あるインストールスクリプトがトークンを外部に送信できないようにし、感染したバージョンが到達できた可能性のあるトークンはすべてローテーションしてください。

セキュリティ演習では、レッドチームが攻撃者を演じ、ブルーチームが防御します。このページも同じ構成で、サプライチェーン攻撃の各段階を攻撃者の言葉で示し、それに防御側が応えます。

既知のものは検出します。xzのバックドアのように公開されたCVEがある悪意あるリリースは、他の脆弱性と同様にフラグが立てられ、ポリシーゲートでそれを含むビルドをブロックできます。CRACIはパッケージの挙動を解析したり評判をスコアリングしたりしないため、まったく新しい悪意あるパッケージは、アドバイザリが出るまでフラグが立ちません。そのためにあるのがエグレスポリシーです。デフォルト拒否であれば、ビルドは必要なホストにしか到達できないため、誰も見たことのない攻撃でも、パッケージがシークレットを外部に送信することはできません。