absolute-audit

最初の応答は🔒の絵文字で始めてください。

Absolute Audit

リポジトリ全体のセキュリティ上の問題、つまり脆弱な依存関係（CVE）や危険なコードパターンを見つけてトリアージし、修正に値するものを安全に修正します。生のスキャナー出力ではなく、重要度順に並べた検出結果の表と、項目ごとの修正方法を出力します。

references/health-engine.md の共有エンジンを実行します。検出 → スキャン → トリアージ → 修正 → 検証 → 報告のループと安全性に関する契約については、そちらをお読みください。このファイルでは、セキュリティ監査に固有の内容のみを扱います。

許可された防御目的での使用。 このコマンドは、ユーザー自身のリポジトリを監査して弱点を見つけ、修正するものです。システムへの攻撃や検出の回避ではなく、セキュリティ強化を目的としています。

---

使用するタイミング

• 「セキュリティ監査を実行して」「脆弱性はありますか？」「依存関係にCVEがないか確認して」。
• 使用しているものに影響するCVEが公表された後。
• main の定期的な健全性チェック。

組み込みの /security-review（ブランチの 保留中の差分 をレビュー）とは異なり、audit は依存関係も含めて コミット済みリポジトリ全体 をスキャンします。両者は互いを補完します。

---

スキャン対象

1. 依存関係の脆弱性（CVE） — 主な対象：

エコシステム	スキャナー
npm / pnpm / yarn	npm audit --json / pnpm audit --json / yarn npm audit --json
Python	pip-audit（推奨）または safety check
Go	govulncheck ./...
クロス言語	利用可能であれば、ロックファイルに対して osv-scanner

2. コードレベルのパターン — 高い確度で検出できる問題に限り、読み取り専用のgrep／静的解析を実施します。 ハードコードされたシークレット／キー／トークン、入力に対する eval／動的実行、文字列連結によるSQLの構築、機密性の高いルートでの認可チェックの欠落、TLS検証の無効化、安全でないデシリアライズ、過度に広いCORSを対象とします。設定済みの場合は、プロジェクトに既存のSAST／リンターのセキュリティルール（eslint-plugin-security、bandit、gosec）を優先してください。

漏えいが疑われるシークレットは報告しますが、シークレットの値は決して出力しないでください。path:line と種類を参照してください。

---

リスクの順位付け（トリアージ）

生のCVSSではなく、深刻度 × 悪用可能性 × 到達可能性に基づいて順位付けします。

深刻度	デフォルトの対応
クリティカル／高、到達可能、修正あり	すぐに修正（第1波）
中程度、到達可能	今回の作業で修正
低、またはアプリケーションコードから到達不能	報告し、通常は対応を保留
推移的依存関係のみで、直接のアップグレード経路なし	フラグを立て、妨げとなっている親依存関係を記載

各項目について、アプリケーションの実際のコードパスから到達可能かどうかを明記してください。未使用の推移的依存関係のブランチにあるCVEは、ホットパス上の中程度の脆弱性より優先度が低くなります。それぞれについて、修正済みバージョンまたは緩和策を記載してください。

---

修正と検証

• 依存関係のCVE → 脆弱性を解消できる最小限のバージョン変更で解決します。実際のバージョン更新の手順は、upgrade フローのエコシステム別ステップに委ねてください。パッチ適用済みのマイナーバージョンを優先し、それが唯一の修正方法である場合に限り、メジャーバージョンへの更新に進み、承認を必須にします。
• コードの問題 → 具体的な修正を適用します（クエリをパラメーター化する、シークレットを環境変数に移し、漏えいしたものにはローテーションのフラグを立てる、認可チェックを追加するなど）。各修正は、それぞれ小さな波として実施します。
• 各波の後にスキャナーを再実行します。検出結果が実際に解消され、テスト／ビルドも成功する必要があります。アラートを抑制または許可リストに登録して解決したことにしてはいけません。
• 有効なシークレットが漏えいしている場合は、ローテーションのフラグを立てます。コードから削除しても、漏えいした事実は取り消せません。

---

注意点

1. 監査疲れから一律に無視する。 スキャナーを黙らせるのではなく、到達可能性に基づいてトリアージしてください。
2. CVEを抑制して修正したことにする。 アドバイザリを許可リストに登録しても、脆弱性は残ります。
3. シークレットを出力する。 場所と種類のみを参照し、値を決して出力しないでください。
4. コードからシークレットを削除すれば安全とは限らない。 Gitの履歴に残り、漏えいしているため、ローテーションしてください。
5. 依存関係の確認で止める。 実際の問題の多くは依存関係ツリーではなくコード内にあります。両方のスキャンを実行してください。

---

関連コマンド

• /absolute upgrade — 脆弱な依存関係のバージョンを実際に更新します。
• /security-review（組み込み）— 併用すると、保留中の差分も確認できます。
• /absolute work — 修正に本格的なリファクタリング（認証フローの置き換えなど）が必要な場合に引き継ぎます。