DEV Community

Cover image for API開発者のためのNPM依存関係を保護する完全なサプライチェーンセキュリティガイド
Akira
Akira

Posted on • Originally published at apidog.com

API開発者のためのNPM依存関係を保護する完全なサプライチェーンセキュリティガイド

要するに

NPMサプライチェーン攻撃は2024年だけで3,000以上の悪意のあるパッケージが検出され、2026年3月のAxios侵害は、トップ10パッケージでさえ安全ではないことを示しました。API開発者が実装すべき多層防御(ロックファイル強制、postinstallスクリプトのブロック、プロベナンス検証、行動分析ツール活用、アーキテクチャ選択による攻撃対象領域の縮小)について、具体的な方法と手順を解説します。

Apidogを今すぐ試す

はじめに

2026年3月31日に発生したAxiosサプライチェーン攻撃は、npm侵害としては初めてではありませんし、これが最後でもありません。週8,300万回ダウンロードされるパッケージが、乗っ取られた単一のメンテナーアカウント経由でクロスプラットフォームのRAT(リモートアクセスツール)を展開した今回の事件は、JavaScriptエコシステムの重大なリスクを明確に示しました。

Axios攻撃は従来の「依存関係を更新してください」というアドバイスを無効化し、悪意のあるコードがAxios自体ではなく、偽の依存関係を介したpostinstallフックで注入された点が特徴です。攻撃期間中にnpm installを実行した場合、ロックファイルやバージョン固定だけでは防げませんでした。

API開発者は特に標的にされやすく、テストスクリプトやCI/CDパイプライン、モックサーバー、HTTPクライアントのどれか1つでも侵害されると、APIキーや認証情報が漏洩するリスクがあります。

💡 Apidogは、APIテスト用の組み込みHTTPクライアントを提供することで、主要な攻撃ベクトルの一つを排除します。Axiosやnode-fetch、gotに頼る必要がありません。以下の防御戦略でnpm依存関係を最小限にしつつ、Apidogを無料でご利用ください。

このガイドでは、ロックファイル衛生から行動分析まで、API開発者向けに実践的な7つの防御レイヤーを解説します。

レイヤー1:ロックファイルの強制

ロックファイルが重要な理由

ロックファイルは、全依存パッケージの正確なバージョンを記録します。ロックファイルがないと、npm install^1.14.0のような範囲指定に対して最新バージョン(例:1.14.1、これが悪意のあるバージョンかもしれません)を解決します。

実践ルール

  • 必ずロックファイルをバージョン管理にコミットすること

    package-lock.json(npm)、yarn.lock(Yarn)、pnpm-lock.yaml(pnpm)、bun.lock(Bun)を必ず管理下に。

  • CI/CDではフリーズインストールを利用すること

    自動化環境でnpm installを使わず、下記を徹底:

    # npm
    npm ci
    
    # yarn
    yarn install --frozen-lockfile
    
    # pnpm
    pnpm install --frozen-lockfile
    
    # bun
    bun install --frozen-lockfile
    

npm cinode_modulesを削除し、ロックファイルと完全に一致した状態でインストールします。

  • プルリクエストでロックファイルの差分を確認すること package-lock.json等が変更された場合、何が・なぜ変わったか必ず精査。Socket.devなどの自動化ツールで不審な変更を検知可能。

ロックファイルの限界

ロックファイルは予期せぬバージョン解決から守りますが、「最初のインストール」や「新しい依存追加」時には無力です。多層防御の1レイヤーに過ぎません。

レイヤー2:postinstallスクリプトの無効化

攻撃ベクトル

Axios攻撃やua-parser-js、event-stream等、メジャーなnpm攻撃はすべてpostinstallスクリプトを悪用しました。これらはnpm install時に任意コードが実行されるため、アプリ実行前・監査前に攻撃が成立します。

スクリプトのグローバルブロック

.npmrcに以下を追加:

ignore-scripts=true
Enter fullscreen mode Exit fullscreen mode

またはコマンドで設定:

npm config set ignore-scripts true
Enter fullscreen mode Exit fullscreen mode

これで全てのライフサイクルスクリプト(preinstall/install/postinstall/prepare)を無効化できます。

スクリプト必須パッケージの対応

  • 選択的にrebuildする方法

    npm ci --ignore-scripts
    npm rebuild bcrypt sharp
    
  • 許可リストを使う(npm 10+)

    .scriptsrc.jsonを用意:

    {
      "allowScripts": {
        "bcrypt": true,
        "sharp": true
      }
    }
    
  • プリビルドバイナリを活用

    例えばsharpは現在プリビルドバイナリを提供しており、postinstallが不要なケースが増えています。

