シャイ・フルード2の余波と、何が違った形でできたのか

Shai-Hulud 2.0 npm ワームは、AppSec チームが今後何年も事後検証で参照することになるインシデントの 1 つです。

何が起こったのか、誰が影響を受けたのか、そしてSSCSプラットフォームがどのように スクライブハブ 組織が爆発範囲を阻止、または少なくとも大幅に制限するのに役立つはずでした。

1. Shai-Hulud 2.0とは何ですか?

シャイ・フルードは2025年9月に初めて登場した。 npmエコシステムを標的とする自己複製ワーム数百の JavaScript パッケージを侵害し、盗まれた資格情報と自動再公開を介して拡散します。 

わずか2ヶ月後、研究者たちは はるかに積極的で自動化されたフォローアップ波、現在では一般的に 「シャイ・フルド 2.0」、「シャイ・フルド 2.0」または「再臨」。 

Shai-Hulud 2.0 の主な特徴:

• サプライチェーンに焦点を当てます。 一つの企業を攻撃するのではなく、 信頼できるnpmパッケージ さらに、後期の亜種では、Java エコシステム (Maven) にまで影響が及び、何千ものプロジェクトで使用されるビルディング ブロックが汚染されました。
• 自己増殖するワーム。 メンテナーに侵入すると、自動的にバックドアが仕掛けられる を そのメンテナーのパッケージを削除して再公開することで、依存関係グラフ全体に指数関数的に広がることができます。
• 秘密を盗むインフォスティーラー。 ペイロードは、開発者のマシンとビルド パイプラインから環境変数、GitHub および npm トークン、クラウド認証情報、CI/CD シークレットを積極的に収集します。 
• 破壊的な「デッドマンスイッチ」。 マルウェアが C2 に到達できなかったり、拡散に失敗したりした場合、一部の亜種はユーザーのホーム ディレクトリを消去しようとし、サプライ チェーンの侵害を潜在的に破壊的なインシデントに変えてしまいます。

2. 攻撃の仕組み – ステップバイステップ

ベンダーによってツールやスクリプトは若干異なりますが、全体的なキル チェーンはおおよそ次のようになります。

2.1 最初の足掛かり：侵害されたメンテナーアカウント

攻撃者：

1. 侵害された npm / GitHub メンテナー アカウント 以前に盗まれたトークンの使用、フィッシング、パスワードの再利用、または弱い MFA など。
2. これらのアカウントを使用して公開しました 正規パッケージのトロイの木馬化されたバージョン – 多くの場合、パッチレベルのバージョンアップのみで、通常の更新パターンに組み込まれます。

パッケージは正当なメンテナーによって署名/公開されているため、下流の消費者にとって信頼できるものに見えました。

2.2 npm install / CIパイプライン経由の感染

組織はこれらのパッケージをプルしました:

• 通常経由 npmインストール ローカル開発では、
• または間接的に CI / CDパイプライン 自動ビルドの一部として。

