npmサプライチェーン攻撃Shai-Huludの起点はフィッシング～TOTPの代わりにFIDOで対策を～【セキュア開発技術Blog】

Securityチーム オーナーの松田です。
2025年9月に起きたShai-Hulud攻撃とその対策について記事を書きました。皆様のご参考になれば幸いです。

今回の記事概要

2025年9月14日、npmを標的としたShai-Hulud攻撃が発生しました。これはサプライチェーンを狙った大規模な攻撃であり、500以上のパッケージが侵害されたと報告されています。その後、GitHubは9月22日に公式ブログにて対応策を公表し、npmレジストリのセキュリティ強化を進めています。
【出典: GitHub Security Blog「Our plan for a more secure npm supply chain」】

本記事では、その中でも特に注目すべき対策のひとつである以下の方針について考えてみたいと思います。
Deprecate time-based one-time password (TOTP) 2FA, migrating users to FIDO-based 2FA.
（時間ベースのワンタイムパスワード TOTP による2要素認証を廃止し、FIDOベースの2要素認証に移行します）

Shai-Hulud攻撃とは

2025年9月14日に発生した Shai-Hulud攻撃 は、npm レジストリを標的とした前例のないサプライチェーン攻撃です。特徴的なのは、自己増殖型のサプライチェーン攻撃として拡散した点です。従来のサプライチェーン攻撃では以下のようなステップで感染拡大することが一般的でした。

1. 攻撃者がマルウェア入りのパッケージを公開
2. 開発者や自動ビルドがそのパッケージを取り込むことで、プロジェクトが感染
3. 感染したシステム上で、外部への通信や機密情報の取得など不正な振る舞いが行われる

一方、Shai-Hulud は感染した環境で得られた権限を使って、さらに他の npm パッケージを乗っ取り、マルウェア版を再公開するという “拡散” 構造を持っています。侵害されたアカウントを起点に次々とパッケージへ横展開し、短期間で 500以上のパッケージ が影響を受けました【GitHub Blog】。

この攻撃では、広く利用されているパッケージも侵害され、依存関係を通じて多数の開発者やプロジェクトがリスクに晒されました。報告例として、開発ツールやユーティリティ系のパッケージが改ざんされており、インストール時に機密情報の窃取やさらなる拡散が試みられたことが確認されています【CISA】【Trend Micro】。

このように、Shai-Hulud攻撃は npm エコシステム全体に急速に広がり得る「供給網の連鎖的な侵害」を実際に示した重大なインシデントとなりました。

起点はフィッシング

Shai-Hulud攻撃の起点は、巧妙に仕組まれた 標的型フィッシング による、npm メンテナーアカウントの侵害でした。Trend Micro の調査によれば、攻撃者はまずこのフィッシングキャンペーンを通じて特定のメンテナーをだまし、認証情報を取得しています。【Trend Micro】

このことに驚きました。高度なワーム機構や自動拡散の仕掛けが使われていたとはいえ、その出発点が古典的な手段であるフィッシングであったという事実です。

GitHub が公表した対策～TOTPの代わりにFIDOベースの2要素認証へ

GitHub が公表した対策の中で特に注目されるのが、次の方針です。

TOTP

TOTP（Time-based One-Time Password）は、RFC 6238 に基づいて標準化された方式であり、スマートフォンにインストールした Authenticator アプリで30秒ごとに更新される6桁のコードを利用する仕組みです【RFC 6238】。
導入しやすく多くのサービスで普及していますが、一度コードを攻撃者に取得されてしまうと、その有効時間内であれば悪用可能です。実際、フィッシングによってTOTPコードが盗まれるケースは少なくありません。

FIDOベースの認証ーpasskey

これに対して、FIDOベースの認証、いわゆる passkey はフィッシング耐性を持つ点で大きな優位性があります。
passkey は公開鍵暗号をベースとした仕組みで、ユーザーが登録したドメインに対してのみ認証が成立します。そのため、攻撃者が見た目だけを似せた偽サイトを用意しても、異なるドメインでは認証が行えず、フィッシングによる情報窃取を防止できるのです。

TOTPからFIDOベースの2要素認証へ

Shai-Hulud攻撃の起点がフィッシングであったことを踏まえると、GitHub が「TOTPからFIDOへの移行」を打ち出したのは必然と言えます。

これまで利便性と実装容易性から広く使われてきたTOTPですが、今回の事件は「従来の標準的な多要素認証では守り切れない」ことを突きつけました。フィッシング耐性を備えたFIDOへの移行は、npm エコシステム全体のセキュリティを強化するうえで重要な転換点になるでしょう。

FIDOベースの認証、いわゆる passkeyを実装するためには私たちが開発するシステムでも、2要素認証を考える際には TOTP だけでなく、FIDOベースの認証 を選択肢に含めることが重要だと感じます。

実装方法は？

実際の実装方法は意外と難しくありません。たとえば AWS Cognito を使えば、ユーザープールにおいて WebAuthn（passkey）を有効化し、ブラウザやスマホの標準的な認証機能をそのまま利用できます。

このような仕組みを利用することで、より安全でユーザーにとってシームレスな認証体験を提供できます。
今後のシステム開発では、ぜひ検討すべき選択肢と言えるでしょう。

この記事が皆様のセキュアなシステム開発の一助になれば幸いです。

【参考サイト】
⦁ GitHub Security Blog「Our plan for a more secure npm supply chain」
https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/
⦁ CISA「Widespread Supply Chain Compromise Impacting npm Ecosystem」
https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
⦁ Trend Micro「What We Know About the NPM Supply Chain Attack」
https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html
⦁ RFC 6238
https://datatracker.ietf.org/doc/html/rfc6238