cve-verify

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 the scan_output_summary for 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 PR
• still_present → do NOT create PR, add Jira comment explaining fix was insufficient
• scan_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_present verdict 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