悪意のあるパッケージは通常、 npmライフサイクルスクリプト (プレインストール, install, インストール後）を実行ベクトルとしてダウンロードし、第2段階のペイロードを実行する。 バンドル.js, セットアップ_bun.js、または同様の大きな難読化ファイル。 

2.3 資格情報の盗難と環境の偵察

実行されると、ペイロードは次のようになります。

• 列挙された環境変数とローカル構成ファイル。
• 収穫した クラウド資格情報、GitHub/GitLab トークン、npm アクセス トークン、SSH キー、その他のシークレット。
• 時々使用するツール TruffleHogスタイルのスキャン リポジトリで秘密を検索します。

これらの資格情報はその後 攻撃者が管理するGitHubリポジトリに流出 またはその他の C2 インフラストラクチャ。多くの場合、周囲に溶け込むように名前が付けられます (例: 盗まれた環境ダンプが格納されている「Shai-Hulud」リポジトリ)。 

2.4 開発者エコシステム間の横方向の移動

マルウェアは盗んだトークンを使用して次のことを行います。

• すべてのnpmパッケージにバックドアを仕掛ける 侵害を受けたメンテナーが所有する、同じ悪意のあるスクリプトを挿入して再公開します。
• 植えた 悪意のあるGitHub Actionsワークフロー CI 実行中の永続化と継続的なデータ流出のために、被害者のリポジトリにバックドアを設置します。
• 2.0のいくつかのバリエーションでは、npmを超えて拡張され、 Mavenリポジトリ真のクロスエコシステムサプライチェーンの到達範囲を実証します。 

多くの人気ライブラリは依存関係ツリーの上位に位置するため、わずか数人のメンテナーの妥協は 影響を受けるリポジトリの数万 下流。

3. 規模と被害者への影響

セキュリティ ベンダーによって報告される数字は若干異なりますが、次の点についてはすべて一致しています。 Shai-Hulud 2.0は巨大です。

• セキュリティ研究者は、 25,000以上のGitHubリポジトリ および 数百～約700個のパッケージ 後の波で影響を受けたいくつかのものは、 クラウド/コード環境の4分の1以上 彼らはスキャンしました。
• アナリストはそれを これまでに見た中で最も急速に広がるnpmサプライチェーン攻撃の1つ自動化によって 数時間以内に数百個のパッケージをお届けします。
• 著名な被害者には、 Zapier、ENSドメイン、PostHog、Postman、 つまり、SaaS プロバイダーとその何千人もの顧客の両方が潜在的な危険にさらされていたことになります。

3.1 直接的な技術的影響

トロイの木馬化されたパッケージをプルした組織の場合、典型的な結果は次のようになります。

• CI/CD の秘密の漏洩 (クラウド プロバイダー キー、デプロイメント トークン、コード署名証明書など)。
• ステルス性の高いバックドア GitHub リポジトリと CI アクションで、攻撃者が将来のビルドで任意のコマンドを実行できるようになります。
• 改ざんされた遺物: 開発者が気付かないうちに、攻撃者が構築されたアプリケーションに悪意のあるロジックを挿入する可能性があります。
• 運の悪い開発者の中には、 破壊的な消去 $ HOME ディレクトリにジョブを開始します。 マルウェアのフォールバックが起動したとき。

3.2 ビジネスへの影響

ビジネスの観点から見ると、これは次のようになります。

• 大規模なインシデント対応イベント: IR チームは、影響を受けるパッケージを使用しているすべてのプロジェクトを監査し、トークンをローテーションし、場合によってはデプロイメントを凍結する必要がありました。
• 規制および契約上のリスク規制対象業界 (金融、医療、政府サプライヤー) では、規制対象データや重要なシステム アクセス キーがサードパーティ パッケージ経由で流出する可能性に直面しています。
• オープンソースにおける信頼の低下セキュリティおよびエンジニアリングのリーダーは、パブリック レジストリの信頼モデルを見直し、依存関係の管理に関するより厳格な制御を検討する必要があります。

4. 伝統的な防御が困難になる場所

Shai-Hulud 2.0 はなぜこれほど多くの防御を突破できたのでしょうか?

1. それは単なる脆弱性ではなく、信頼を悪用したものでした。 パッケージは「正当」であり、多くの場合は既存のリポジトリから、実際のメンテナー名で公開されていました。
2. 静的 SCA/SAST だけでは不十分でした。 たとえチームがSBOMと脆弱性スキャナを持っていたとしても、その多くは 行動的 疑わしいライフサイクル スクリプトやビルド中の外部への流出などの指標。
3. 本当のターゲットはシークレットと CI/CD でした。 多くの組織では、CI/CD 環境に対する制御と監視が本番環境よりも弱いため、絶好の標的となります。
4. エンドツーエンドの来歴の欠如。 ほとんどのチームは簡単に答えることができませんでした。 「トロイの木馬化されたパッケージが関係していたビルド、アーティファクト、デプロイメントは正確にはどれですか。また、クリーンなものはどれですか。」

これはまさに ソフトウェアサプライチェーンセキュリティ (SSCS) プラットフォームが好き スクライブハブ 対処するように設計されています。

 

5. ScribeHub SSCSがSh​​ai-Hulud型攻撃の防止と軽減にどのように役立つか

Shai-Hulud 2.0 のテクニックを、Scribe Security の ScribeHub プラットフォームと関連ツール (Valint policy-as-code など) を使用して通常実装する機能にマッピングします。

5.1 依存関係の取り込みに関するガードレール

Shai-Hulud 2.0 の問題:
組織は更新されたnpmパッケージを自動的に使用しました（ ^/~ バージョン範囲、Renovate/Dependabot、CI スクリプトなど) の動作をほとんど精査せずに実行します。

