ソフトウェアサプライチェーンの防衛:すべてのエンジニアリングチームが今やるべきこと

ソフトウェアのサプライチェーンは継続的な攻撃を受けています。単一の脅威アクターや単一のインシデントによるものではなく、数か月にわたりエスカレートし、衰えの兆しを見せないエコシステム全体のキャンペーンによるものです。

今週、週に83百万回ダウンロードされ、約80%のクラウド環境に存在するHTTPクライアントライブラリAxiosが、乗っ取られたメンテナアカウントによって侵害されました。北朝鮮のラザラス・グループに高い信頼を得たプラットフォーム特有のRATを搭載した2つのバックドアバージョンが配備されていた。悪意のあるバージョンは約3時間稼働していました。それで十分だった。

これは、3月の TeamPCPキャンペーン に続くもので、Aqua SecurityのTrivy脆弱性スキャナー(数千の組織に信頼されているセキュリティツール)を武器化し、自己伝播ワームを介してCheckmarx KICS、LiteLLM、Telnyx、 141 npmパッケージに感染を拡大しました。それ以前には、 Shai-Huludワーム が 2025年末にnpmエコシステムを破壊し、 Glassworm は 400+ VS Code拡張機能、GitHubリポジトリ、npmパッケージに不可視なUnicodeペイロードを使って感染させました。

これらのインシデントすべてでパターンは一貫しています。攻撃者は開発者の認証情報を盗み、それを使って信頼できるパッケージを毒し、侵害されたパッケージはさらに認証情報を盗みます。それは自己強化的であり、加速しており、今やランサムウェアの収益化パイプラインも背後に存在しています。

共通の糸は暗黙の信頼です

これらの妥協で実際に何が失敗したのかを見ると、答えは毎回同じです。信頼が 検証されるべきところで前提とされたのです。組織はコンテナタグを信頼していました。なぜなら、馴染みのある名前だからです。彼らはバージョン番号があるからGitHub Actionを信頼していました。ワークフローはチームの誰かが作成したため、CI/CDの秘密を信頼していました。いずれの場合も、攻撃者は仮定された信頼と検証された信頼の間のギャップを利用しました。

これらのインシデントを最小限の被害で乗り越えた組織は、すでに暗黙の信頼を明示的な検証に置き換え始めていました。コミュニティプルの代わりに検証されたベースイメージ、可変タグの代わりに固定された参照、長寿命トークンの代わりにスコープ付きかつ短命な認証情報、そしてオープンなCIランナーの代わりにサンドボックス化された実行環境を導入しました。これらは新しいアイデアではなく、実装も難しいものではありません。彼らが求めるのは、デフォルトの姿勢を変えることです。つまり「理由がない限り信頼する」から「信頼する前に検証し、検証が失敗した場合は爆発範囲を制限する」ということです。

ここでは、すべてのエンジニアリング組織が推奨すべきこと、そして私たち自身がDockerで実践していることを紹介します。

基礎をしっかり守りましょう

まずは信頼できるベースイメージから始めましょう

検証できないアーティファクトの上に構築しないでください。Docker Hardened Images (DHI)は、DockerによってSLSAビルドレベル 3 証明、署名されたSBOM、VEXメタデータを用いてソースから再構築され、Apache 2の下で無料かつオープンソースで提供されています。0。DHIはTeamPCPの影響を受けませんでした。なぜなら、TeamPCPの管理されたビルドパイプラインと内蔵されたクールダウン期間により、短時間のサプライチェーンの脆弱性(通常 1 〜 6 時間)がイメージに現れる前に排除されるからです。今日でも使わない理由はありません。Docker Hardened Images(Node.js用)PythonやRustにはSocket Firewallも含まれており、インストール時に悪意のある依存関係をブロックし、CanisterWormやAxiosの侵害のようなサプライチェーン攻撃を npm install や pip install 実行前に傍受します。

すべてをダイジェストでピン留めするか、SHAにコミットしてください