PackageGate注意点

2026年1月公開のPackageGate脆弱性では、Gitベースの依存関係はignore-scriptsでも無防備な場合が判明。Git依存はコミットハッシュで固定し、内容を監査してください。

レイヤー3:厳密なバージョン固定

セマンティックバージョン範囲の禁止

デフォルトの^1.14.0では、攻撃期間中に悪意のある新バージョンへ自動アップグレードされるリスクがあります。

  • 厳密なバージョン指定を徹底:

    {
      "axios": "1.14.0"
    }
    
  • .npmrc設定:

    save-exact=true
    save-prefix=''
    

推移的依存関係のオーバーライド

  • npmの場合:

    {
      "overrides": {
        "axios": "1.14.0",
        "plain-crypto-js": "npm:empty-npm-package@1.0.0"
      }
    }
    
  • Yarnの場合:

    {
      "resolutions": {
        "axios": "1.14.0"
      }
    }
    
  • pnpmの場合:

    {
      "pnpm": {
        "overrides": {
          "axios": "1.14.0"
        }
      }
    }
    

トレードオフ

厳密固定は自動更新されないため、手動でバージョンアップが必要です。セキュリティ重視なら手間を惜しまない選択を推奨。

レイヤー4:パッケージのプロベナンス検証

プロベナンスとは

npmのプロベナンス証明は、公開パッケージをソースコードやCI/CD環境に紐付け、Sigstore署名で透明性を保証します。

  • どのリポジトリ・どのCI/CD・どのコミットからビルドされたか証明可能。

プロベナンスの確認手順

npm audit signatures
Enter fullscreen mode Exit fullscreen mode

これで有効なプロベナンス証明の有無を確認できます。手動公開やローカルビルドにはプロベナンスがありません。

自パッケージでプロベナンス有効化

# GitHub Actions例
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Enter fullscreen mode Exit fullscreen mode

.npmrcにも:

provenance=true
Enter fullscreen mode Exit fullscreen mode

制限

プロベナンスは現時点でオプトインです。全てのnpmパッケージが対応しているわけではありません。また、プロベナンスは「どこでビルドされたか」しか証明しません。

レイヤー5:行動分析ツール活用

脆弱性スキャンの限界

npm auditSnykは既知のCVEのみ検出。ゼロデイ攻撃や未知の悪意コードは検知不可です。

Socket.dev

Socketは依存パッケージの振る舞い(ネットワーク要求、ファイル操作、シェル実行等)をリアルタイム分析します。

  • インストール例:

    npm install -g @socketsecurity/cli
    socket scan
    
  • GitHub連携でPR時に疑わしい依存を自動検知。

Socket.dev のスクリーンショットで、ネットワーク要求、ファイルシステムアクセス、シェルコマンド実行などの疑わしい動作を示す

Snyk

Snykは既知脆弱性のリスク評価や修正ガイダンスに強み。

  • インストール例:

    npm install -g snyk
    snyk test
    

Snyk のスキャン結果のスクリーンショットで、脆弱性と推奨される修正が表示される

多層チェック例

両方使い分けることで、ゼロデイ(Socket)・既知脆弱性(Snyk)両面から防御できます。

npm audit
socket scan
snyk test
Enter fullscreen mode Exit fullscreen mode

CI/CDで重大検出時はビルドをブロックしてください。

レイヤー6:依存関係の表面積最小化

依存関係ツリー監査

# 総依存数
npm ls --all | wc -l

# 重複・多重依存を確認
npm ls --all | sort | uniq -c | sort -rn | head -20
Enter fullscreen mode Exit fullscreen mode

質問リスト

  • 標準APIで代替できないか?
  • サブ依存が多すぎないか?
  • 小さなユーティリティならベンダー化(プロジェクトに直接組み込み)できないか?

代表的パッケージのネイティブ代替

パッケージ ネイティブ代替 Node.jsバージョン
axios, node-fetch, got fetch (グローバル) 18
uuid crypto.randomUUID() 19
dotenv --env-file フラグ 20.6
chalk util.styleText() 21.7
glob fs.glob() 22
path-to-regexp URLパターンAPI 23

APIテストの場合

APIテストワークフローはHTTPクライアント、アサーション、テストランナー、モックサーバー等に依存しがちです。

ApidogのUIスクリーンショットで、APIテストワークフローのさまざまなコンポーネントが示されている

Apidogを使えば、これらの依存をまとめて排除できます。

  • HTTPクライアント/アサーション/テストランナー/モックサーバー/ドキュメント生成が全て組み込み
  • npm依存が激減し、サプライチェーン攻撃のリスクも大幅低減

