オープンソース パッケージや開発ツールは、現代のソフトウェア開発に欠かせない存在です。しかし、その「信頼された部品」が攻撃者に悪用された場合、影響は開発者端末やCI/CD環境を超え、企業のシステム全体へ波及する可能性があります。生成AIの活用によって開発が加速し、外部のライブラリやツールを取り込む機会も増えている中で、このような「信頼された部品」が攻撃者に悪用されるリスクを考慮したセキュリティ対策は今後さらに重要になってくると考えています。
今回は、Shai-Hulud、なかでも特にMini Shai-Huludと呼ばれるサプライチェーン攻撃を取り上げます。この手口がなぜ広範囲に影響を与えたのか、攻撃者にとってなぜ効率的なのか、そして企業やセキュリティ担当者は何を見直すべきなのかを整理します。
便利な依存関係が、攻撃の入口になる時代
企業のシステムは、多くのオープンソース ソフトウェア（OSS）、ライブラリ、開発ツール、クラウドサービスの上に成り立っています。開発者が日々利用する npm や PyPI などのパッケージ管理サービス、つまり外部ライブラリを取得・管理する仕組みや、GitHub のワークフロー、CI/CD の仕組みは、開発の効率化に欠かせないものです。
しかし、攻撃者の視点で見ると、この便利さは同時に大きな攻撃機会でもあります。個別の企業を一社ずつ侵害するよりも、多くの企業が依存するパッケージや開発基盤に不正コードを混入させる方が、効率よく影響を広げられるためです。
図1．企業への主な侵入経路とサプライチェーン経由の攻撃
Shai-Huludの厄介さは、単に不正なパッケージが配布されたことだけではありません。不正コードが開発者端末やビルド環境で実行されることで認証情報を収集し、その認証情報を使ってGitHub上のリポジトリやパッケージへ影響を広げる点にあります（図1）。
主な侵入経路は図の①公開サービスの脆弱性 ②不正メール ③認証情報の悪用ですが、今回のShai-Huludは④サプライチェーンの開発環境を狙っています。防御側には、メールやWebアクセスの入口だけでなく、開発環境そのものを守る視点が求められます。
Shai-Huludは何を狙ったのか
Shai-Huludは、npm経由で感染を拡大し、多くのパッケージで不正コードが埋め込まれたことで注目されました。端末上で不正コードが実行されると、認証情報が収集され、GitHub上に公開されたり、悪用されたりする動きが確認されています。
図2．TanStack関連パッケージの改ざんに関するSecurity Advisory（出典：GitHub Security Advisory）
この攻撃で重要なのは、攻撃者が「信頼されているもの」を利用している点です。開発者は、普段から利用しているパッケージやリポジトリを常に疑いながら作業しているわけではありません。攻撃者は、その信頼関係の中に入り込みます。
TanStackのように広く利用されるパッケージが改ざん対象となると、影響は一部の開発者にとどまりません。TanStackは、GitHub上で本件に関するSecurity Advisoryを公開しており、複数の @tanstack/* パッケージに不正なバージョンが公開されたことを説明しています。そのパッケージを利用する開発環境、ビルド環境、アプリケーション、さらにはソフトウェア供給網上の他の利用者へと影響が波及する可能性があります。
ここで防御側が見落としやすいのは、攻撃の入口が「怪しい添付ファイル」や「不審なメール」だけではないという点です。信頼されたパッケージ、正規の開発フロー、通常のビルド処理の中に不正な処理が紛れ込むため、従来の境界防御だけでは十分に把握できない領域が生まれます。
攻撃の流れ：開発者環境から信頼の連鎖をたどる
Shai-Huludの攻撃は、一般的なマルウェア感染とは異なる広がり方をします。多くの場合、不正コードが埋め込まれたパッケージが開発者端末やCI/CD環境で実行されます。そこでGitHubトークン、クラウド関連の認証情報、SSHキーなどが収集される可能性があります。
図3．Shai-Hulud型サプライチェーン攻撃の全体像
認証情報が盗まれると、攻撃者は正規の権限を使って操作できるようになります。たとえば、リポジトリの作成、コードの変更、パッケージの公開、ワークフローの変更といった操作が、正規ユーザーの権限を通じて行われる可能性があります。ログ上は正規の操作に見える場合もあり、単純な不正アクセス検知だけでは判断が難しくなります。
さらに、改ざんされたパッケージや、それを利用する正規アプリケーションを通じて、ソフトウェア供給網上の他の利用者へ影響が広がる可能性もあります。つまり、この問題は開発者だけの問題ではありません。開発環境の侵害を、企業のソフトウェア供給網全体に影響するリスクとして捉える必要があります。
なぜ検知・防御が難しいのか
この手口の厄介な点は、攻撃が日常的な開発作業の中に紛れ込むことです。開発者がパッケージをインストールする。CI/CDがビルドを実行する。GitHub上でワークフローが動く。いずれも通常の業務として行われる処理です。
その中に不正な処理が含まれていても、表面的には通常の操作と区別しにくい場合があります。特に、攻撃者が窃取した認証情報を使って操作した場合、「正規ユーザーの権限で異常な操作が行われた」形になる為、そのような観点の監視をしていない限り不正操作を検知することは困難です。
防御側としては、「誰がアクセスしたか」だけでなく、「その権限で何が行われたか」を見る必要があります。普段とは異なるリポジトリの作成、想定外のパッケージ公開、CI/CDワークフローの変更、クラウド認証情報の異常利用など、開発基盤における振る舞いの変化を監視する視点が重要です。
近年の侵入経路を見ても、公開サービスの脆弱性、不正メール、認証情報の悪用が主要な侵入経路であることに変わりはありません。しかし、Shai-Huludのようなサプライチェーン経由の攻撃は、企業が守るべき範囲をさらに広げています。守るべき対象は、社内ネットワークやメールだけではなく、開発環境、クラウド、ID、パッケージ管理、AIが利用する外部ツールにまで及んでいます。
AI時代にサプライチェーンリスクが拡大する理由
この事例で注目すべきは、攻撃の入口が開発環境やツールチェーンに広がっている点です。生成AIや開発支援ツールの利用が進む中では、開発者やシステムが何を参照し、どの依存関係を取り込んでいるのかを把握することが、より重要になります。
開発者がAIの提案をもとにライブラリを導入する。AIエージェントが外部ツールを呼び出す。開発環境が自動的に依存関係を取得する。
こうしたAI時代の開発の流れにより、広く利用される仕組みに不正コードを紛れ込ませる攻撃効果は、さらに大きくなります。
攻撃者はまさにこのような企業環境の変化を想定し、攻撃を成功させやすいポイントを狙っていると考えられます。企業はAIの利用そのものには注意を向け始めていますが、こうした流れが一般化すると、それらが利用する周辺ツールやパッケージ、開発ワークフローまで十分に管理できているとは限りません。つまり、AIを安全に使うには、AIモデルやプロンプトだけでなく、その背後にあるツールチェーン全体を見直す必要がある為、今後も類似のサプライチェーン攻撃が発生する可能性を前提に、防御体制を見直す必要があります。
防御側としては、AIの活用を避けるのではなく、安全に活用するための前提条件を整えることが重要です。開発者が利用するパッケージ、AIツールが参照する外部リソース、CI/CDが実行する処理、そこに紐づく認証情報を可視化し、異常な動きを早期に検知できる体制を整える必要があります。
Shai-Huludに関わる攻撃者グループTeamPCPの逮捕
2026年8月に、オーストラリア連邦警察は、FBIおよび西オーストラリア州警察との連携により、ハッカーグループTeamPCPのメンバーとされる2人の逮捕を発表しました。同一攻撃者による攻撃の可能性はなくなったと考えたいところではありますが、攻撃に悪用されたツールは公開されており、またAIの活用によって攻撃ツールの開発も加速している為、同様のサプライチェーンリスクに注意が必要である点は変わりません。特に、大きな攻撃の成功事例は、類似の攻撃を誘発する傾向にある為、さらなる脅威に備える必要があります。
企業が見直すべきポイント
このような攻撃に備えるには、開発部門、SOC、情報システム部門のいずれか一部門だけで完結する対策では不十分です。OSSパッケージの利用状況、依存関係、認証情報、CI/CD、クラウド、AI利用を横断的に見直す必要があります。
- OSSパッケージと依存関係の管理
まず、OSSパッケージの利用状況を把握し、依存関係のレビュー、ロックファイルの管理、SBOMの整備、パッケージ公開時に手動で取り込まない運用などを確認する必要があります。 - 認証情報の最小化と管理
次に、開発者端末やCI/CD環境に保存される認証情報を最小化することが重要です。トークンの権限を必要最小限にし、有効期限を設け、利用場所を制限する。長期間有効な認証情報をローカル環境に残さない。こうした基本的な対策が、サプライチェーン攻撃では大きな意味を持ちます。 - 開発環境とクラウドの監視
SOCやCSIRTの観点では、GitHubリポジトリの不審な作成、パッケージの想定外の公開、CI/CDワークフローの変更、クラウド認証情報の異常利用を監視対象に含める必要があります。メールやエンドポイントのアラートだけではなく、開発基盤やクラウド監査ログまで含めて相関的に見ることが、今後ますます重要になります。 - AI利用時のデータとツール連携の確認
AI時代の開発では、外部から何を取り込むかだけでなく、外部へどのようなデータが渡っているかにも注意が必要です。開発者が生成AIにソースコードやログを入力したり、AIツールが外部サービスと連携したりすることで、機密情報や認証情報が想定以上に多くの場所へ広がる可能性があります。 - ユーザー教育の対象拡大
ユーザー教育の観点でも、開発者向けの教育が欠かせません。一般従業員向けのフィッシング教育に加えて、開発者には「便利なパッケージをすぐに入れることのリスク」「AIが提案したライブラリを検証せずに採用するリスク」「認証情報をローカルに残すリスク」を伝える必要があります。
まとめ
Shai-Huludの事例は、サプライチェーン攻撃が一部の開発者だけの問題ではなく、企業全体のセキュリティ課題であることを示しています。
攻撃者は、企業の開発基盤、パッケージ、認証情報、AI時代のツール連携を悪用し、効率よく被害を広げられる場所を狙います。
防御側に求められるのは、攻撃が成立した構造を理解し、前述のような横断的な見直しを進めることです。
あわせて、侵入を完全に防ぐことは難しいという前提に立ち、侵害後に重要な情報を持ち出させない備えも欠かせません。
侵入を防ぐ対策と、データ流出を防ぐ対策の両方を整えることが、被害を最小限に抑える鍵となります。
プルーフポイントからのご案内
無料リスクアセスメント
開発環境への攻撃でも、発端がフィッシングメールによるアカウント乗っ取りであるケースは少なくありません。
自社にどのような脅威メールが届いているのかを可視化し、侵入リスクを確認します。
情報漏えいの実態を知る
侵害に備え、機密データの所在や、エンドポイント・クラウド・生成AIでの利用状況を把握することも重要です。
アカウント侵害の起きた組織の約半数で、侵害後に不審なデータアクティビティが確認されています。
生成AIや内部関係者を含む情報漏えいの全容を本レポートで解説しています。
→ 無料レポート: Data Security Landscapeのダウンロード
「侍」内田浩一にチャレンジコイン ― フィッシング対策への貢献を称えて
「侍ハッキング」を執筆するプルーフポイントの内田浩一が、 フィッシング対策協議会より「チャレンジコイン」を贈呈されました。
このコインは、フィッシング詐欺やサイバー犯罪対策に貢献した有識者などに、 感謝とコミュニティとのつながりを示す証として贈られるものです。
これからも内田ならではの視点で、「侍ハッキング」を通じて サイバー脅威の実態と対策に役立つ情報をお届けしていきます。
- ●関連リンク
- 内田浩一の侍ハッキング #1 フィッシング最新手法 - Basic認証と文字コードを悪用したHTMLの難読化
- 内田浩一の侍ハッキング #2 フィッシング最新手法 - 難読化したHTMLを添付してメールフィルタを回避する
- 内田浩一の侍ハッキング #3 CAPTCHAを悪用したマルウェアメール、SVGファイルを悪用したフィッシングメールを確認
- 内田浩一の侍ハッキング #4 巧妙化するリモートツール悪用型サイバー攻撃の脅威と対策
- 内田浩一の侍ハッキング #5 正規サイトが攻撃の入口に潜む不正コード — ErrTrafficとSocGholishに見る「信頼」の悪用
内田 浩一プリンシパル セキュリティ アドバイザー
ペネトレーションテストやマルウェア解析、スレットインテリジェンスを得意とするテクニカルコンサルタント。マカフィー(株)においては、プリンシパルコンサルタントとしてSOCの立ち上げや、マルウェア解析、インシデントレスポンス等の業務に従事し、制御システム、IoTデバイス等の新規分野に対するハッキングの調査研究も担当。アビラ(合)では、アジアにおける多くのセキュリティベンダーに対してアンチウィルスエンジンの提供とセキュリティ製品開発を支援し、エンドポイントからクラウドまで幅広い製品企画と開発支援の実績を有する。 現在、日本プルーフポイント(株)では、シニアセキュリティコンサルタントとしてメールを中心としたセキュリティ対策強化やインテリジェンスの活用を担当する。