可変タグはセキュリティの境界線ではありません。まさにこれがTeamPCPがトリビアクションバージョンタグ 75 乗っ取った 76 方法です。GitHub Actionsを完全な 40文字コミットSHAにピン留めてください。sha256 digestによるコンテナ画像をピン。パッケージ依存関係を正確なバージョンにピンし、^および~の範囲を削除します。参照が名前を変えずに上書きできるなら、それは上書きされます。あなたが管理しているGitHubアクションについては、 Immutable Releasesを有効にしてください。これにより、公開後にリリースタグをロックし、署名済みのアテスメントを生成します。これにより、TeamPCPがtrivy-actionを乗っ取ったタグ書き換え攻撃を防ぎます。組織内で使用されているすべてのサードパーティGitHubアクションをインベントリ化し、カタログ化していないものはピン留めできないため、許可リストポリシーを厳格に適用してください。組織内のすべてのパッケージレジストリアカウント(npm、PyPI、RubyGems、Docker Hubなど)で二要素認証を有効にしてください。単一のメンテナによるアカウント乗っ取りがほとんどの攻撃の始まり方です。ロックファイルをコミットし、すべてのCIパイプラインでnpm ci(またはパッケージマネージャー内の同等のもの)を使いましょう。これにより、ロックファイルに含まれていない新しいバージョンをビルドが無音で引き寄せるのを防ぎます。

依存関係の更新にはクールダウン期間を使いましょう

npmもRenovateも、新バージョンの導入を遅らせる最低リリース年齢設定をサポートしています。ほとんどのサプライチェーン攻撃は数時間の有効期限があり、 3日のクールダウンでほとんどの攻撃が排除されます。一般的なパッケージマネージャーやツールのための安全なデフォルト設定のコレクションを維持しています。使ってください。それに貢献しましょう。

ビルド時にSBOMを生成します

インシデントが発生したとき、最初の疑問は常に「私たちは影響を受けているのか?」です。docker buildxを使って画像を作成すれば、ビルド中にSBOMや出所証明を生成・付与できます。署名してください。画像と一緒に保存しましょう。次のAxiosやTrivyが動くときは、ライブのKubernetesポッドに実行して何が動いているかを調べるのではなく、ビルドのメタデータをチェックします。Docker Scoutは、既知の脆弱性やポリシー違反に対してこれらのSBOMを継続的に監視できます。

CI/CDを安全に保ちましょう

すべてのCIランナーを潜在的な突破点として扱いましょう

TeamPCPの認証情報盗用装置はCI/CDパイプライン内で動作し、プロセスメモリをダンプし、 50+ファイルシステムパスから秘密をスイープしていました。ワークフローステップにアクセス可能なものは、そのステップで依存関係を侵害する攻撃者にもアクセス可能です。GitHub Actionsでpull_request_targeトリガーは絶対に必要な場合を除き避け、明示的なセキュリティチェックも行ってください。これはTeamPCPが秘密にアクセスできるベースリポジトリの文脈でコードを実行するために使っていたまさにこの仕組みです。各ワークフローステップが到達できる秘密情報を監査しましょう。スキャンステップがあなたのデプロイメント認証情報にアクセスできるなら、それはスキャンの問題ではなくブラスト半径の問題です。

短命で範囲の狭い資格情報を使う

Trivyの漏洩の根本原因は、 33+ワークフロー全体で広範な範囲で使用される単一のパーソナルアクセストークンでした。短命で範囲の狭い資格を使いましょう。単一のトークンがクロスリポジトリや組織全体のアクセス権を与えるべきではありません。ワークフローファイルに散らばる環境変数ではなく、シークレットマネージャーを使いましょう。この分野は、Docker Hubを含むエコシステムが引き続き改善すべき分野であり、私たちは積極的に取り組んでいます。

内部ミラーやアーティファクトプロキシを使いましょう

