dependency-audit

依存関係の監査 — フレームワーク、パッケージ、ツールチェーンのセキュリティ

プロジェクトの依存関係、フレームワーク、言語ランタイム、開発ツールを監査し、既知の脆弱性（CVE）、セキュリティ上のアンチパターン、サプライチェーンリスクを確認します。

方法

ステップ 1：スタックを棚卸しする

使用しているものをすべて特定します。直接依存関係だけでなく、依存関係の全体像を確認してください。

パッケージマニフェスト — 読み込んで一覧化する：

Node/JS:    package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python:     requirements.txt, Pipfile.lock, pyproject.toml, poetry.lock
Ruby:       Gemfile, Gemfile.lock
Go:         go.mod, go.sum
Rust:       Cargo.toml, Cargo.lock
Java:       pom.xml, build.gradle
PHP:        composer.json, composer.lock
.NET:       *.csproj, packages.config

フレームワークとランタイムのバージョン：

• フレームワークのバージョンを確認する（Next.js、Django、Rails、Spring、Laravel、Express など）
• 言語／ランタイムのバージョンを確認する（Node.js、Python、Ruby、Go、Java、PHP、.NET）
• インフラストラクチャツールを確認する（Docker のベースイメージ、Terraform プロバイダー、Kubernetes のバージョン）

開発ツールと CI/CD：

• CI/CD パイプラインの設定ファイルを確認する（.github/workflows、.gitlab-ci.yml、Jenkinsfile）
• pre-commit フック、リンター、フォーマッターを確認する
• コンテナーのベースイメージと更新状況を確認する
• IaC ツールのバージョンを確認する（Terraform、Pulumi、CDK）

パッケージマニフェストの注意点：

• optionalDependencies — インストールされていても、デフォルトでは監査されません
• peerDependencies — バージョン範囲が実際にインストールされているバージョンと一致しない場合があります
• overrides / yarn の resolutions / pnpm の overrides — アドバイザリーへの対処ではなく、単に警告を抑制する目的で使われていないか確認する
• モノレポ：ルートだけでなく、packages/*/package.json と apps/*/package.json をすべて読み込む
• engines フィールド — LTS より古い Node では、ほかの監査を行っても意味がありません

ステップ 2：自動監査ツールを実行する

プロジェクトに適した監査コマンドを実行します。

# Node.js
npm audit --json                # full structured output
npm audit --omit=dev --json     # production-only: filters dev/build-time vulns
# Compare the two — vulns only in dev/build tooling do not ship to users
# and should be triaged as lower priority. Don't bury this in the report.

# Python
pip audit          # If pip-audit installed
safety check       # If safety installed

# Ruby
bundle audit

# Go
govulncheck ./...

# Rust
cargo audit

# PHP
composer audit

# .NET
dotnet list package --vulnerable

# Docker
docker scout cves <image>
trivy image <image>

# General (if Trivy is available)
trivy fs .

修正を適用する — --force を使う前に必ず読む：

npm audit fix                   # safe: upgrades within stated ranges
npm audit fix --dry-run --force # ALWAYS dry-run first
npm audit fix --force           # only after reviewing the dry-run

npm audit fix --force は、監査シグネチャに引っかからない古いバージョンへパッケージをダウングレードすることで、アドバイザリーを解消する場合があります。これはほぼ常に誤った対処です（たとえば、推移的な postcss CVE を「修正」するために next@16 を next@9 にダウングレードするなど）。ドライランの出力に「Will install X@Y, which is a breaking change」と表示された場合は、ツールがダウングレードを試みています。

npm audit fix でアドバイザリーを解決できない場合（上流パッケージによって推移的な依存関係のバージョンが固定されている場合）：

1. 到達可能性を確認する — 使用状況において、脆弱なコードパスが実際に呼び出されているか確認します。npm ls <package> を実行し、親パッケージのソースを読むことで、そのコードパスに到達しないことを確認できる場合があります。
2. パッチ適用済みバージョンを指定するために、package.json の overrides を使うことを検討します（十分にテストしてください。親パッケージが壊れる可能性があります）。
3. 親プロバイダー自体を置き換えることを検討します。
4. いずれも該当しない場合： 問題を明記して上流の対応を追跡し、検出事項を黙って除外するのではなく、監査レポートに記載します。

ステップ 3：フレームワーク固有の既知の問題を調査する

パッケージの CVE だけでなく、使用中のフレームワークに固有の既知の脆弱性パターンも確認します。最近のアドバイザリーや、よくある設定ミスを検索してください。

直接依存するパッケージごとに、インストール済みバージョンを次の情報と照合します。

• https://github.com/advisories?ecosystem=npm&query=<package>
• https://github.com/<org>/<repo>/security/advisories

以下のフレームワーク固有のパターンでは、継続的に見られるアンチパターン（Mass Assignment、本番環境でのデバッグ有効化など）を取り上げます。最近の CVE は、固定のアドバイザリー一覧がすぐに古くなり、LLM の学習データも最新情報より 6 か月以上遅れていることが多いため、最新情報を確認する必要があります。 Next.js / React：

