dependency-audit

依存関係の監査

依存関係のリスクを包括的に評価します。ライセンスの互換性分析、メンテナンス状況のスコアリング、CVE の検出、不要な依存関係の特定、推移的依存関係のリスクマッピングを行います。緊急度（セキュリティ → ライセンス → メンテナンス → 不要な依存関係）に沿って優先順位を付けた、実行可能な修正手順を含むレポートを作成します。

参考ファイル

ファイル	内容	読み込むタイミング
references/license-compatibility.md	ライセンス互換性マトリックス、コピーレフトの検出、商用利用に安全なライセンス	常に
references/health-metrics.md	メンテナンス状況の指標、スコアリング基準、放棄の検出	常に
references/bloat-detection.md	未使用の依存関係、機能の重複、大規模な推移的依存関係ツリーの特定	不要な依存関係の分析を依頼された場合
references/cve-sources.md	CVE データベース、勧告の情報源、脆弱性の深刻度の解釈	セキュリティ監査を依頼された場合

前提条件

• プロジェクトの依存関係ファイル（pyproject.toml、requirements.txt、 package.json、Cargo.toml、go.mod）へのアクセス
• ロックファイル（正確なバージョンと推移的依存関係を確認するため）
• プロジェクトのライセンス（互換性要件を判断するため）

ワークフロー

フェーズ 1：依存関係ツリーを解析する

1. 直接依存関係 — プロジェクトで明示的に宣言されているパッケージです。
2. 推移的依存関係 — 依存関係が依存するパッケージです。直接依存関係の数の 10～50 倍になることもよくあります。
3. バージョン制約 — 固定（==1.2.3）、範囲指定（>=1.0,<2.0）、または浮動（*）です。
4. 開発用と本番用 — 開発・テスト用の依存関係と本番用の依存関係を分けます。

ツール：

• Python：uv pip list、pip-audit、pipdeptree
• Node.js：npm list --all、npm audit
• Rust：cargo tree、cargo audit

フェーズ 2：ライセンスを監査する

依存関係ごとに、以下を行います。

1. ライセンスを特定する — パッケージのメタデータ、LICENSE ファイル、pyproject.toml を確認します。

2. 互換性を分類する — プロジェクト自身のライセンスと照らし合わせます。

   ライセンス	商用利用可	コピーレフト	リスクレベル
   MIT、BSD、ISC、Apache 2.0	はい	なし	低
   LGPL	注意が必要	弱い	中
   GPL-2.0、GPL-3.0	いいえ（GPL プロジェクトを除く）	強い	高
   AGPL	いいえ（AGPL プロジェクトを除く）	強い＋ネットワーク	重大
   不明	判断できません	不明	重大

3. 問題にフラグを付ける — プロプライエタリプロジェクトでのコピーレフトライセンス、不明なライセンス、バージョン間でのライセンス変更を確認します。

フェーズ 3：メンテナンス状況を評価する

依存関係ごとに、メンテナンスの兆候を評価します。

指標	健全	要注意	放棄状態
最終リリース	6 か月未満	6～18 か月	18 か月超
コミット数（90 日）	10 以上	1～9	0
未解決 Issue への応答	2 週間未満	2～8 週間	8 週間超、または応答なし
バス係数	メンテナー 3 人以上	2 人	1 人
CI の状態	成功	不安定	失敗、または未設定

フェーズ 4：セキュリティを確認する

1. 既知の CVE — アドバイザリデータベースと照合します：

   • Python：pip-audit、PyPI アドバイザリデータベース
   • Node.js：npm audit、GitHub Advisory Database
   • 一般：NVD（National Vulnerability Database）

2. 深刻度の分類 — CVSS スコアの解釈：

   CVSS スコア	深刻度	対応
   9.0-10.0	致命的	直ちにアップグレードする
   7.0-8.9	高	数日以内にアップグレードする
   4.0-6.9	中	数週間以内にアップグレードする
   0.1-3.9	低	都合のよいときにアップグレードする

3. 修正の有無 — パッチ適用済みのバージョンはありますか？ない場合、回避策は何ですか？

フェーズ 5：肥大化を検出する

1. 未使用の依存関係 — コードベース内のどこからもインポートされていない依存関係です。
2. 機能の重複 — 同じ機能を提供する複数のパッケージです（HTTP クライアントが 2 つ、 JSON パーサーが 2 つなど）。
3. 肥大化した推移的依存関係ツリー — 単純な機能のために、数十個のサブ依存関係を取り込む パッケージです。
4. サイズ分析 — 小さな機能のために使われている大きなパッケージです。

フェーズ 6：報告する

対応項目を優先順位付けしたレポートを作成します。

出力形式

## Dependency Audit: {Project Name}

### Summary
| Metric | Count |
|--------|-------|
| Direct dependencies | {N} |
| Transitive dependencies | {N} |
| License issues | {N} |
| Maintenance concerns | {N} |
| Security vulnerabilities | {N} |
| Bloat candidates | {N} |

### License Compliance

| Package | Version | License | Compatible | Issue |
|---------|---------|---------|------------|-------|
| {pkg} | {ver} | MIT | Yes | None |
| {pkg} | {ver} | GPL-3.0 | No | Copyleft in proprietary project |
| {pkg} | {ver} | Unknown | Unknown | License not identifiable |

