Loop 056
The dependency-CVE burndown loop
A software-security workflow that ranks dependency CVEs by reachability and exposure, applies one bounded fix, and verifies the complete project before continuing.
Ready-to-use prompt
Copy the loop
Scan the dependencies of [authorized project or current repository] for known CVEs using current advisory sources. If you cannot access the dependency graph, repository, or current advisories, report the blocker and stop. For each high or critical finding, identify the affected direct or transitive dependency, determine whether the vulnerable code is reachable, and check whether the exploit conditions exist in this project. Rank findings by severity, reachability, exposure, and available remediation. Patch or upgrade the highest-risk reachable dependency using the smallest credible change. Run the build, tests, and security scan again. Keep the change only if verification passes and no unacceptable regression appears. Repeat until no exploitable high or critical CVE remains, or every remaining finding has an evidence-backed reachability assessment and an approved risk decision. Ask before major or breaking upgrades, production changes, or accepting risk. Finish with the CVE inventory, reachability evidence, fixes, verification results, and remaining risks.
Verify / stop
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.
Context and guidanceWhen to use it, steps, safety notes, and related loops
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 to run it
- 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.
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.