dep-audit

依存関係の監査

リポジトリ横断の依存関係監査です。パッケージマニフェスト（package.json、pyproject.toml、Cargo.toml、go.mod）をスキャンし、古いパッケージ、セキュリティアドバイザリ、リポジトリ間のバージョン競合、ライセンスの互換性に関する問題を検出します。優先順位を付けた更新計画を作成します。

インストール

git clone https://github.com/thatrebeccarae/claude-marketing.git && cp -r claude-marketing/skills/dep-audit ~/.claude/skills/

使用するタイミング

• 月次のメンテナンス：定期的に実行し、依存関係のずれが積み重なる前に検出します
• リリース前：既知の脆弱性が本番環境に持ち込まれないことを確認します
• セキュリティインシデント発生時：CVEが公開されたときに、すべてのリポジトリへの影響を迅速に評価します
• 新しいリポジトリのオンボーディング時：引き継いだ、または採用するリポジトリの依存関係の健全性を把握します

使用方法

• /dep-audit [repo-path] — 単一のリポジトリを監査します
• /dep-audit [repo-path1] [repo-path2] ... — リポジトリ横断の監査を実行します（バージョン競合の検出を有効にします）

手順

1. パッケージマネージャーの検出

対象のリポジトリをスキャンし、マニフェストファイルを探します。

パッケージマネージャー	マニフェスト	ロックファイル
npm	package.json	package-lock.json
yarn	package.json	yarn.lock
pnpm	package.json	pnpm-lock.yaml
pip	requirements.txt、setup.py、setup.cfg	requirements.txt（固定バージョン）
poetry	pyproject.toml（[tool.poetry]を含む）	poetry.lock
uv	pyproject.toml（[tool.uv]を含む）	uv.lock
cargo	Cargo.toml	Cargo.lock
go mod	go.mod	go.sum

# Detect which manifests exist
ls package.json pyproject.toml Cargo.toml go.mod requirements.txt 2>/dev/null
# Detect lock files
ls package-lock.json yarn.lock pnpm-lock.yaml poetry.lock uv.lock Cargo.lock go.sum 2>/dev/null

複数のエコシステムが含まれる場合（たとえば、Node.js のフロントエンドと Go のバックエンドを含むモノレポ）、それぞれを個別に監査し、結果を統合します。

2. マニフェストとロックファイルの解析

マニフェストを読み取って宣言済みの依存関係（直接依存）を特定し、ロックファイルから解決済みのバージョン（推移的依存）を確認します。次のように区別します。

• 本番依存関係（dependencies、[dependencies]、メインの requires）
• 開発依存関係（devDependencies、[dev-dependencies]、extras）

3. 古いパッケージの確認

レジストリに問い合わせて最新バージョンを確認し、差分を分類します。

# Node.js
npm outdated --json

# Python (pip)
pip list --outdated --format=json

# Python (poetry)
poetry show --outdated

# Rust
cargo outdated --format json  # requires cargo-outdated

# Go
go list -m -u all

古いパッケージをそれぞれ次のように分類します。

• パッチ更新（例：2.3.1 -> 2.3.4）：安全で、通常はバグ修正です
• マイナー更新（例：2.3.1 -> 2.5.0）：新機能が追加され、後方互換性が保たれるはずです
• メジャー更新（例：2.3.1 -> 3.0.0）：破壊的変更が含まれる可能性が高く、移行の確認が必要です

4. セキュリティアドバイザリの確認

エコシステム標準の監査ツールを実行します。

# Node.js
npm audit --json

# Python
pip-audit --format=json  # or: safety check

# Rust
cargo audit --json  # requires cargo-audit

# Go
govulncheck ./...

結果から深刻度を判定します。

• クリティカル：リモートコード実行、認証の回避、データの持ち出し
• 高：権限昇格、重大なデータ漏えい
• 中：サービス拒否の可能性、限定的なデータ漏えい
• 低：情報開示、軽微な問題

5. リポジトリ横断の分析（複数のリポジトリ）

2つ以上のリポジトリを監査する場合は、依存関係のバージョンを比較します。

• バージョン競合：同じパッケージがリポジトリ間で異なるバージョンになっている状態（例：リポジトリ A の [email protected]、リポジトリ B の [email protected]）
• 共通依存関係：複数のリポジトリで使用されており、単一バージョンに統一できる可能性があるパッケージ
• メジャーバージョンの不一致：リポジトリ間の乖離を示すため、最優先事項として報告します