### Maintenance Health

| Package | Last Release | Commits (90d) | Maintainers | Status |
|---------|-------------|---------------|-------------|--------|
| {pkg} | {date} | {N} | {N} | {Healthy/Warning/Abandoned} |

### Security Vulnerabilities

| Package | Version | CVE | Severity | Fix Available | Fixed In |
|---------|---------|-----|----------|---------------|----------|
| {pkg} | {ver} | {CVE-ID} | {severity} | {Yes/No} | {version} |

### Bloat Analysis

| Package | Install Size | Used By | Recommendation |
|---------|-------------|---------|----------------|
| {pkg} | {size} | {usage description} | {Remove/Replace/Keep} |

### Action Items

#### Immediate (Security)
1. Upgrade {pkg} to {version} — fixes {CVE-ID} ({severity})

#### Short-term (License)
1. Review {pkg} GPL usage — may require license change or removal

#### Medium-term (Maintenance)
1. Find alternative to {pkg} — abandoned since {date}

#### Long-term (Bloat)
1. Remove {pkg} — unused in codebase
2. Replace {pkg} with lighter alternative

### Transitive Risk
- {direct-dep} depends on {transitive-dep} which has {issue}

評価基準

1. 本番環境の依存関係を優先します。 開発／テスト用の依存関係はユーザーに配布されないため、リスクが低くなります。本番環境の依存関係は、より厳しく監査してください。
2. 推移的なリスクも現実のものです。 MIT ライセンスの直接依存関係が、GPL ライセンスの推移的依存関係を取り込む場合があります。必ず依存関係ツリー全体を確認してください。
3. 放置されていても、壊れているとは限りません。 1 年間更新されていない、成熟して安定したライブラリでも、問題ない場合があります。ライブラリが「完成」しているのか、「放置」されているのかに基づいて評価してください。
4. セキュリティに妥協はできません。 致命的および高深刻度の CVE には、直ちに対処する必要があります。中深刻度の CVE は追跡してください。低深刻度の CVE は、次回の依存関係更新サイクルまで保留できます。

エラー処理

問題	解決策
ロックファイルがない	宣言された依存関係に基づいて監査します。ロックファイルがない場合、推移的な分析が不完全であることを記録してください。
ライセンスのメタデータがない	パッケージのリポジトリにある LICENSE ファイルを確認します。ライセンスを特定できないパッケージを記録してください。
パッケージレジストリを利用できない	キャッシュされたメタデータとローカルのロックファイルデータを使います。
依存関係が多すぎて手動で監査できない	優先順位を付けます。本番環境の依存関係、直接依存関係、既知の問題がある推移的依存関係の順に確認してください。

監査すべきでない場合

次の場合は、監査を見送るよう提案してください。

• 出荷予定のないプロトタイプである — 本番投入の判断まで監査を延期します
• ユーザーが求めているのは監査ではなく依存関係の更新である — 別のタスクです（dependabot、renovate）
• プロジェクトに依存関係がない（標準ライブラリのみ） — 監査対象がありません

よくある正当化

正当化	実態
「信頼できるパッケージです」	信頼はセキュリティモデルではありません。信頼されているパッケージも侵害されます（event-stream、ua-parser-js、colors.js）
「マイナーバージョンの更新にすぎません」	マイナーバージョンでも、脆弱性の導入、動作の変更、推移的依存関係の追加が起こり得ます。セマンティックバージョニングは約束であり、保証ではありません
「脆弱な関数は使っていません」	推移的依存関係が使っている可能性があります。また、攻撃対象領域にはプロセスに読み込まれるあらゆるコードが含まれます
「CVE の深刻度は低いです」	単独では低深刻度でも、状況によっては重大になり得ます。クラウドメタデータにアクセスできる内部サービスにおける「低深刻度」の SSRF は、重大です
「既知のエクスプロイトが出たら更新します」	既知のエクスプロイトがあるなら、すでに対応が遅れています。侵害が起きてからではなく、SLA 内にパッチを適用してください
「依存関係が多すぎて監査できません」	それこそが問題であり、言い訳にはなりません。依存関係の多さ自体がリスクとして指摘される事項です

重大な懸念事項

• 推移的依存関係のツリーを無視し、直接依存関係のみを監査している
• 脆弱なコードパスに到達可能かを確認せず、CVE を問題なしとしている
• ライセンスの互換性を確認していない — プロプライエタリなコードベースにおける GPL は法的な問題です
• 単一のスキャナーの「既知の脆弱性なし」という結果を、他の情報と照合せずに受け入れている
• 依存関係の古さを無視している — 2 年以上更新されていない未メンテナンスのパッケージはリスクです
• ロックファイルの分析を省略している（バージョンが固定されているか、変動するか）

検証

• 直接依存関係と推移的依存関係の両方をスキャン済み
• 脆弱性スキャナーの出力を取得済み：npm audit / pip-audit / cargo audit
• 各 CVE の指摘に、深刻度、影響を受けるバージョン範囲、アップグレード方法、到達可能性の評価が含まれている
• プロジェクトのライセンスとの互換性を確認済み
• 主要な依存関係の古さとメンテナンス状況を確認済み
• ロックファイルが存在し、バージョン固定を確認済み — 本番環境に変動する範囲指定がない