💬

axiosサプライチェーン攻撃から考えるOSS依存のガバナンス――監査人はどこを見るべきか

に公開
Security
OSS
axios
Supply Chain
tech

はじめに

2026年3月31日、JavaScriptエコシステムで最も広く使われるHTTPクライアントライブラリのひとつであるaxiosが、サプライチェーン攻撃を受けました。週間1億ダウンロードを超えるこのライブラリへの攻撃は、単なるセキュリティインシデントにとどまりません。「広く使われているから安全」という思い込みがいかに危険かを改めて示す事例です。

本記事では、攻撃の概要を事実ベースで整理したうえで、IT監査・セキュリティ監査の観点から何を確認すべきかに焦点を当てます。

1. 何が起きたか

攻撃のタイムライン

日時 (UTC) 出来事
3月30日 05:57 plain-crypto-js@4.2.0（クリーン版）がnpmに公開される
3月30日 23:59 plain-crypto-js@4.2.1（ペイロード入り）が公開される
3月31日 00:21 axios@1.14.1 が侵害済みアカウントから公開される
3月31日 01:00 axios@0.30.4 が同アカウントから公開される

攻撃者は本番公開の18時間前から準備を進め、39分以内に2つのリリースブランチを汚染しました。

手口の概要

攻撃者はaxiosのメインメンテナーである jasonsaayman のGitHubおよびnpmアカウントを侵害しました。その後、アカウントに紐づくメールアドレスを匿名のProtonMailアドレスに変更し、通常のGitHub Actions CI/CDパイプラインを完全に迂回してnpm CLIから直接悪意あるパッケージを公開しました。

公開された axios@1.14.1 と axios@0.30.4 には、plain-crypto-js@4.2.1 という依存関係が注入されていました。このパッケージは：

  • 正規の crypto-js ライブラリを装い、説明文・作者名・リポジトリURLを偽装
  • axiosのソースコードでは一切インポートされていない（存在意義はpostinstallスクリプトの実行のみ）
  • macOS・Windows・Linux に対応したマルチプラットフォームRATをドロップ
  • 実行後に自身を削除し、package.json をクリーン版に置き換えて痕跡を消去
  • C2サーバー（sfrclak[.]com）に接続してセカンドステージペイロードを取得

推測と事実の分離
攻撃者の最終目的（認証情報窃取、永続的バックドア設置など）は執筆時点では確認情報がないため、断定は避けます。ただし、CI/CD環境に侵害が及んだ場合、シークレット・クラウドキー・SSHキーが危険にさらされ得ます。

同様の事例との接続

今回の手口は新しいものではありません。

  • 2025年9月: chalk と debug がメンテナーへのフィッシング攻撃で侵害
  • 2025年12月: Shai-Hulud 2.0ワームが感染npmパッケージのpostinstallスクリプト経由で約40万件の開発者シークレットを窃取

同じ攻撃パターンが繰り返されていることが重要です。

2. なぜ防げなかったか――構造的問題

メンテナー個人がSPOFになっている

axiosはOSSとして広大なコントリビューターコミュニティを持つ一方、npmへの公開権限はごく少数のメンテナーに集中しています。メンテナーのアカウントが単一障害点（SPOF）となっており、一人のアカウント侵害がエコシステム全体の脅威に直結します。

CI/CDパイプラインの署名検証が機能しなかった

通常、axiosはGitHub Actionsを通じてリリースされます。しかし攻撃者はnpm CLIを直接利用することで、このプロセスを迂回しました。npm registryに公開されたパッケージが「正規のCI/CDから生成されたものか」を検証する仕組みが存在しなければ、こうした迂回は防ぎようがありません。

postinstallスクリプトへの過信

npmのpostinstallスクリプトは npm install 実行時に自動で走ります。この仕組みは開発上の利便性を提供する一方、攻撃者にとって任意コード実行の入口にもなります。多くの開発チームはこのリスクを十分に評価せずにいます。

3. 監査観点：どこを見るべきか

ここからが本稿の本題です。今回のインシデントをふまえ、IT監査・セキュリティ監査の文脈で確認すべきコントロールを整理します。

3-1. SBOMの整備状況

確認ポイント：

  • アプリケーションが依存するOSSライブラリの一覧（直接依存・推移的依存の両方）が管理されているか
  • package-lock.json や yarn.lock でバージョンが固定されているか
  • SBOMが定期的に更新され、変更差分が追跡可能か