ScribeHub を使用すると:

• ポリシーに基づく依存関係の制御。 Valint ポリシーを使用して、「信頼できる」と見なされるレジストリとスコープを制限し、重要なパッケージの許可リストを適用し、次の場合にアラートを発します。
  • 新しいメンテナーがバージョンを公開し、
  • 予期しないライフサイクルスクリプトが表示される、
  • または、パッケージが突然新しいネットワーク/実行動作を獲得します。
• サードパーティ コンポーネントの証明。 ScribeHubは取り込みと検証が可能 起源と建造物の証明 利用可能なパッケージ（例：SLSAスタイルのメタデータ、Sigstore、in-toto）の場合、次のようなルールを有効にする。 「ビルドの由来が信頼できる依存関係のみを消費します。」

これはnpmエコシステムを魔法のように修正するものではないが、 基準を引き上げる 新しいバージョンがビルドに許可される前に。

5.2 CI/CDパイプラインを「第一級の資産」として強化する

シャイ・フルードの主な価値は、 開発者のラップトップと CI/CD ノードを秘密の金庫として使用します。

ScribeHub の使用:

• 実行ごとにパイプラインの証明。
  各 CI ジョブは、次の内容を説明する署名付き証明書を生成します。
  • どのリポジトリとブランチが構築されたか
  • どの依存関係とコンテナイメージが使用されたか
  • 実行されたスクリプト（ライフサイクルフックを含む）
  • どの秘密にアクセスされたか。
• そのデータは ScribeHubの証拠湖誰が何を、どこから、どのような入力で構築したかという、改ざん不可能な履歴を提供します。
• ポリシー・アズ・コードによるランタイム チェック。
  ビルド成果物をステージング/本番環境に昇格する前に、ポリシー エンジンは次のことを検証します。
  • 承認されたnpmレジストリのみが使用されていること
  • 禁止されたライフサイクルスクリプトがない（カール | バッシュ、難読化された バンドル.jsなど）が実行され、
  • ランナーがルートとして実行されておらず、機密性の高いホストパスをマウントしていなかったこと。

シャイ・フルードが追加注入すれば インストール後 秘密を盗み出すスクリプトは 政策に失敗する そして、生産には決して至りません。

5.3 爆発半径の迅速解析

このようなキャンペーンで最も難しい作業の 1 つは、次の質問に答えることです。

「トロイの木馬化されたパッケージ X は具体的にどこで使用され、何に影響されたのでしょうか?」

ScribeHub を使用すると:

• すべてのビルド、デプロイメント、アーティファクトは、 暗号的にリンクされた証明: 依存関係、環境の詳細、コミット SHA、コンテナ ダイジェストなど。
• 新しい勧告に「バージョン4.8.1～4.8.5の いくつかのライブラリ Shai-Hulud 2.0の一部である」とScribeHubに問い合わせます。
  
  
  「過去 90 日間にこれらのバージョンが含まれていたすべてのビルドと、それらが生成したデプロイメントまたはイメージを表示してください。」
  
