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.
claude-code · codex
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.
/loop run the repo's static analyzer (semgrep, CodeQL, or whatever is already configured) with the security ruleset; take ONE finding — highest severity first — and fix it minimally, then re-run the analyzer to verify the finding is gone and run the test suite. Never suppress or downgrade a rule to make a finding disappear; anything that needs a design change gets flagged for human review instead. Continue until the analyzer reports zero findings at high severity — stop after 10 turns and propose the fixes as one PR.
/goal `gitleaks detect --no-git` reports zero findings — for each finding, tell me whether it looks like a real credential (flag it for rotation and replace it with an env var lookup) or a false positive (add it to the baseline with a comment); never print the secret value itself; stop after 8 turns
/goal In Supabase prod project udooysjajglluvuxkijp, replace each authenticated write <table> ALL policy on public.customers/orders/order items/quotes/quote items/products (currently USING + WITH CHECK both literally true) with an org/tenant-scoped USING + WITH CHECK, or drop the policy if the table is unused in RA. End state: get advisors(project id=udooysjajglluvuxkijp, type:security) returns 0 rls policy always true findings for those 6 tables. Or stop after 6 turns if the owning tenant column cannot be confirmed