パッケージ、リポジトリごとのバージョン、推奨する対象バージョンを示す競合テーブルを提示します。

6. ライセンスのスキャン

互換性ルールに照らして依存関係のライセンスを確認します。

# Node.js
npx license-checker --json

# Python
pip-licenses --format=json

# Rust
cargo license --json  # requires cargo-license

# Go
go-licenses report ./...  # requires go-licenses

次の問題を報告します。

• 許容的ライセンスのプロジェクトにおけるコピーレフト：MIT/Apache ライセンスのプロジェクトにおける GPL/AGPL 依存関係
• 不明または欠落しているライセンス：ライセンスのメタデータがない依存関係
• OSI 承認外のライセンス：独自ライセンスまたは制限の厳しいライセンス
• ライセンスの競合：互換性のないライセンスの組み合わせ（例：GPLv2-only と Apache-2.0）

7. 更新計画を作成する

すべての指摘事項に優先順位を付け、1つの順序付きリストにまとめます。

1. 重大なセキュリティアドバイザリ — 直ちに修正
2. 高リスクのセキュリティアドバイザリ — 今スプリントで修正
3. ライセンス違反 — 評価して是正
4. 既知の問題がある大幅な旧バージョン — 移行を計画
5. リポジトリ間のバージョン競合 — バージョンを統一
6. 軽微な旧バージョン — まとめて更新
7. パッチの旧バージョン — まとめて更新

関連する更新はグループ化します。

• すべての@types/*パッケージを1つのPRにまとめる
• 同じ組織のすべてのパッケージ（例：@babel/*）
• まとめて更新する必要があるピア依存関係の連鎖

メジャーアップデートには、破壊的変更のリスクを記載します。利用可能な場合は、移行ガイドへのリンクを付けます。

8. レポート

重要度をコード化した概要表を作成します。

優先度	パッケージ	現在	最新	種別	重要度	影響を受けるリポジトリ	対応
1	lodash	4.17.19	4.17.21	patch	CRITICAL (CVE-2021-23337)	repo-a, repo-b	直ちに更新
2	express	4.17.1	4.21.2	minor	HIGH (CVE-2024-29041)	repo-a	今スプリントで更新
3	webpack	4.46.0	5.94.0	major	MEDIUM (旧バージョン)	repo-a	移行を計画
...

続けて、以下を記載します。

• リポジトリごとの依存関係の合計数（直接／推移的）
• セキュリティの概要：X 件の重大、Y 件の高、Z 件の中、W 件の低
• 旧バージョンの概要：X 件のメジャー、Y 件のマイナー、Z 件のパッチ
• ライセンスの概要：X 件の要確認、Y 件の問題なし
• リポジトリ間の競合：バージョンに差異のあるパッケージ X 件

主な原則

1. 自動更新は行いません。 このスキルは監査と推奨を行います。何をいつ更新するかは人が判断します。自動更新では、特にメジャーバージョンで破壊的変更が発生する可能性があります。
2. セキュリティを最優先します。 重大および高リスクの脆弱性は、他の依存関係がどれほど古くても、常に優先順位リストの上位に置きます。
3. 関連する更新をグループ化します。 reactをreact-domと一緒に更新しないと、バージョンの不一致が生じます。ピア依存関係の連鎖を必ず特定します。
4. 状況を考慮します。 開発専用の依存関係（例：eslint）のメジャーバージョン更新は、CVE のある本番ランタイム依存関係のパッチ更新よりリスクが低くなります。
5. ロックファイルを正とします。 マニフェストに記載された範囲指定ではなく、実際に解決されたバージョンをロックファイルで必ず確認します。
6. 最新バージョンを追い求めること自体を目的にしません。 依存関係が正常に動作し、安定していて、アドバイザリもない場合、「旧バージョン」であることは「壊れている」ことと同じではありません。

このスキルの使い方

次のように依頼します。

• 「~/Repos/my-app の依存関係を監査して」
• 「この3つのリポジトリ間で依存関係のバージョンを比較して」
• 「このプロジェクトにセキュリティ脆弱性はある？」
• 「このリポジトリをオープンソース化する前に、ライセンスの問題を確認して」
• 「古くなっているものすべての更新計画を作成して」

コマンドのリファレンス、ライセンスの互換性に関する詳細、誤検知への対処については、REFERENCE.mdを参照してください。 具体的な例については、EXAMPLES.mdを参照してください。