Apidogを無料で試して、APIテストスタックを統合しましょう。

レイヤー7:ネットワーク・ランタイム監視

悪質ドメインのブロック

攻撃後はC2サーバー等の悪質ドメインを遮断します。

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
Enter fullscreen mode Exit fullscreen mode

CI/CDでは必要最小限のアウトバウンド通信のみ許可し、他はデフォルト拒否。

StepSecurity Harden-Runner

StepSecurity Harden-RunnerはGitHub Actionsのワークフローをリアルタイム監視し、不審な通信・プロセス・ファイル操作を検知します。

- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # 厳格モードでは 'block'
Enter fullscreen mode Exit fullscreen mode

ランタイムプロセス監視

開発マシンではEDRツールでNode.jsプロセスが起動する子プロセス(osascript/cscript/python3等)を監視・検知しましょう。

推奨.npmrc設定

save-exact=true
save-prefix=
ignore-scripts=true
provenance=true
registry=https://registry.npmjs.org/
auth-type=web
audit-level=moderate
Enter fullscreen mode Exit fullscreen mode

この設定をリポジトリにコミットし、チーム全員で統一してください。

CI/CDセキュリティパイプライン例

7レイヤーを強制するGitHub Actions例:

name: セキュアなビルド
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci --ignore-scripts
      - run: npm ls --all > deps.txt
      - run: npm audit signatures
      - run: npx socket scan
      - run: npx snyk test
      - run: npm audit --audit-level=moderate
      - run: npm rebuild sharp bcrypt
Enter fullscreen mode Exit fullscreen mode

npmセキュリティの今後

プロベナンス義務化

npmはダウンロード数が多いパッケージへのプロベナンス証明義務化を検討中。Axios攻撃のような手動公開をブロックできます。

二人制リリース承認

人気パッケージは二人目のメンテナー承認が必要となる可能性が高いです。

ランタイム権限モデル

Denoのように明示的なパーミッションモデル導入が進行中。postinstall等も明示許可が必須に。

パッケージマネージャーの進化

pnpmのような厳格分離モデルがnpmにも導入されつつあり、攻撃対象領域が縮小する方向です。

よくある質問

npmにおけるサプライチェーン攻撃とは?

依存チェーンを標的にし、パッケージメンテナー侵害やタイポスクワットで悪意コードを仕込み、npm install等で自動実行→認証情報窃取やバックドア設置・漏洩へと繋がります。

npm auditだけで十分防御できますか?

いいえ。npm auditは既知CVEしか検出できず、ゼロデイや未知の悪意コードは検知できません。Socket.devのような行動分析ツールと併用してください。

npmの使用自体をやめるべき?

やめる必要はありませんが、バージョン固定・ロックファイル強制・スクリプト無効化・依存最小化などでリスクを下げてください。ネイティブ代替があれば積極的に利用を。

Apidogはnpmリスク低減にどう役立つ?

Apidogは組み込みHTTPクライアント・テストランナー・モックサーバー・ドキュメント生成を提供し、テスト用途でのnpm依存を大幅に削減。攻撃ベクトルが減少します。

npmにおけるプロベナンスとは?

Sigstoreによりパッケージとソースリポジトリ・CI/CDを暗号学的に紐付け。npm audit signaturesで確認できます。手動公開パッケージはプロベナンス無し=リスク。

悪意npmパッケージの件数は?

2024年は3,000件超、2025年Q4にはSonatypeが四半期で12万件超のマルウェアをブロック。増加傾向で、タイポスクワット中心ですが著名パッケージも例外ではありません。

PackageGate脆弱性とは?

2026年1月公開。npm/pnpm/Bun等のGit依存で、ignore-scriptsでもコード実行可能なゼロデイ脆弱性。Git依存はコミットハッシュ固定・監査必須。

主要なポイント

  • ロックファイル強制は必須だが、攻撃期間中の初回インストールには無力
  • .npmrcignore-scripts=true設定し、postinstall等を全ブロック
  • save-exact=trueで厳密バージョン固定し、範囲指定の事故を防ぐ
  • npm audit signaturesでプロベナンス検証、手動公開を早期検出
  • Snyk+npm audit(ベースライン)+Socket.dev(行動分析)の多層チェックを徹底
  • Node.jsネイティブAPIやApidog等で依存数を削減
  • StepSecurity Harden-RunnerでCI/CDのネットワーク監視

すべての依存は信頼の判断です。依存が少なければ攻撃対象も小さく、多層の検証を重ねるほど攻撃者の突破は困難になります。単一防御に頼らず、必ず多層で守りましょう。

button

Top comments (0)