deps

依存関係のサプライチェーンセキュリティを強化します。プロジェクトの言語を検出し、すでに設定されている内容を自動検出して、そのエコシステムで不足している強化策のみを適用します。

0. 言語を検出してガイドを選択する

マニフェストからプロジェクトの言語を検出し、該当する強化ガイドに従います。

言語	検出対象	強化ガイド
JS/TS	package.json	以下の rules/*.md ファイル（バージョン固定・リリース隔離・Renovate・依存関係レビュー・パッケージランナー）
Python	pyproject.toml、requirements*.txt、setup.py	references/python.md（バージョン固定＋ハッシュ・pip-audit・Renovate/Dependabot・依存関係レビュー）
Go	go.mod	references/go.md（go mod verify・govulncheck・チェックサム DB・依存関係レビュー）
Rust	Cargo.toml	references/rust.md（Cargo.lock のコミット・cargo audit/cargo-deny・ソースポリシー・依存関係レビュー）

検出した言語に対応するガイドのみを読み込みます。一覧にない言語（例：Ruby → bundler-audit）の場合は、同じ方針（バージョン固定、脆弱性スキャン、更新の自動化、PR のゲート）を適用し、その言語の正式なサポートはまだ含まれていないことを明記します。

このファイルの残りの部分（ステップ 1～4）は JS/TS 向けの手順です。Python、Go、Rust の場合は、参照先のガイドに従ってから、ステップ 4 の共通の要約形式を使用します。

1. パッケージマネージャーを検出する

ロックファイルから、次の順にパッケージマネージャーを検出します：nub.lock、pnpm-lock.yaml、bun.lock/bun.lockb、yarn.lock、package-lock.json。ロックファイルがない場合は、ユーザーに確認します。

package.json の devEngines.packageManager または packageManager フィールドは、ロックファイルより優先されます。pnpm の場合は、packageManager より devEngines.packageManager を優先します。pnpm 11+ と pnpm/setup アクションは最初にこのフィールドを読み取り、pnpm は解決されたバージョンを pnpm-lock.yaml に記録します。範囲指定ではなく正確なバージョンを固定し、すべてのマシンと CI の実行で同じ pnpm が使われるようにします。セットアップ時に最新バージョンを解決（pnpm view pnpm version）し、{ "name": "pnpm", "version": "<latest>", "onFail": "download" } として記述します。ランタイムも同様です。.nvmrc や engines.node ではなく、devEngines.runtime で Node を宣言します（pnpm 10.14+ は Node をダウンロードし、そのチェックサムをロックファイルに記録します）。セットアップ時に解決した現在の LTS に固定します。pnpm runtime set node lts（pnpm 11.4+）でフィールドを記述し、保存された version が範囲ではなく正確なバージョンであることを確認します。pnpm を宣言するときに、このフィールドも記述します。従来の "packageManager": "pnpm@…" からの移行は推奨されますが、必須ではありません。宣言は 1 つにし、両方は記述しないでください。2 つのフィールドが一致しないプロジェクトでは、バージョン切り替えツールが処理を拒否します。Yarn では、Yarn が読み取る唯一のフィールドである packageManager が引き続き必要です。Nub は別のマネージャーのロックファイル上で互換モードで動作するため、pnpm-lock.yaml と並んで nub.lock がある場合は Nub を使用しています。ロックファイルだけで判断する前に、このフィールドを確認してください。

ルールファイルでは 2 つのプレースホルダーを使用します。<pm> を検出したマネージャーに、<pmx> をそのマネージャーの一時的なパッケージランナーに置き換えます。対応表は rules/package-runner.md を参照してください。

2. 既存の設定を検出する

強化策を適用する前に、既存の設定をスキャンします。

• renovate.json / .renovaterc / .renovaterc.json / package.json の renovate キー → Renovate は設定済み
• dependency-review を含む .github/workflows/*.{yml,yaml} → 依存関係レビューが存在
• ^ または ~ のプレフィックスが付いていない package.json の依存関係バージョン → バージョンは固定済み

チェックに合格しているルールはスキップしてください。 スキップした内容を最後に報告します。

3. ルールを適用する

各ルールファイルを読み、詳細な手順と設定テンプレートを確認します。

ルール	影響度	ファイル
リリース隔離	MEDIUM	rules/release-quarantine.md
バージョン固定	HIGH	rules/version-pinning.md
Renovate	MEDIUM	rules/renovate.md
依存関係レビュー	HIGH	rules/dependency-review.md
パッケージランナー	MEDIUM	rules/package-runner.md

4. 出力の概要

すべてのルールを処理した後、概要を表示します。

## Supply Chain Hardening Complete

### Applied
- [list of rules applied with brief description]

### Skipped (already configured)
- [list of rules skipped with reason]

### Manual Steps Required
- [any post-setup steps, e.g. "Run `<pm> exec husky` to reinitialise git hooks"]