• その後、缶 ターゲットシークレットローテーション すべてを盲目的にローテーションするのではなく (運用上非現実的な場合があります)、必要な部分を正確に修復します。

言い換えれば、ScribeHubはエコシステム全体のパニックを 境界が定められた監査可能なインシデント.

5.4 あなたの 自分の パッケージが武器化されるのを防ぐ

多くの組織はオープンソースを消費するだけでなく、 パブリッシュ 顧客、パートナー、または社内チームが使用するパッケージ。組織のメンテナーアカウントが侵害された場合、Shai-Huludのメンテナーと同様に、意図せずして感染経路となってしまう可能性があります。

ScribeHub は次のようなサポートを提供します:

• CI からの署名付き証明書の要求 パッケージをnpmまたは内部レジストリに公開する前に:
  • 必要な証明書が添付されていないパッケージ バージョンは拒否されるか、フラグが付けられます。
• 独自のレジストリとリポジトリの継続的な監視:
  • パッケージが不明なビルド環境から公開されたり、承認された CI パイプラインの外部から公開されたりした場合にアラートを出します。
  • 前回の「信頼できる」リリースには存在しなかった新しい GitHub Actions または npm スクリプトを検出します。

これはそれを作ります 盗まれたトークンを持つ攻撃者にとってははるかに困難 悪意のあるバージョンを静かに名前空間に紛れ込ませる。

5.5 規制当局、顧客、内部関係者への証拠

シャイ・フルード2.0のような事件は、特に以下のような枠組みに沿ったセクターにおいて、規制当局や大口顧客によってますます精査されるようになっている。 NIST SSDF, PCI DSS 4、または政府のソフトウェア認証要件。

ScribeHubは SDLC アクティビティのタイムスタンプ付き署名付き記録、次のことができます。

• トロイの木馬化された依存関係の影響を受けなかったビルドとリリースを示します。
• 監査人に以下の具体的な証拠を提供します。
  • 依存関係ポリシー、
  • CIにおける最小権限の強制
  • および事件後の秘密ローテーションのタイムライン。

これにより、会話は「私たちは大丈夫だと思います」から「これが私たちのソフトウェアの証明された保管チェーンです」へと変わります。

6. セキュリティリーダーのための実践的なポイント

すべてをまとめると、Shai-Hulud 2.0 と ScribeHub のようなプラットフォームが果たせる役割を次のように要約できます。

1. エコシステムが危険にさらされていると想定します。 パブリックレジストリは単一障害点として魅力的すぎるため、セキュリティモデルでは、外部依存関係は、信頼できないと証明されるまで信頼できないものとして扱う必要があります。
2. 「スキャンして祈る」から「証明して強制する」にアップグレードします。 従来の SCA と linting は依然として重要ですが、Shai-Hulud 2.0 では次のものも必要であることが示されています。
   • 強力な起源、
   • 証明されたビルド、
   • およびポリシーで保護されたアーティファクトのプロモーション。
3. CI/CD を本番環境のように扱います。 このワームが秘密やパイプラインを狙ったのは、それらが強化されたランタイム環境よりも脆弱なターゲットであることが多いためです。
4. トレーサビリティに投資しましょう。 次にエコシステム全体に及ぶ侵害が発生したとき（必ず発生します）、数週間ではなく数時間以内に「これはどこに影響したのか」に答えられるかどうかが、制御可能なインシデントに終わるか、本格的な危機に終わるかの違いを生むでしょう。

ScribeHub SSCS は npm やオープンソースを魔法のように安全にするものではありませんが、Shai-Hulud スタイルの攻撃に、はるかに少ない混乱で耐えるために必要な可視性、制御、証拠のバックボーンを提供します。

継続的な署名済み証明書、証拠に基づくポリシー、強力な CI/CD 衛生を中心として SDLC を設計すると、次に発生する「史上最大の npm サプライチェーン攻撃」は、ビジネスに対する実存的脅威ではなく、対処すべき別のインシデントになります。