• 内部エンドポイントを公開する Server Actions（14.1.1 より前ではミドルウェアをバイパスする CVE-2025-29927）
• サニタイズせずに使用する dangerouslySetInnerHTML
• 画像最適化を介した SSRF（ドメイン制限のない next/image）
• 公開ディレクトリまたはクライアントバンドル内に .env ファイルを公開すること（NEXT_PUBLIC_ プレフィックスによるシークレットの漏えい）
• ミドルウェアによる認証バイパスのパターン — middleware.ts がすべての保護対象ルートに一致することを確認します
• Server Component / Client Component の境界からサーバー専用データが漏えいすること：
  • process.env.SECRET を読み取るモジュール、または DB クライアントをインスタンス化するモジュールには import "server-only"; を記述します — Client Component からインポートされるとビルドに失敗します
  • 次を検索します：process.env.[A-Z_]+ にアクセスする lib/ 内のファイルのうち、server-only をインポートしていないもの
  • 逆方向の確認："use client" を含むファイルが、そのようなモジュールからインポートしている場合は漏えいです
• 古い next.config.js のセキュリティヘッダー

Django：

• 本番環境での DEBUG=True
• ALLOWED_HOSTS の設定ミス（ワイルドカード *）
• CSRF ミドルウェアの欠落、または状態を変更するビューへの @csrf_exempt の使用
• パラメーター化されていない extra()、raw()、RawSQL による生 SQL
• セッションでの Pickle デシリアライズ（JSON シリアライザーを使用します）
• ソース管理へのシークレットキーのコミット

Rails：

• Strong Parameters を使わないマスアサインメント
• where("column = '#{input}'") による SQL インジェクション
• パッチ未適用の Action Pack、Action View、または Active Record の CVE
• Cookie の安全でないデシリアライズ（secret_key_base のローテーションを確認します）
• API 専用モードでの CSRF トークンのバイパス

Express / Node.js：

• Object.assign、lodash.merge、deep-extend を介したプロトタイプ汚染
• バリデーションパターンにおける ReDoS（正規表現サービス拒否攻撃）
• ファイル配信ルートの req.params を介したパストラバーサル
• 認証エンドポイントにおけるレート制限の欠落
• ユーザー入力を使った eval() または Function()
• 同期処理によるイベントループのブロック

サーバーレス / エッジランタイム（Vercel、Lambda、Cloud Run、Workers）：

• インメモリ状態 ≠ レート制限です。 レート制限、セッション、キャッシュに使うモジュールスコープの Map または Set はインスタンスごとに存在します。コールドスタートで状態がリセットされ、負荷は複数のインスタンスに分散されるため、攻撃者は簡単に回避できます。
  • 次を検索します：server-action / API-route ファイル内の const rateLimitMap = new Map、const cache = new Map
  • 修正方法：共有ストアを使用します — Vercel KV、Upstash Ratelimit、Redis、DynamoDB
• 上限のないインメモリコレクションは、トラフィックの増加時にメモリリークを引き起こします。サイズに上限を設け、エビクション（LRU または FIFO）を行います。
• **x-forwarded-for の信頼性：**エッジがこの値を上書きする場合にのみ信頼できます。設定ミスのあるプロキシチェーンの背後では、攻撃者が偽装できます。フォールバックを単一の "unknown" バケットにすると、すべての匿名トラフィックがまとめてスロットリングされます。ランダムな値へのフォールバックでは、制限が気付かれないまま無効になります。

Spring / Java：

• Spring4Shell および関連する RCE 脆弱性
• デシリアライズ攻撃（Java ネイティブシリアライズ、Jackson のポリモーフィック型）
• Spring Expression Language における SpEL インジェクション
• 状態を変更するエンドポイントでの CSRF 保護の欠落
• 認証なしで公開されている Actuator エンドポイント

Laravel / PHP：

• 本番環境での APP_DEBUG=true（エラーページで環境変数が漏えいします）
• バインディングのない生の DB クエリによる SQL インジェクション
• $fillable / $guarded を使わないマスアサインメント
• 型検証のないファイルアップロード（アップロードされた .php を介した PHP の実行）
• キュージョブにおける安全でないデシリアライズ

WordPress：

• 古いコア、テーマ、またはプラグインのバージョン（最も一般的な攻撃ベクトル）
• wp-admin でのファイルエディターの有効化（管理者アカウントが侵害された場合にコードインジェクションが可能になります）
• XML-RPC の有効化（ブルートフォース攻撃の増幅、SSRF）
• デフォルトの管理者ユーザー名、脆弱なパスワード
• パッチ未適用のプラグインの脆弱性（WPScan データベースを確認します）

ステップ 4：サプライチェーンのリスクを確認する

既知の CVE だけでなく、サプライチェーン攻撃の兆候も確認します。

