2026年4月29日、また新たなサプライチェーン攻撃が世間を騒がせました。今回は、Mini Shai Huludと呼ばれるSAPへの攻撃でした。
サプライチェーン攻撃の詳細は、npmパッケージの公開プロセスなどに馴染みのない私にとって、容易に理解できるものではありません。それでも、自分自身やプロジェクトは守らなければならないもの。色々なブログでセキュリティ対策が紹介されていますが、攻撃内容を知ってこその対策だと思うのです。このブログでは、私がSafeDepのブログを読み、Claudeに助けを借りて、長時間格闘の末やっと理解したことをまとめています。どなたかのお役に立てれば嬉しいです。
起こったこと
- SAPのエンジニアのGitHubアカウントが盗まれる
- 改ざんされたCIワークフローが、盗まれたGitHubアカウントでupdate/releasesブランチにプッシュされる。
- 改ざん内容：
- update/releasesブランチにプッシュしてワークフローをトリガー
- npmへのパッケージ公開権限を得るために使うOIDCトークンをログに表示
- 改ざん内容：
- 改ざんされた4つのSAPパッケージが攻撃者のデバイスからnpmに直接公開。（内3つはログに表示されたOIDCトークン、1つは静的トークンを用いて公開された）
改ざんされたSAPのパッケージをインストールするとどうなるか
- クレデンシャル（GitHubトークン、npmトークン、AWSキー、Azure/GCPクレデンシャルなど）が盗まれる
- GitHubトークンを用いて、悪質なファイルが
.vscode/と.claude/に追加される - npmトークンを用いて、改ざんされたバージョンがリリースされる
- これがいわゆるワーム。被害者が次は加害者になりうる。
追加された悪質なファイルによって起こること
悪質なファイルは、1つのリポジトリにつき最大50のブランチにコミットされたそう。改ざんされたブランチにチェックアウトし、リポジトリをVS Codeで開く、もしくはClaude Codeのセッションを開始するだけでクレデンシャル等が盗まれる仕組み。サプライチェーン攻撃対策として効果的と思えるpreinstallスクリプトの制限をしていたとしても、またnpm installを実行しなくとも、被害に遭ってしまうということです。
なぜ起こったのか
- npmパッケージ公開の設定ミス ー CIにおいて、どのブランチ、どのワークフローを使えばnpmのOIDCトークンを発行できるかという制限がなく、攻撃者が容易にトークンを盗むことができた。
- 被害に遭ったリポジトリの内1つは、静的トークンのみでパッケージが公開できてしまう、セキュアでない方法を採っていた。
npm公開の設定
npm公開の設定ミスに対して警告するなど、npmレジストリは何か対策を講じられないものなのか…と憤りを感じます。そんな中、「段階的リリース」が可能になったようです。これまでnpm publishでそのまま公開されていたパッケージが、npm stage publishによって、管理者が公開前に二要素認証できるようになるとのこと。ただ、段階的リリースを採用するのかは管理者次第であり、また、今回のようにCI/CDを介さず直接npmに公開されることへの対策にはなりませんが…。更なる改善に期待します。
今回の攻撃の内容を一つひとつ見てみると、巧妙なテクニックに感心を覚えるほどでした。PRレビューの際にはそのブランチにチェックアウトする前に、怪しいファイルがコミットされていないかしっかりチェックするよう気をつけなければならないというのが、今回の大きな学びになりました。
もし内容に誤りがあれば、ご指摘いただけますと幸いです。
Reference: