frontend-review-deps

フロントエンドレビュー — 依存関係

フロントエンドプロジェクトの依存関係の健全性を監査します。対象は次の3分野です。

1. 最新性 — 古くなったパッケージと、破壊的変更を伴う更新手順
2. CVE のトリアージ — CVSS スコアだけでなく、実際の攻撃ベクトルに基づいて脆弱性の優先度を評価します
3. トレンドの監視 — 移行すべき、非推奨、放棄、または後継に置き換えられたライブラリ

手順

1. 次のコマンドを並行して実行します。
   • scripts/audit-deps.sh --repo <client-repo>
   • scripts/audit-trend-watch.sh --repo <client-repo>
2. raw/deps.json と raw/trend-watch.json を読み込みます。
3. CVE の検出結果ごとに、優先度を割り当てる前に、以下の攻撃ベクトルのトリアージマトリクスを適用します。
4. トレンド監視の検出結果（Tier 1／2／3）ごとに、インストール済みバージョンを確認し、移行コストを評価します。

CVE のトリアージ — 攻撃ベクトルマトリクス

CVSS スコアだけで判断しないでください。開発時依存関係にある CVSS 9.8 の RCE は、ブラウザーのみで動作する SPA には本番環境での影響がありません。

CVE の種類	開発時依存関係のみ	ランタイム（SPA）	ランタイム（SSR／Edge）
RCE	無視	無視	P0
プロトタイプ汚染	無視	P1（入力経路を確認）	P0
ReDoS	無視	P1（ユーザー入力に到達するか確認）	P0
パストラバーサル	無視	無視	P0
ライブラリ経由の XSS	無視	P0（HTML 生成ライブラリ）	P0
SSRF	無視	無視	P0
サプライチェーン（postinstall のマルウェア）	CI P0	CI P0	P0

トリアージ手順：

1. pnpm audit --prod を実行して、開発時依存関係を出力対象から除外します。
2. プロトタイプ汚染／ReDoS／XSS に注目します。それ以外の種類は、ブラウザーのみで動作する SPA ではリスクが低いものです。
3. 残った検出結果ごとに、ユーザーが制御する入力が脆弱なコード経路に到達するか確認します。到達しない場合は、優先度を P2 に下げます。
4. SSR／Edge Functions の場合、RCE／パストラバーサル／SSRF を P0 として扱います。
5. 無視した CVE はすべて、理由とともに kpi/audit-triage.md に記録します。

# Runtime-only CVEs (excludes devDeps)
pnpm audit --prod --audit-level=moderate --json | jq '
  .vulnerabilities | to_entries[] |
  { name: .key, severity: .value.severity,
    via: [.value.via[] | select(type=="object") | .title] }'

# Prototype Pollution / ReDoS only
pnpm audit --prod --json 2>/dev/null | jq -r '
  .vulnerabilities | to_entries[] |
  .value.via[] | select(type=="object") |
  select(.title | test("prototype|pollution|redos|regex denial"; "i")) |
  "\(.severity) \(.title) in \(.name)"' | sort -u

トレンド監視 — ライブラリのティア

package.json を data/trend-watch-config.json と照合します。

• Tier 1（今すぐ移行）：非推奨／放棄／後継に置き換え済みで、使い続ける合理的な理由がありません。移行コストが低く、成熟した代替手段があるライブラリも含みます。正式に非推奨になっていない場合も対象です（jest → vitest、axios → ky/fetch、cypress → Playwright）。
• Tier 2（移行を計画）：メンテナンスモード／満足度の低下／RSC 非対応。
• Tier 3（監視）：サポート終了（EOL）バージョンが存在する／満足度が低下傾向にある。

Tier 1 の検出結果ごとに、具体的な移行経路を提案し、所要時間（時間／日数）を見積もります。 Tier 2 の検出結果ごとに、今後1〜3か月以内の移行スケジュールを推奨します。 Tier 3 の検出結果ごとに、継続的な監視リストに追加します。

ライブラリの選定 — Web 標準を優先

新しい依存関係を代替手段として推奨する前に、次の順序で検討します。

1. Web プラットフォーム／ECMAScript の標準 API で対応できますか？

用途	避けるもの	代わりに使用するもの
日付／時刻	moment、date-fns、dayjs	Temporal（ポリフィル）、または単純なケースでは Date
配列／オブジェクトのユーティリティ	lodash、ramda	Array.prototype.{flatMap,findLast,groupBy}、Object.{entries,fromEntries,groupBy}、structuredClone()
HTTP リクエスト	axios、request	fetch + AbortController
UUID の生成	uuid、nanoid	crypto.randomUUID()
URL／クエリパラメーター	qs、query-string	URL、URLSearchParams
数値／日付の書式設定	numeral.js	Intl.NumberFormat、Intl.DateTimeFormat

2. ツリーシェイキングに対応していますか？ インポートしたものだけがバンドルに含まれる必要があります。
3. 積極的にメンテナンスされていますか？ 過去6か月以内にリリースされていること。
4. gzip 圧縮後のバンドルへの影響が 5 kb 未満ですか？ pnpm build とバンドルアナライザーで確認します。

破壊的変更を伴う更新手順

1. 単独の PR として提案します。機能追加やリファクタリングと決してまとめないでください。
2. 変更履歴を読み、削除された API を確認します。コードベース内の使用箇所を grep／ast-grep で検索します。
3. マージ前に typecheck && lint && test:ci && e2e が成功することを必須とします。
4. VRT スナップショットがある場合は、更新後に Linux コンテナーで再生成します。

出力

<client-repo>/.frontend-review/report/latest/md/deps-review.md に以下を記載します。

• 古いパッケージの表（名前、現在のバージョン、最新バージョン、破壊的変更の有無）
• 攻撃経路のトリアージ後の CVE の検出結果（優先度、パッケージ、種類、優先度の理由）
• Tier 別の トレンド監視の検出結果（Tier 1：今すぐ移行、Tier 2：計画、Tier 3：監視）
• 正当な理由を添えた 無視する CVE（kpi/audit-triage.md 用）
• 推奨する PR：更新のバッチと移行の着手点

境界

• TypeScript／lint／デッドコードは評価しないでください。これらは frontend-review-hygiene の対象です。
• AI ペンテストを実行したり、HTML シンクを確認したりしないでください。これらは frontend-review-security の対象です。
• クライアントリポジトリのソースファイルには触れないでください。

参考資料

• チェックリスト：02-dependencies.md、27-dependency-audit.md、28-trend-watch.md
• データ：data/trend-watch-config.json、data/trend-watch-history.json
• スクリプト：scripts/audit-deps.sh、scripts/audit-trend-watch.sh、scripts/fetch-trend-data.sh
• フェーズ：week-1-ci-baseline.md