axios npmパッケージ侵害を防ぐ対応策を徹底解説

何が起きたのか

2026年3月31日、npmで最も利用されるHTTPクライアントの一つである「axios」において、悪意あるパッケージ（マリシャスパッケージ）による深刻なサプライチェーン攻撃が発生しました。

詳しくは、前報のブログ記事「2026年3月31日にaxiosが受けたサプライチェーン攻撃の概要と予防策「クールダウン」機能について」をご確認ください。

今弊社が昨年公表した2025年セキュリティレポートでも言及しているとおり、マリシャスパッケージのほとんどは、Web開発に不可欠なnpm（Node.js）エコシステムを標的としています。

なぜこれほどnpmが狙われるのでしょうか。その理由は以下の3点に集約されます。

• 圧倒的な利用ユーザー数
  一度の侵害で、数百万件規模のプロジェクトに自動的に拡散・影響を及ぼすことが可能です。

• 複雑な依存関係
  axiosのような主要パッケージを侵害すれば、それを間接的に利用している膨大な「上流に位置するパッケージ」へ連鎖的に攻撃を広げられます。

• インストール時の自動実行機能
  パッケージをインストールするだけで、OSコマンドを自動実行できる仕組みがデフォルトで有効になっており、これが攻撃の入り口となります。

npmを利用する以上、悪意あるコードが紛れ込むリスクをゼロにすることは困難です。重要なのは、「もし紛れ込んだとしても、攻撃コードを実行させない仕組み」を構築することです。

この仕組みを構築することで、前回のブログ記事でご紹介した「クールダウン」中に緊急のパッチを当てざるを得ないシチュエーションに当たっても、リスクを低減しつつアップデートができます。

本章では、3つの対応策を紹介します。

対応策1：pnpmへ乗り換える

1つ目の対応策は、パッケージマネージャー自体を、よりセキュリティ設計が強固なpnpmへ乗り換えることです。

pnpmは、インストール時に実行される postinstall などのライフサイクルスクリプトの制御に優れています。npmでは、依存パッケージに含まれるスクリプトがデフォルトで自動実行されてしまいますが、pnpm（特に最新バージョン）では onlyBuiltDependencies 設定を用いることで、「信頼して実行を許可するパッケージ」を明示的に指定する許可リスト形式での運用が可能です。

これにより、未知のパッケージに仕込まれた悪意あるスクリプトによるサプライチェーン攻撃のリスクを最小限に抑えられます。

対応策2：ロックファイル等を用いて依存関係を固定する

2つ目の対応策は、ロックファイル等を用いて、安全と判断したバージョンを使い続けることです。

package-lock.json（npm）、yarn.lock（yarn）、pnpm-lock.yaml（pnpm）といったロックファイルをリポジトリで厳格に管理します。

開発環境やCI/CD環境では、通常の install ではなく npm ci 等のコマンドを使用することで、ロックファイルと完全に一致するバージョンのみをインストールし、バージョンの範囲指定（^や~）による意図しないマイナーアップデートを防ぎます。

また、ロックファイルにはパッケージの整合性ハッシュ（ Integrity Hash ）が含まれています。これにより、配布元でコードが改ざんされた場合、インストール時に検知することが可能です。

対応策3：npm設定（ignore-scripts）による実行遮断

3つ目の対応策は、ignore-scripts を設定し、パッケージインストール時にスクリプトが自動実行されるのをブロックすることです。

多くのマルウェアは、インストール直後の postinstall 等で情報窃取コードを起動するため、この実行ルートを遮断するだけで被害を抑えることができます。

プ

ロジェクトの事情ですぐにpnpmへ移行できない場合、この設定が必須となります。

.npmrc への記述例

プロジェクト単位でこの制限を強制するために、プロジェクトルートにある .npmrc ファイルに以下の1行を記述してください。

※注意：一部のビルドツールやネイティブコンパイルが必要なパッケージが動作しなくなる場合があります。その際は、信頼できる特定のパッケージに限定して個別にスクリプトを実行するなどの運用ルールを併せて策定してください。

すぐに自社システムでの利用状況を特定できる体制構築を

近年の傾向から、axiosのように、開発現場で「標準ツール」として広く浸透しているライブラリやツールを標的としたサプライチェーン攻撃は、今後さらに増加・巧妙化することが予測されます。

こういう状況の中で、エンジニアやセキュリティ担当者に求められるのは、「自社システムのどこで、そのパッケージが使われているか」を即時に特定することです。

パッケージマネージャーの設定による「物理的な実行遮断」は重要ですが、それだけでは「どの環境にリスクが残っているか」を網羅的に把握することはできません。突発的な脅威に対し、手動の調査に頼るのではなく、システム全体を横断して即座に利用状況を可視化できる体制を整えておくことが、企業を守る鍵となります。

サプライチェーンの脆弱性を可視化する 脆弱性管理クラウドyamoryのご紹介

株式会社アシュアードが提供する脆弱性管理クラウド「yamory」は、システム内に潜む脆弱性などのITリスクの検知から対応の優先度付けまでを自動で行う、国産のクラウドサービスです。

yamoryを使えば、重大な脆弱性が発生したときでも、「どのプロジェクトで、どのバージョンの該当パッケージが利用されているか」を即座に特定することが可能です。

幅広いレイヤーのITリスクを一元管理

クラウド・オンプレミス環境に問わず、インフラからアプリレイヤー内のITリスク（脆弱性・EOL・OSSライセンスリスク・クラウド設定不備）を一元管理することができます。

分かりやすいダッシュボードで結果を可視化

お使いのシステム環境に合わせて、検出したITリスクの対応優先度を自動で判別し、結果をダッシュボードに可視化。専門家でなくてもリスクの状況をひと目で把握することができます。

間接依存関係にあるライブラリの脆弱性も瞬時に発見

ライブラリの依存関係をツリー構造で可視化。間接依存関係にあるライブラリの脆弱性を瞬時に発見することができます。

axios がシステム内で使用されているかどうかも、yamoryで検出することが可能です。

政府認定のクラウドセキュリティ評価制度『ISMAP』に登録された唯一の脆弱性管理ツール

yamoryは、政府情報システムのためのセキュリティ評価制度『ISMAP』において、「唯一、SBOM・脆弱性管理ツールとして登録された国産クラウドサービス」です。

経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」においても、唯一の有償国産ツールとして紹介され、数多くの企業様に導入いただいております。

• 重大な脆弱性が発生したとき、すぐに自社システムで使われているかを確認したい
• ITリスクを一元管理できるサービスを探している

というご担当者様。この機会に、ISMAP登録済みのセキュアな基盤で、効率的かつ強固なITリスク管理をスタートしませんか？