0x03Harden

CVE reachability burndown

Use this when a dependency scan returns more high and critical advisories than anyone can act on, and the work needs ordering by what is actually exploitable here rather than by score.

Done when

Every high and critical advisory is either fixed or carries evidence and a named owner.

Each finding ends in one of two states: removed and verified by a passing build, test run and rescan; or documented with the reachability evidence behind the decision and the person who accepted the residual risk. Nothing is left merely unexamined.

The cycle

  1. 01Resolve the dependency tree and match every version against current advisories.
  2. 02For each high or critical finding, establish reachability and whether the advisory’s preconditions hold here, and record the evidence.
  3. 03Order by exploitability, then remove the top item with the smallest credible change.
  4. 04Re-run build, tests and scan; keep the change only if all three pass, revert if not.
  5. 05Repeat until nothing reachable is unaddressed and every survivor has evidence and an owner.

repeat from 01 while the evidence improves

Why it holds

A severity score describes a vulnerability in the abstract. It says nothing about whether this project imports the affected module, reaches the affected function, or meets the preconditions the advisory names. Ordering by evidence spends the effort where the risk is, and re-verifying after each single change keeps the diff reviewable.

Prompt

Work only inside [authorized repository or project]. Resolve the full dependency tree, direct and transitive, and match every package version against current vulnerability advisories. If the dependency graph, the source, or the advisory feed is unavailable, say exactly what is missing and stop — do not estimate. For each high or critical advisory, answer three questions before changing anything. Does the project import the affected module? Does any execution path actually reach the affected code? Are the preconditions the advisory names present here? Record each answer with its evidence: a call path, a configuration value, a feature that is switched off. Order what remains by exploitability rather than by score alone — reachable and externally exposed first, reachable but internal next, unreachable last. Take the top item and make the smallest change that removes it: a patch bump, a version constraint, a pinned transitive dependency. One item per pass. After each change, re-run the build, the test suite, and the scan. Keep the change only if all three pass and no behaviour shifts. If any fail, revert it and reconsider the approach rather than layering a second change on an unverified one. Stop and ask before a major version bump, a change that alters public behaviour, anything that touches production, or accepting a risk instead of fixing it. Finish when no reachable high or critical advisory is left unaddressed, or when every remaining one carries written reachability evidence and a named owner who accepted it. Report the inventory you started from, the reachability evidence per finding, what you changed, what verification showed, and what risk is left standing and who owns it.

  • Local rulesclean
  • Trivyclean
  • Cisco AI Defense Skill Scannerclean

    1 informational

  • NVIDIA SkillSpectorclean

    score 0/100 · safe