Agent Skills: Skill: CVE Verify

>-

UncategorizedID: opendatahub-io/ai-helpers/cve-verify

Install this agent skill to your local

pnpm dlx add-skill https://github.com/opendatahub-io/ai-helpers/tree/HEAD/helpers/skills/cve-verify

Skill Files

Browse the full folder contents for cve-verify.

Download Skill

Loading file tree…

helpers/skills/cve-verify/SKILL.md

Skill Metadata

Name
cve-verify
Description
>-

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