2026年3月31日に発生した axios サプライチェーン攻撃 は、週間1億ダウンロードを超えるメジャーパッケージが標的となり、開発コミュニティに大きな衝撃を与えました。
この攻撃の恐ろしさは、自分が直接 axios を使っていなくとも、インストールしたパッケージの依存関係の奥深くに axios が含まれていれば、自動的に RAT（リモートアクセス型トロイの木馬） がインストールされてしまう点にあります。
本記事では、個人の開発環境を守るための「2行の設定」と、その具体的な検証・運用方法を解説します。
デザイナーサプライチェーン攻撃って、最近よく聞くけど具体的にどういうこと？
エンジニアソフトウェア開発の供給網、つまりnpmパッケージのような依存関係を狙った攻撃のことだよ。一つの脆弱な部品が全体を危険にさらすんだ。
デザイナーRATって何？リモートアクセス型トロイの木馬？
エンジニアそう。攻撃者が遠隔でPCを操作できるようになるマルウェアのこと。気づかずにインストールされるのが一番怖い点だね。
セキュリティ対策：.npmrc の2行設定
結論として、自身の環境の .npmrc（npmの設定ファイル）に以下の2行を追加することで、今回の axios 攻撃のようなサプライチェーン攻撃の多くを防ぐことが可能です。
# ~/.npmrc に設定する2行
ignore-scripts=true
min-release-age=3なぜこの2行で防げるのか
- ignore-scripts=true
axios の依存関係に追加された `plain-crypto-js` の postinstall スクリプト（マルウェアの実行トリガー）が動作しなくなります。 - min-release-age=3
今回の悪意あるバージョンは公開から約2.5〜3時間で検知・削除されました。公開から3日（設定値）以内のパッケージをインストール対象から外すことで、検知前の汚染バージョンを掴むリスクを回避できます。
デザイナーなるほど、スクリプトの実行を止めればマルウェアが動けないし、公開直後を避ければ検知されるまでの時間を稼げるってことね。
エンジニアその通り。シンプルだけど効果的な二重の防御だ。
対策①：postinstall スクリプトの無効化
仕組みと背景
npm には、パッケージのインストール時に任意のコードを自動実行する「ライフサイクルスクリプト（postinstall 等）」があります。これは正規の機能ですが、攻撃者にとっては「npm install させるだけでウイルスを実行させる」絶好の入り口となります。
今回の攻撃も、axios 本体のコードではなく、追加された依存パッケージの postinstall スクリプトのみで完結していました。
デザイナーpostinstallスクリプトって、便利だけど危ない諸刃の剣なのね。
エンジニア本来はパッケージに必要なビルド処理なんかで使うんだけど、悪用されるとあっという間に感染源になるんだ。
設定コマンドと確認
以下のコマンドで設定を有効化できます。
# 設定の有効化
npm config set ignore-scripts true
# 設定の確認（trueと返ればOK）
npm config get ignore-scriptsこの設定は、OSごとの以下のファイルに保存されます。
- Windows: `%USERPROFILE%\.npmrc`
- Mac/Linux: `~/.npmrc`
副作用への対処：個別の rebuild
`ignore-scripts=true` にすると、ビルドが必要な一部の正常なパッケージ（ネイティブモジュール等）も動かなくなります。その場合は、信頼できるパッケージに限定して手動で実行します。
# 依存関係をインストール
npm install
# 必要なパッケージのみ手動でビルド
npm rebuild [パッケージ名] --ignore-scripts=false※ `–foreground-scripts` オプションを付けると、実行内容をターミナルで確認できるためより安全です。
動作不全を見分けるエラー例
設定後にアプリが動かない場合、以下のようなエラーが出ていないか確認してください。
- `Error: Cannot find module ‘…’`（ビルド成果物が見つからない）
- `Error: Could not locate the bindings file`（ネイティブモジュール未コンパイル）
- `node-pre-gyp ERR!`（バイナリのダウンロード失敗）
デザイナー全部自動でやってくれるのがnpmの魅力だけど、セキュリティのためには手動で確認する手間も必要なのね。
エンジニアそうだね。信頼できるものだけ手動でビルドすることで、リスクを最小限に抑えられる。
対策②：公開直後のパッケージを除外する（min-release-age）
設定コマンド
公開から3日未満のバージョンをインストール対象から除外します。
npm config set min-release-age 3注意：npm バージョンの確認
`min-release-age` は npm v11.10.0（2026年2月） で導入された新機能です。古いバージョンでは動作しません。
# バージョン確認
npm --version
# v11.10.0 未満の場合は更新
npm install -g npm@latest最新のnpmじゃないとこの機能は使えないのね。これも定期的なメンテナンスが必要だわ。
エンジニアその通り。ツール自体も常に最新の状態に保つ意識が重要だね。
設定が効いているかテストする
実際にスクリプトがブロックされるか検証する手順です。
- テスト用プロジェクトの作成
mkdir test-ignore-scripts && cd test-ignore-scripts npm init -y - package.json にテスト用スクリプトを追加
"scripts": { "postinstall": "echo 'postinstallが実行されました！'" } - 実行テスト
- `npm install –ignore-scripts=false` → メッセージが表示される。
- `npm install –ignore-scripts=true` → 何も表示されない（成功）。
デザイナー実際に試して効果を確認するのは大切ね。これで安心して開発できるわ！
エンジニアうん。どんな設定も、ブラックボックスにせず自分の目で確かめるのが基本だ。
補足：その他の追加対策
package.json のキャレット（^）を外す
デフォルトでは "axios": "^1.7.0" のようにキャレットが付き、マイナー更新が自動で入ります。これを固定するには以下の設定を行います。
npm config set save-exact true※ 既にインストール済みのパッケージには適用されないため、手動で書き換える必要があります。
ツールの自動更新をオフにする
開発ツール（例：Claude Code等）自体が最新ビルドを自動追従する設定になっている場合、安定版（stableチャネル）を選択することで、公開直後のリスクを低減できます。
デザイナーパッケージのバージョン固定や、ツールの自動更新オフも、リスクを減らすためには有効なのね。
エンジニアそう。セキュリティは多層防御が基本だから、小さな対策も積み重ねていくことが重要だ。
まとめ：防御層を重ねる重要性
今回紹介した対策は、あくまで「短時間で検知・削除される攻撃」に特化したものです。
- 長期潜伏型の攻撃
- 正規メンテナーによる意図的な破壊（Protestware等）
これらを完全に防ぐことは困難ですが、サプライチェーン攻撃の多くは公開数時間で勝負が決まります。
「スクリプトを実行させない」「公開直後のものを入れない」 という2層の防御を敷くだけで、現実的なリスクの大部分を遮断することが可能です。