依存関係の混同／置き換え：

• パブリックレジストリで第三者が取得できる可能性のあるプライベートパッケージ名
• プライベートレジストリを指定する .npmrc または pip.conf がない
• ロックファイルの整合性検証がない

タイポスクワッティング：

• 人気のあるパッケージ名に似たスペルミスのパッケージ名
• ダウンロード数がごく少ない、最近公開されたパッケージ
• 最近、所有者が変更されたパッケージ

悪意のあるパッケージ：

• ネットワークリクエストを行う、またはコードを実行する postinstall スクリプト（package.json の scripts.postinstall）
• 難読化されたコードを含むパッケージ
• 機能に対して過剰な権限を要求するパッケージ

メンテナンスのリスク：

• メンテナンスされていないパッケージ（2 年以上コミットがない、リポジトリがアーカイブされている）
• 重要な機能を単独のメンテナーが担当しているパッケージ
• 既知の脆弱性が未修正のパッケージ（メンテナーが応答しない）

ロックファイルの整合性：

• ロックファイルがコミットされているか？ git ls-files | grep -E 'package-lock\.json|yarn\.lock|pnpm-lock\.yaml|Gemfile\.lock|poetry\.lock|composer\.lock|Cargo\.lock|go\.sum'
• CI はロックファイルからインストールしているか？
  • .github/workflows/*.yml、.gitlab-ci.yml、Jenkinsfile、vercel.json、netlify.toml、Dockerfile を確認します
  • npm install（不適切）と npm ci（適切）の違い、yarn install（不適切）と yarn install --immutable（適切）の違い、pip install -r（不適切）と pip install --require-hashes -r（適切）の違いを確認します
• ロックファイルに integrity ハッシュがあるか？（最新の npm／pnpm ではデフォルトで含まれます）

ステップ 5：開発ツールと CI/CD のセキュリティを確認する

GitHub Actions：

• pull_request_target トリガーで PR のコードをチェックアウトしている（コードインジェクションのリスク）
• フォークされた PR のワークフローからシークレットにアクセスできる
• アクションのバージョンが固定されていない（uses: actions/checkout@main と @v4.1.0 または SHA 固定の違い）
• run: ブロック内の ${{ github.event.issue.title }} によるスクリプトインジェクション

Docker：

• コンテナ内で root として実行している（USER ディレクティブがない）
• 既知の CVE があるベースイメージ（trivy または docker scout で確認）
• イメージレイヤーに埋め込まれたシークレット（docker history で確認可能）
• 固定バージョンではなく latest タグを使用している

Terraform／IaC：

• .tf ファイルにハードコードされたシークレット
• プロバイダーバージョンが固定されていない
• 状態ファイルの暗号化がない
• プロバイダー設定で IAM 権限が過剰に許可されている

出力形式

# Dependency & Stack Security Audit
## Project: [name]
## Stack: [language, framework, key tools]
## Date: [date]

### Stack Inventory
| Component | Version | Latest | Status |
|-----------|---------|--------|--------|

### Known Vulnerabilities (CVEs)
| Package | Installed | Vuln | Severity | Where reachable | CVE | Fix Version |
|---------|-----------|------|----------|-----------------|-----|-------------|

Where reachable values: `runtime` / `build-only` / `dev-only`. Confirm with `npm ls --omit=dev <package>` or inspect the deployment artifact (Vercel function bundle, Docker layer). Build- and dev-only vulnerabilities should not block a release on their own; runtime-reachable ones should.

### Framework-Specific Issues
#### [SEVERITY] [Title]
**Component:** [framework/tool name and version]
**Issue:** [description]
**Evidence:** [code or config snippet]
**Remediation:** [specific fix]

### Supply Chain Risks
| Risk | Package/Component | Details | Remediation |
|------|-------------------|---------|-------------|

### Dev Tool / CI Security
| Tool | Issue | Severity | Remediation |
|------|-------|----------|-------------|

### Prioritized Action Plan
1. [Critical — actively exploited CVEs, RCE vulnerabilities]
2. [High — known CVEs with public exploits, supply chain risks]
3. [Medium — framework misconfigurations, outdated dependencies]
4. [Low — maintenance risks, best practice improvements]

対応範囲

• ユーザーが提供したコードと設定のみを監査します
• CVE を特定する際は、実際にインストールされているバージョンに該当することを確認します
• 特定した問題ごとに、具体的な修正バージョンまたは対処手順を提示します
• 脆弱性の悪用に特定の条件が必要な場合（実質的な深刻度を下げる場合）は、その旨を記載します
• 許可されていない対象に対して、発見した脆弱性を悪用する支援は拒否します

参考資料

• OWASP Dependency-Check
• National Vulnerability Database (NVD)
• GitHub Advisory Database
• Snyk Vulnerability Database
• npm audit／pip-audit／bundler-audit のドキュメント
• SLSA（ソフトウェア成果物のサプライチェーンレベル）フレームワーク