Axios サプライチェーン攻撃生存ガイド：スタートアップ開発者が即座に構築すべき3段階の防御策

最近の Axios ライブラリ乗っ取り事件と Shai-Hulud ワームの拡散は衝撃的です。信頼していたメンテナのアカウントが侵害され、悪意のあるコードが私たちのコードベースに直接埋め込まれる可能性があることを証明したからです。セキュリティチームがいないスタートアップにとって、npm install 一回で AWS アクセスキーが盗まれる状況は災難です。しかし、システムレベルに安全網を敷いておけば、悪意のあるスクリプトが実行されてもデータが外部へ流出する経路を遮断できます。

システムレベルでデータ流出経路を閉鎖する

攻撃者がパッケージのインストール時に悪意のあるコードを実行したとしても、ネットワークレベルで許可していない外部送信を阻止すれば、認証情報の流出被害をゼロに抑えることができます。AWS セキュリティグループ（Security Group）はデフォルトですべてのアウトバウンドトラフィックを許可しています。これは攻撃者のサーバーにデータを送るための高速道路を敷いているのと同じです。

• セキュリティグループの最小権限設定: AWS コンソールで既存のアウトバウンドルールをすべて削除してください。サービス運用に不可欠な特定の DB ポートと、ホワイトリストに登録された外部 API ドメインの IP 帯域（443 ポート）のみを明示的に許可します。
• アウトバウンドプロキシの導入: Squid のようなオープンソースプロキシを設置し、開発マシンが外部と直接通信する通路を塞ぐ必要があります。Host ヘッダーや SNI 情報を照合し、registry.npmjs.org のように承認されたドメインのみを通過させます。
• 環境変数の隔離: .env ファイルはもう捨てましょう。AWS Secrets Manager を使い、アプリケーション実行時に SDK でメモリ上だけにシークレットを展開するレイヤーを作成してください。

これにより、Shai-Hulud 2.0 のようにファイルシステムを探索して .env を盗もうとするワームの攻撃を物理的に無力化できます。

依存関係の整合性検査およびバージョン固定の自動化

攻撃は、開発者の知らない間に依存関係ツリー内でバージョンが勝手に上がった時に発生します。npm install は流動的なバージョン範囲（^1.0.0）を解決する際、package-lock.json を修正してしまうリスクが高いです。パッケージマネージャーの整合性検証機能を厳格に使用する必要があります。

• 厳格なバージョン固定: .npmrc ファイルに save-exact=true と記述してください。すべてのパッケージがキャレット（^）なしの正確なバージョンでのみ保存されるよう強制します。
• コマンドの置き換え: ビルドおよびデプロイスクリプトで npm install を npm ci に変更してください。package-lock.json と少しでも異なればインストールを拒否し、ビルドを即座に中断させます。
• 下位依存関係の強制修正: Axios v1.14.1 のように感染したバージョンが問題になった場合、package.json の overrides フィールドに "axios": "1.14.0" を指定してください。すべての間接的な依存関係まで安全なバージョンに固定されます。

npm ci は既存の node_modules を削除して新規インストールするため、汚染されたファイルが残る隙を与えません。依存関係の計算をスキップするため、ビルド速度が向上するのもメリットです。

CI/CD パイプラインのセキュリティゲート構築

人間が一つひとつパッケージを検査することはできないため、パイプラインが自ら拒否権を行使するように設定する必要があります。npm audit は既知の CVE データベースのみを参照します。ゼロデイ攻撃や未知の悪意のある挙動を捉えるには限界があります。

• Socket.dev の統合: GitHub リポジトリに Socket CLI を連携させてください。パッケージがネットワークにアクセスしたり、シェルコマンドを実行したりするなどの危険信号 70 余りをリアルタイムで分析します。
• Harden-Runner の適用: StepSecurity の Harden-Runner を GitHub Actions に導入してください。eBPF ベースでビルド中に発生するすべてのアウトバウンドリクエストを監視し、承認されていないドメインへのアクセスを遮断します。
• カスタムリントポリシー: ESLint の no-restricted-imports ルールで Axios のような特定のライブラリの使用を制限し、内部的に検証済みの HTTP クライアントのみを使用するようにコードレベルで強制します。

Socket.dev のような行動ベースの分析を導入すれば、セキュリティ事故発生時の手動調査時間を毎週 2 時間以上節約できます。

ツール名	分析方式	導入効果
npm audit	CVE DB 照合	標準内蔵ツール、静的脆弱性分析
Socket.dev	行動ベース分析	未知の悪意のあるコードパターンの検知
Harden-Runner	eBPF ランタイム監視	ビルドサーバーの不審なネットワークリクエスト遮断

侵害事故の痕跡調査および復旧

攻撃の知らせを聞いた時には、すでに手遅れかもしれません。システムログとネットワーク活動記録を確認し、自身の環境が侵害されていないかチェックしてください。悪意のあるコードは通常、C2 サーバーと通信するためにまず DNS クエリを送信します。この記録が最も確実な手がかりです。

• DNS クエリログの分析: tcpdump で sfrclak.com や plaincryptojs 関連のキーワードを含むリクエストがあったか探してください。発見した場合は、そのデバイスを直ちに隔離してください。
• 異常プロセスの検知: ps -ef コマンドで親プロセスが npm である子プロセスのうち、bun や powershell が起動していないか確認します。
• 認証情報のローテーション: 侵害の可能性が少しでもあるなら、AWS アクセスキー、NPM トークン、DB パスワードをすべて変更してください。既存のセッションもすべて無効化する必要があります。

攻撃者は痕跡を消そうとしますが、node 以外の唐突なプロセスを作成したり、.github/workflows/ 以下に不審な YAML ファイルを植え付けて持続性を確保しようとしたりします。Git status で検知されない新規ファイルが作成されていないか入念に調査すべきです。ネットワークホワイトリスト、npm ci、ランタイム分析ツールという 3 段階の安全網を構造化すれば、セキュリティニュース一つで一日中不安になることは確実に減るはずです。