建築システムと公開レジストリーの間にArtifactory、CodeArtifact、またはNexusを配置してください。パイプラインに届く前に、バージョンをスキャンして承認してください。Docker Businessの顧客は、Registry Access ManagementやImage Access Managementを使って、開発者が取得できるレジストリーやイメージを制限することもでき、完全なアーティファクトプロキシを実行しないチーム向けに軽量なポリシーレイヤーを提供します。

本番環境の秘密が存在しない依存関係の更新をテストします

本番環境の認証情報にアクセスできない開発・ステージング環境でのアップデートを評価する。悪意のあるパッケージがステージングで実行されても、価値あるものは何も盗まれません。

エンドポイントを安全にしましょう

ここからほとんどの攻撃が始まる。TeamPCP、Shai-Hulud、そして今のAxiosはいずれも、開発者マシンからドットファイル、環境変数、SSHキー、ブラウザセッション、クラウド設定に保存された認証情報をスイープするインフォスティーラーを展開しています。CI/CDパイプラインの保護は重要ですが、パイプラインを作成する開発者マシンが侵害された場合、攻撃者はその開発者が到達できるものを継承します。

カナリアトークンの展開

AWSキー、APIトークン、SSHキーなど偽の認証情報をフリート全体に配置し、それは盗み出された際に警告する以外に目的のないものです。インフォスティーラーがマシンをスイープすると、本物の認証情報が使われる前にカナリアトークンが発射されます。TracebitやCanarytokensのようなツールがあれば、これを簡単にできます。MDMソリューション(Jamf、Intune、Jumpcloud)があれば、すべての管理デバイスにカナリアをプッシュしてください。これを1日以内に艦隊全体に展開しました。

資格のクリーンアップ スプロール

監査 ~/.ssh/、 ~/.aws/credentials、 ~/.docker/config.json、.envファイルやハードコーディングされた秘密のシェル履歴などです。すべてパスワードマネージャーや秘密保管庫(1パスワード、HashiCorpの保管庫)に移してください。すべてのSSHキーをパスフレーズ保護。クリアテキスト認証情報のないマシンにたどり着いたインフォスティーラーは、何の役にも立たない。開発者ツール全体にインストールされている拡張機能やプラグイン(IDE拡張機能、ブラウザ拡張機能、スキル、プラグイン、MCPサーバーなどのコーディングエージェント拡張など)を監査してください。これらは開発者レベルの権限で動作する傾向があり、ほとんどのマーケットプレイスは初回公開後に更新を再審査しません。

行動検出付きのEDRを展開する

エンドポイントの検出および対応ツールは、既知のマルウェアシグネチャだけでなく、認証情報スウィーピング、永続化メカニズム、異常なプロセス挙動に対応するために検出されるべきです。

AI開発の安全を確保する

AIコーディングエージェントは、業界がようやく認識し始めた形でサプライチェーンリスクを増大させています。エージェントはパッケージをインストールし、設定を修正し、API呼び出しを行い、開発者レベルのアクセス権を持つコンテナを立ち上げます。エージェントによって引き寄せられた依存関係が侵害された場合、侵害された開発者マシンと同じ範囲を持ち、これらのエージェントを利用する人には、怪しい行動を認識できない非開発者も含まれるようになりました。

サンドボックス環境でエージェントを動かす

Docker Sandbox(sbx)は 、Claude Code、Gemini CLI、CodexなどのAIコーディングエージェントを分離されたmicroVM内で実行します。各サンドボックスはホストから完全に分離された独自のカーネル、ファイルシステム、Docker Engine、ネットワークを持っています。認証情報はホストプロキシによってHTTPヘッダーに注入され、VMに直接入ることはありません。ネットワークアクセスはデフォルトで拒否されており、明示的な許可リストがあります。侵害された依存関係がサンドボックス内で動作している場合、ホストのファイルシステム、Dockerデーモン、他のコンテナ、または明示的に承認していないドメインには届くことができません。

MCPサーバーを管理しましょう

