SLSA L3の“正当性”を逆手に取る自己増殖ワーム──Mini Shai‑Huludが示したサプライチェーンの新常態です

今日の深掘りポイント

• 正当なSLSA Build Level 3のプロヴァナンスが付与されたまま、攻撃者がパッケージを汚染できる現実が可視化された点が決定的です。真正性の証明は「どう作られたか」を示しても、「誰が支配していたか」までは保証しないのです。
• ワームは開発者端末とCIをまたいで認証情報を窃取し、npm/PyPI双方で自己増殖します。CI/CDそのものが“感染の拡声器”になる構図です。
• 依存関係の検証は「出荷元の身元＋ビルドの来歴＋発行者の行動異常」の三点張りが必要です。プロヴァナンス単独では防げません。
• 防御の肝はアイデンティティ・ファーストなビルドと公開フローです。短命トークン、OIDCによるワークロードID、二人承認、強制レビューなど、破られた前提に合わせてガードレールを重層化する必要があります。
• インシデント対応は“全面侵害前提”で。開発者・レジストリ・クラウドの資格情報を一斉ローテーションし、パッケージの公開履歴とCIログを広く遡及監査するのが第一歩です。

はじめに

TeamPCPによる自己増殖型のワーム「Mini Shai‑Hulud」は、npmおよびPyPIのサプライチェーンを狙い、開発者とクラウドの認証情報を盗み取って、正規パッケージを汚染しながら広がる攻撃キャンペーンです。TenableのFAQによれば、侵害は170以上のパッケージに及び、累積5億1,800万超のダウンロードが影響を受けたと報告されています。さらに一部パッケージにはSLSA Build Level 3の正当なプロヴァナンス証明が付与されていたことが確認され、従来の供給網防御の前提が揺らいでいます。攻撃を受けたシステムは全面侵害として扱うべきだと結論づけられています［出典: Tenable］です。

• 参考: Mini Shai-Hulud: FAQ (Tenable)

本稿では、単なる事実の羅列ではなく、CISOやSOC、Threat Intelの視点で「何が壊れ、何を立て直すべきか」を掘り下げます。なお、未公表部分については仮説である旨を明示します。

深掘り詳細

事実整理（確認済みのポイント）

• 対象エコシステムはnpmおよびPyPIで、開発者端末やCI環境から各種認証情報（レジストリ発行トークン、クラウドAPIキー、VCSトークンなど）を窃取するコンポーネントを含む自己増殖型のワームです［Tenable］です。
• 侵害は170超のパッケージに波及し、累積ダウンロードは5億1,800万以上に達したとされます［Tenable］です。
• 一部の悪性リリースにはSLSA Build Level 3のプロヴァナンスが正当に付随しており、ビルドの由来検証をすり抜けています［Tenable］です。
• 結果として、開発主体・組織だけでなく、それらに依存する広範な利用者にもリスクが継播し、影響評価と封じ込めの難易度が一段と増しています［Tenable］です。

インサイト：SLSA L3の限界は「真正性の粒度」にある

• 「正当なSLSA L3プロヴァナンスを持つ不正パッケージ」という事象は、SLSAが保証するのが主に「ビルドプロセスの完全性」や「由来の追跡可能性」であり、「正当な操作者（人・ワークロード）の健全性」までは包含しないことを示します。攻撃者が開発リポジトリやCIのパイプラインを支配できていれば、正規の手順で“悪”を製造できてしまうのです。
• 供給網の防御は「どう作られたか（プロセス）」「誰が作ったか（操作者）」「どこから配られたか（配布者）」の三層で成立します。今回、プロセスの証明は生きていた一方、操作者の真正性（長寿命トークンや流出クレデンシャルで乗っ取られていないか）という前提が崩された構図です。
• ワーム性は「横展開の摩擦を最小化」します。開発者端末から.envや設定ファイル、CI環境変数、クラウドCLIキャッシュなどに散在する資格情報を回収すれば、npm/PyPIの両方で公開・改竄が可能になります。つまり、複数エコシステムを跨ぐ“同時多発の供給網汚染”が低コストで成立します。
• 依存の審査は「来歴が正しいか」だけでなく、「発行者・ビルダーのアイデンティティに異常がないか（振る舞い・地理・時刻・頻度・機材などのベースライン）」を併置しないと防げません。プロヴァナンスは必要条件であって十分条件ではないのです。

仮説：攻撃者が取り得たパス（未確証）

• 発端は開発者端末のフィッシングや悪性依存の導入などで初期実行を得て、秘匿情報リポジトリ（.npmrc、.pypirc、Gitクレデンシャル、クラウドプロファイル、CIジョブの環境変数）を横断的に収集・送出し、正規の自動化パイプライン経由で汚染リリースを発行した可能性が高いと推測します。
• CI/CDを“配布ベクトル”として悪用するため、リポジトリのリリースタグ付与やワークフロー定義（YAML）に軽微な変更を行い、検知を遅らせる手口（ステルス更新・小刻みリリース）を組み合わせた可能性があります。
• 正当なプロヴァナンスは、攻撃者が“正規のビルダー環境”を使ってビルド・署名・公開した帰結であり、偽造というより「真正な手順の悪用」であると見るのが自然です。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説的なシナリオ整理です（テクニックIDの列挙は対応づけの目安で、実際の事象は公開情報に依存します）。

