1
普段どおり更新する
開発者は脆弱性修正や互換対応のつもりで npm update や lockfile 更新を行います。ここでは不審に見えません。
サプライチェーン攻撃の事案を実技で理解する
更新したライブラリが直接悪いのではなく、依存先のどこかに悪性コードが混入すると被害が起きます。ここでは 2026-03-31 時点で共有された axios 混入事案（`1.14.1` / `0.30.4`）を題材に、侵入経路と検知ポイントを図で確認します。
今回の事案は何だったのか
今回扱うのは、axios の一部公開版に不正コード混入が疑われた事案です。学習上は、[email protected] と 0.30.4 を「危険版が混ざったかもしれない更新」として扱います。重要なのは、axios 自体のAPIではなく、信頼していた更新経路が攻撃面になることです。
入口
いつもの依存更新として取り込まれる
対象
axios の特定バージョンを利用した環境
怖い点
アプリ本体ではなく依存チェーンで混入する
初動
固定・差し戻し・通信確認・CI秘密情報の確認
つまり「axios を書いた人が悪い」ではなく、更新・配布・依存解決のどこかが侵されると、利用者側が巻き込まれるというのが今回の本質です。
攻撃フロー（アニメーション）
今回の事案としては、依存更新に見える青い流れの中へ、赤い不正コードが紛れ込み、最終的に紫の外部送信へ繋がるイメージです。
正常な依存更新
混入コード
外部送信
今回の事案を4段階で見る
2
危険版が混じる
[email protected] や 0.30.4 のように、更新対象として見えた版へ不正コード混入が疑われると、利用者側の環境へそのまま入ります。
3
実行時に外へ出る
ビルド時・起動時・HTTP通信時に、環境変数、CIトークン、設定値などが外部へ送られる可能性があります。
4
気づくのは後になりやすい
最初は普通の依存更新に見えるため、lockfile差分や不自然な通信を見ていないと、侵害後まで発見が遅れます。
現場でどう判断するか
今回のような事案では、まず その版を使っているか、次に いつ更新されたか、最後に 更新後に外部通信やCI実行があったか を見ます。ここを時系列で追える運用がないと、影響範囲の切り分けができません。
監視で先に見るポイント
lockfile の急変、未知の postinstall、通常と異なる外部通信先、CI トークンアクセスを優先監視してください。単一対策ではなく、依存固定・差分レビュー・SBOM・実行時監視を重ねる構成が有効です。今回のようなケースでは、「ライブラリ名」より「更新経路」「実行タイミング」「送信先」を監視する方が実務的です。