モデルコンテキストプロトコルサーバーは、新たな未検証の依存関係です。彼らは広範な権限で動作し、AIエージェントを内部システムに接続し、分析されたMCPサーバーの43%にコマンドインジェクションの欠陥があります。MCPサーバーには署名済みのハード化イメージを使用してください。Dockerは 300+検証済みのMCPサーバーイメージを、DHIと同じSLSA/SBOM標準で管理しています。Dockerの MCPゲートウェイ は、すべてのエージェント間トラフィックに対して、中央集権的なプロキシ、ポリシー強制、シークレットブロッキング、監査ログを提供します。

ツール数を減らし、中央集権で管理する標準化

すべてのAIツールやモデルを動かしたくなる誘惑があります。やめて。信頼できるスタックに統合し、MDM経由で管理された構成をプッシュし、Docker Desktopの管理機能(レジストリアクセス管理、プロキシ設定、イメージアクセス管理)を使って、エージェントが何を取得でき、どこでプッシュできるかを制御しましょう。

インシデント対応のための筋肉をつける

本番環境のすべてのSBOMを維持しましょう

次の妥協案が出たら、「影響を受けますか?」と数分で答える必要があります。数日ではなく。docker buildxによるビルドタイムSBOMとDocker Scoutの継続的な監視を組み合わせることで、その機能が得られます。エクスポージャーを決めるためにコンテナを動かさなければならないなら、すでに遅れをとっています。

プレイブックを用意しておいてください

GitHubの組織を凍結する方法、CI/CDを一時停止しつつすべてを壊さずに行う方法、資格情報を一括取り消し、プレッシャーの中で行う前に顧客にコミュニケーションを取る方法を知っておくこと。インシデント対応のワークフローを把握する時間は、インシデント中ではありません。まだであれば、npm/PyPI/Docker、Hubアカウントの不正公開の確認、予期せぬネットワーク通話や秘密アクセスの最新CIログを確認し、過去 90 日間にCIがアクセスできた長寿命トークンをローテーションしてください。

信頼する前に確認し、重要な部分はゆっくりと進めましょう

ほとんどのサプライチェーン攻撃は数時間以内に燃え尽きてしまう。クールダウン期間、手動レビューゲート、あるいは単に 72 時間待つなどのわずかな遅延が、ほとんどのリスクを排除します。採用のスピードは妥協のコストに見合いません。

状況は変わったので、あなたのデフォルトも変わるべきです

サプライチェーン攻撃の波は単一のインシデントに対応するものではありません。これは脅威の状況における恒久的な変化です。攻撃者は、Lazarus Groupのような国家運営者から、離陸中に飛行機を組み立て、AIを使って加速し、ランサムウェアとの提携で収益化を図るTeamPCPやLAPSUS$のような機会主義的なティーンエイジャーまで多岐にわたります。彼らが利用しているエコシステム、すなわちnpm、PyPI、GitHub Actions、コンテナレジストリは、信頼モデル自体が根本的に変わっていません。

変わったのは、防御者がかつて暗黙の信頼しか選択肢でなかったものから、明示的な信頼境界を確立する手段を持つようになったことです。ハード化されたベースイメージ、ビルドタイムの証明、サンドボックス化された実行、カナリアベースの検出は、2年前のこの成熟度レベルでは存在しませんでした。これらの層を採用する組織とそうでない組織の間のギャップは急速に広がるでしょう。

ここで推奨したことはすべてDockerで実践しています。公開レジストリーから取得し、CI/CDパイプラインを運用し、AIエージェントも使用し、あなたと同じ脅威アクターに直面しています。これが私たちが自分たちを守る方法です。

参考文献:

• Docker Hardened Images:無料の署名済み、SLSA準拠のベースイメージ
• Docker Scout:SBOM生成、脆弱性検出、ポリシー強制
• Docker Sandboxes:AIコーディングエージェント向けの孤立したmicroVMs
• セーフデフォルト:パッケージマネージャーとツールのための安全な設定
• Docker BuildxでSBOMを構築する方法:ビルド時にprovenanceとSBOMを付ける