監査証跡として見るもの： ロックファイルのコミット履歴、SBOMの更新記録

3-2. 依存関係の脆弱性管理プロセス

確認ポイント：

  • npm audit や Dependabot、socket.dev などのツールが定期実行されているか
  • 検出された脆弱性の対応フロー（受け入れ・修正・例外処理）が定義されているか
  • 高リスク脆弱性に対するSLA（対応期限）が設定されているか

監査証跡として見るもの： CIログ内のaudit実行記録、脆弱性チケットの対応履歴

3-3. npm Provenance・公開経路の検証

確認ポイント：

  • パッケージの公開がCI/CDパイプライン経由に限定されているか（手動CLIによる公開が制限されているか）
  • npm Provenanceが有効化されており、trustedPublisher フィールドで公開元を検証できるか
  • npmの公開トークンが適切に管理されているか（MFAの強制、最小権限）
  • パイプラインのログが改ざんされていないか、監査ログとして保管されているか

監査証跡として見るもの： npm publish のアクセスログ、CI/CDの実行ログ、MFA設定の記録

3-4. postinstallスクリプトの制御

確認ポイント：

  • CI/CD環境で npm install --ignore-scripts が標準化されているか
  • postinstallスクリプトを持つパッケージが把握・承認されているか

監査証跡として見るもの： CI設定ファイル（.github/workflows など）内のインストールコマンド

3-5. インシデント対応計画（IRP）におけるOSSリスクの扱い

確認ポイント：

  • サプライチェーン攻撃を想定したシナリオがIRPに含まれているか
  • 影響を受けたバージョンの特定・切り戻し・認証情報ローテーションの手順が整備されているか
  • CI/CDパイプラインが影響を受けた場合のシークレット漏洩対応が定義されているか

4. 開発組織への提言

今すぐできること

今回の影響を受けたバージョン（axios@1.14.1 / axios@0.30.4）をインストールしていた場合：

  1. axios@1.14.0 または axios@0.30.3 へダウングレード
  2. node_modules/plain-crypto-js ディレクトリを削除
  3. npm install --ignore-scripts で再インストール
  4. 当該システム上のすべての認証情報をローテーション（npmトークン・クラウドキー・SSHキー・CI/CDシークレット）
  5. C2ドメイン sfrclak[.]com への通信ログを確認・遮断

中期的に取り組むこと

  • --ignore-scripts のCI/CD標準化：postinstallスクリプトの自動実行を原則禁止し、esbuild や husky など正規のpostinstallが必要なパッケージは npm rebuild <package> で個別に対応します。CI/CDの設定例：
    - name: Install dependencies
  run: npm ci --ignore-scripts
  • socket.dev や Snyk の導入：依存関係の追加・変更時にリアルタイムでリスクスコアを評価します
  • OSSメンテナーの属人化リスク評価：採用するライブラリの「メンテナー構成の分散度」をリスク指標のひとつとして取り込みます
  • npm Provenanceの確認習慣化：GitHub Actions等のCI/CDから公開されたパッケージには trustedPublisher フィールドが付与されます。依存パッケージの公開元を確認する手順を標準化します

おわりに

axiosは「広く使われているから安全」の象徴でした。週間1億ダウンロード、あらゆるNode.jsプロジェクトに入っている——そのライブラリが突破されました。

監査人として問うべきは「なぜaxiosが狙われたか」ではなく、「自分が監査する組織は、これを検知できたか」です。

今回のインシデントで検知の糸口になり得たものは複数ありました。trustedPublisher フィールドの欠落、GitHubリポジトリに存在しないタグ、postinstallスクリプトによる外部通信——いずれも事後的には明確な異常です。しかし多くの組織では、これらを可視化するコントロールが存在しません。公開直後の段階では npm audit はクリーンを返し、CIは正常終了し、誰も気づきません。

SBOMの整備、CI/CDのProvenance確認、postinstallの制御——本記事で挙げたコントロールは、いずれも「導入コストが低く、効果が説明しやすい」ものを選んでいます。経営層や開発チームへの説明材料としても活用してください。

axiosが突破されたなら、次は別の何かが突破されます。問題はそのときに組織が気づけるか、そして監査がそれを問える状態になっているかです。

参考

Discussion