Skill: CVE Verify
After a fix is applied by /cve-fix-apply, verify the CVE is actually resolved
by scanning the compiled output. Source-level scans can give false negatives
when transitive dependencies override the fixed version at build time.
Step 1: Run the verify script
Run scripts/verify.sh which builds the binary (Go) or regenerates lockfiles
(Node.js) and re-scans for the CVE:
bash scripts/verify.sh "${REPO_DIR}" "${CVE_ID}" "${LANG}" "${TARGET_GO_VERSION:-}" "${BUILD_LOCATION:-.}"
The script:
- For Go: builds the binary and runs
govulncheck -mode binary(gold standard). Falls back to source scan if build fails. - For Node.js: regenerates lockfile and runs
npm audit - For Python: re-runs
pip-audit - Writes structured result to
autofix-output/cve-verify-result.json
Step 2: Interpret the result
Read autofix-output/cve-verify-result.json and evaluate the verdict field.
| Verdict | Meaning |
|---------|---------|
| fixed | CVE no longer detected — safe to create PR |
| still_present | CVE still detected after fix — do NOT create PR |
| scan_failed | Verification scan could not run — manual review needed |
Use judgment for edge cases:
- If
still_present: the fix was insufficient. This can happen with transitive dependency conflicts, Go replace directives overriding the fix, or lockfile conflicts. Do NOT create a PR — add a Jira comment explaining the fix was attempted but CVE persists, manual investigation is required. - If
scan_failed: check thescan_output_summaryfor the root cause. If the build failed due to the fix itself (e.g., incompatible version), the fix approach may need to change.
Caller contract
The orchestrator reads verdict:
fixed→ push branch, create PRstill_present→ do NOT create PR, add Jira comment explaining fix was insufficientscan_failed→ skip with documentation, manual review needed
Gotchas
- Binary scan is the gold standard for Go; source scan can miss transitive dependency overrides that re-introduce the vulnerable version at build time
- A
still_presentverdict means do NOT create a PR — post a Jira comment instead explaining the fix was attempted but the CVE persists - SCAN_TIMEOUT defaults to 300s; set it higher for repos with many main packages or slow build times