Burn down CVEs by reachability
Rank dependency CVEs by reachability and exposure, apply one bounded fix, and verify the whole project before moving on.
Use this when
Use this when dependency scans report high or critical CVEs and remediation should reflect whether vulnerable code is actually reachable in the project.
How it runs
- Scan current dependencies and advisories, then map each high or critical CVE to reachable project code and exploit conditions.
- Rank findings by severity, reachability, exposure, and the safety of available remediation.
- Fix the highest-risk reachable finding with one bounded patch or upgrade, then rerun the build, tests, and scan.
- Repeat until reachable risk is removed or every remaining finding has evidence and an approved decision.
Done when
✓ No exploitable high or critical dependency CVE remains without an explicit decision. Current scans, code-path evidence, the passing build and tests, and approved risk decisions account for every high or critical finding.
Why it works
CVSS alone does not show whether a vulnerable path is used or exposed in a specific project. Reachability and regression checks focus effort on real risk while keeping dependency changes reviewable.
Implementation note
Use current primary advisory sources. Do not silence findings, accept risk, make production changes, or perform a major or breaking upgrade without explicit approval.
More security loops
Weekly dependency vulnerability audit
Every Monday morning, run the dependency vulnerability audit, open one PR fixing what auto-fix can handle safely, and file issues for the rest.
Keep security audits running until clear
Run Claude repeatedly across turns until your security audit condition is met, then stop.
Secrets scan until clean
Run a secrets scanner over the working tree and drive the findings to zero: real secrets get flagged for rotation, false positives get baselined.