• シナリオ1：開発者端末からの侵入とレジストリ汚染

  • 初期アクセス: Supply Chain Compromise（T1195）、悪性依存の導入やフィッシング
  • 資格情報アクセス: Unsecured Credentials（T1552/サブ技法: 設定ファイル・履歴・鍵）、Credentials from Password Stores（T1555）
  • 横展開/悪用: Valid Accounts（T1078）でnpm/PyPI/VCSにログインし、悪性バージョンを発行
  • 防御回避: Masquerading（T1036）、Obfuscated/Compressed Files（T1027）
  • 送信: Exfiltration Over C2 Channel（T1041）、Web Protocols（T1071.001）

• シナリオ2：CI/CDを“拡声器”にする自己増殖

  • 初期アクセス: Compromise Software Dependencies and Development Tools（T1195.001）
  • 発行操作: Trustedパイプラインのジョブ実行を悪用して公開（Valid Accounts: T1078）
  • 発見・準備: File and Directory Discovery（T1083）、Software Discovery（T1518）
  • 維持: 攻撃者が長寿命トークンや署名鍵を保持（Valid Accounts: T1078）
  • 影響: 新旧利用者への汚染拡散、組織境界を超えた二次被害

• シナリオ3：クラウド・AI基盤への横展開

  • 資格情報アクセス: Steal Application Access Token（T1528）、クラウドCLIキャッシュ・OIDC連携の誤用
  • 横展開: Remote Services（T1021）でCIランナーやビルドホスト、ストレージにアクセス
  • 影響: ソースコード・モデル重み・APIキーの流出、後続のサプライチェーン・攻撃のための足場化

影響面の勘所は三つです。第一に汚染の広がりが指数関数的になり得ること、第二に“真正な来歴”が検知精度を下げること、第三にクラウド資産の転用（マイニング、スパム、さらなる供給網汚染）がコストを外部化することです。監視と封じ込めは、依存関係グラフ、発行者アイデンティティ、ネットワーク挙動の三系統で並行に行う必要があります。

セキュリティ担当者のアクション

タイムクリティカルな順に、編集部からの実務提案です。

• 72時間アクション（封じ込め）

  • 依存の凍結と棚卸し：ビルド環境でのnpm/pipの自動更新を一時停止し、ロックファイル/要件定義から依存一覧を確定します。影響パッケージの使用状況を可視化し、隔離用のミラー/キャッシュを用意します。
  • トークン一斉ローテーション：npm/PyPIの発行・自動化用トークン、VCS PAT/デプロイトークン、CIのシークレット、クラウドアクセスキーを優先度順に無効化・再発行します。長寿命・広権限のものから先に切り替えます。
  • 監査の同時多発化：レジストリ公開履歴（いつ・誰が・どこから）、CI実行ログ（実行者・トリガ・イメージDigest）、VCS監査ログ（トークン利用元IP/UA、保護ブランチ例外）を横断照合し、異常な地理・時刻・頻度を狙い撃ちで抽出します。
  • EDR/ネットワークハント：開発者端末・CIランナーの一時ディレクトリ、ホームディレクトリの資格情報パス（.npmrc, .pypirc, .aws/credentials 等）への異常アクセス、未知FQDNへのHTTP/HTTPS POST、curl/wgetやnode/python子プロセスの不自然連鎖を検知ルール化します。

• 2週間アクション（再発防止の骨格）

  • アイデンティティ・ファーストな発行フロー：長寿命トークンを廃し、OIDC/短命トークンでのワークロードID連携へ移行します。人の発行操作にはハードウェアキー＋二人承認を義務化します。
  • パイプラインの最小権限化：公開ジョブ専用のロールを作り、必要最小のスコープのみに絞ります。秘密はランナーに永続保存しない設計にし、実行ホストはジョブごとに廃棄・再生成します。
  • 発行ガードレールの多層化：
    • プロヴァナンス検証を「特定のビルダーIDとDigestに限定」「コミットSHAとタグの一貫性検証」「依存のピン留めとSBOM差分検査」と組み合わせます。
    • 発行者行動のベースラインを構築し、リリース頻度・時刻帯・IP/ASN・国コードの逸脱でブロック/要承認にします。
  • 依存導入の隔離と遅延：新規バージョンの社内カナリア環境での隔離実行、ダウンストリームへの段階的展開、オフラインビルドの適用を標準化します。
  • 検知と欺瞞：開発・CI環境にハニートークン（ダミーのnpm/PyPI/クラウドキー）を配置し、外送検知をトリガに自動封じ込め（キー失効・ネットワーク隔離）を走らせます。

• ガバナンス（継続運用）

  • レジストリの組織管理を厳格化し、単独メンテナのクリティカルパッケージを撲滅します。移譲・乗っ取りに備え、緊急停止・ロールバック手順を定常訓練します。
  • サプライチェーンKPIの可視化：依存数、未ピン依存率、長寿命トークン比率、二人承認率、プロヴァナンス検証率、SBOM差分適用率などを定点観測し、経営と合意した閾値でSLO化します。
  • インシデント・テーブルトップ：今回の想定で、開発・SRE・法務・広報を交えた横断訓練を四半期ごとに行い、発表・回収・説明のレディネスを保ちます。

最後に強調したいのは、「プロヴァナンスは必要条件だが十分条件ではない」という一点です。私たちは、正当性の証明を“免罪符”ではなく、“検証可能性の素材”として扱うべきです。誰が、どこで、どうやって作ったのか──その三要素を統合的に点検できる組織だけが、自己増殖型のサプライチェーン攻撃に耐えられるのです。

参考情報

• Tenable: Mini Shai-Hulud: Frequently Asked Questions