【なぜ重要か】
npmの「Trusted Publishing」（OIDC連携による短命トークン発行）は、3年間のアドバイザリや啓発活動ではほとんど普及しなかったが、2025〜2026年にかけて発生した一連の大規模サプライチェーン攻撃によって週間採用数が最大10倍以上に急増した。日本のエンジニア・セキュリティ担当者にとって、自分たちが依存するnpmパッケージが攻撃対象となり得ること、そして「設定10分で対応可能な対策がまだ75%のパッケージで未実施」という現実は、今すぐ行動すべき理由として十分である。
【ポイント】
- Trusted Publishingとは何か： GitHubリポジトリに長期有効なNPM APIトークンを保管する代わりに、CI実行ごとにOIDC経由で数分で失効する短命トークンを発行する仕組み。トークンそのものが存在しないため、盗取・流出のリスクを排除できる。
- 攻撃の連鎖と採用数の急変： 2023〜2024年の週間採用数は平均約35〜40件だったが、2025年8月のS1ngularity攻撃（NxモノレポのGitHub Actions設定ミスを悪用）を皮切りに上昇。Debug/Chalk（フィッシングで週103件）、Shai-Hulud v1（自己複製ワームで700以上のパッケージ侵害、週109件）、Shai-Hulud 2.0（Pwn Requestによる週372件）と段階的に急増し、2026年5月には週430件という過去最高を記録した。18か月で累積採用数は3.4倍に拡大した。
- 攻撃手法の高度化： 初期はメンテナのフィッシングや長命トークン窃取が主流だったが、攻撃はCI/CDパイプライン自体を標的に進化した。Mini Shai-Hulud II（TanStack攻撃）では、Pwn RequestでGitHub Actionsキャッシュを汚染し、正規リリースワークフローが動いた際にOIDCトークンをランナーメモリから抽出。有効なSLSA Build Level 3プロブナンス証明書付きで悪意あるパッケージを公開するという手口で、「Trusted Publishingがバイパスされたのではなく、Trusted Publishingが攻撃ベクターとして利用された」。さらにMiasma攻撃ではトークン抽出すら不要で、OIDCパブリッシングエンドポイントを直接悪用した。
- 攻撃者の意図と構造的問題： Shai-Hulud攻撃者はエコシステムのインセンティブ構造を熟知していた——メンテナはパッケージ保護に対して報酬を得ておらず、侵害の被害はダウンストリームのユーザーに集中し、プラットフォーム側は最も痛みを感じない。これは典型的な集団行動の失敗であり、攻撃者は啓発ではなく「可視的な痛み」だけがエコシステムを動かせると判断して実行に移したと記事は分析している。その後、このワームのプレイブックはTeamPCPや北朝鮮系のSapphire Sleet（Axios攻撃：週1億DLのaxiosに2つのバックドア版を公開）など、メッセージ性を持たない犯罪者・国家支援アクターに転用された。
- 現状と残る課題： 2026年6月時点で上位51,370パッケージのうちTrusted Publishingを採用しているのは11,001件（約21%）のみで、ダウンロード量ベースのカバー率は25%にとどまる。攻撃がなければ採用率は落ち着き、次のコホートは再び長命トークンに戻るという「スパイクと減衰」のサイクルが繰り返されている。また、Trusted Publishingを採用してもCIパイプライン自体が堅牢化されていなければ、OIDCトークンをランナーメモリから抽出されるリスクが残る。
【まとめ】
「Trusted Publishingは無料で10分で設定できる対策」であるにもかかわらず、75%のパッケージがいまだ未対応である。セキュリティコミュニティのアドバイザリよりも実際の攻撃の方が普及を促進するという構造的問題が存在する中、記事はLet's Encryptがすべき行動として、未採用の高ダウンロード数パッケージに対してPRを送ったりIssueを立てたりする積極的な働きかけを呼びかけている。まず自分が管理・依存するnpmパッケージのGitHub ActionsワークフローでTrusted Publishingを有効化し、さらにpull_request_targetの設定ミスやOIDCスコープの最小化など、CIパイプライン全体の堅牢化も合わせて実施すること。