脆弱性・暗号・秘密混入の深刻度は、自動スキャンの警告件数やベストプラクティス違反の有無でなく、「攻撃者が制御できる経路で実コードから到達するか」「その前提（鍵のエントロピー、入力の制御可否、ファイルの追跡状況）で実害が打ち消せるか」という一次情報で評価する。最適化するのは「実際に悪用可能かに基づく優先順位」、避けるのは「ツールの出力やルール違反をそのまま深刻度として鵜呑みにすること」。

判断基準

• 依存の audit に残る critical/high は、その CVE の攻撃経路に自コードが到達しうるかで実害を見る。到達不能や攻撃者制御不可なら、破壊的なダウングレードを急がず別対応に回す判断もある。
• 呼び出し到達解析（実コードからの到達有無を静的に分類するツール）が使えるなら、到達ありを最優先にし、import のみ・require のみは後回しにする。
• 暗号方式の理論的弱点は入力前提で打ち消せることがある。鍵が高エントロピー乱数ならオフライン総当たりは非現実的で即時脆弱性ではない。人手の低エントロピー値だと前提が崩れる、という分け方をする。
• 秘密情報の混入指摘は、対象がバージョン管理下にあるか・履歴に残るかを確認してから深刻度を決める。追跡対象外なら「ソースへの秘密混入」には当たらず過大評価になる。
• 自動スキャンやサブエージェントは深刻度を過大に出しがちなので、報告前に到達経路・スコープ・前提を一次情報で裏取りして補正する。

注意 実害が低くても、監査をクリーンに保つために対応する判断はありうる。その場合もリスクと必要性を分けて記録し、低リスクと無リスクを混同しない。

検証 指摘ごとに「攻撃者が制御できる入力からこの経路へ到達できるか」「前提を満たさないと成立しないか」を言語化し、裏取りできない深刻度は据え置きにする。

根拠（synthesize 元）

• 278 残存 CVE は攻撃者制御可能な経路かで実害を評価する
• 429 govulncheck の呼び出し到達解析で脆弱性をトリアージする
• 316 crypto-js の AES パスフレーズモードの弱点とリスク評価
• 430 秘密情報の所見は git 追跡状況を確認してから深刻度を判定する