cve-verify

Name: cve-verify
Author: opendatahub-io

36stars74forks

How to install cve-verify?

opendatahub-io/ai-helpers/cve-verify

$npx -y skills add opendatahub-io/ai-helpers --skill cve-verify

Installs into the current project.

Summary

Use this skill to verify that a CVE fix actually resolved the vulnerability by scanning the compiled binary or updated manifests. Catches transitive dep overrides, replace directives, and lockfile conflicts. Writes result to autofix-output/cve-verify-result.json.

Files · 1

View on GitHub

SKILL.md

1	# Skill: CVE Verify
2
3	After a fix is applied by `/cve-fix-apply`, verify the CVE is actually resolved
4	by scanning the compiled output. Source-level scans can give false negatives
5	when transitive dependencies override the fixed version at build time.
6
7	## Step 1: Run the verify script
8
9	Run `scripts/verify.sh` which builds the binary (Go) or regenerates lockfiles
10	(Node.js) and re-scans for the CVE:
11
12	```bash
13	bash scripts/verify.sh "${REPO_DIR}" "${CVE_ID}" "${LANG}" "${TARGET_GO_VERSION:-}" "${BUILD_LOCATION:-.}"
14	```
15
16	The script:
17	- For Go: builds the binary and runs `govulncheck -mode binary` (gold standard).
18	Falls back to source scan if build fails.
19	- For Node.js: regenerates lockfile and runs `npm audit`
20	- For Python: re-runs `pip-audit`
21	- Writes structured result to `autofix-output/cve-verify-result.json`
22
23	## Step 2: Interpret the result
24
25	Read `autofix-output/cve-verify-result.json` and evaluate the `verdict` field.
26
27	\| Verdict \| Meaning \|
28	\|---------\|---------\|
29	\| `fixed` \| CVE no longer detected — safe to create PR \|
30	\| `still_present` \| CVE still detected after fix — do NOT create PR \|
31	\| `scan_failed` \| Verification scan could not run — manual review needed \|
32
33	Use judgment for edge cases:
34	- If `still_present`: the fix was insufficient. This can happen with transitive
35	dependency conflicts, Go replace directives overriding the fix, or lockfile
36	conflicts. Do NOT create a PR — add a Jira comment explaining the fix was
37	attempted but CVE persists, manual investigation is required.
38	- If `scan_failed`: check the `scan_output_summary` for the root cause. If the
39	build failed due to the fix itself (e.g., incompatible version), the fix
40	approach may need to change.
41
42	## Caller contract
43
44	The orchestrator reads `verdict`:
45	- `fixed` → push branch, create PR
46	- `still_present` → do NOT create PR, add Jira comment explaining fix was insufficient
47	- `scan_failed` → skip with documentation, manual review needed
48
49	## Gotchas
50
51	- Binary scan is the gold standard for Go; source scan can miss transitive dependency overrides that re-introduce the vulnerable version at build time
52	- A `still_present` verdict means do NOT create a PR — post a Jira comment instead explaining the fix was attempted but the CVE persists
53	- SCAN_TIMEOUT defaults to 300s; set it higher for repos with many main packages or slow build times

People who liked this also viewed

6 picks

Type

cve-verify

36stars74forks

View on GitHub

How to install cve-verify?

opendatahub-io/ai-helpers/cve-verify

$npx -y skills add opendatahub-io/ai-helpers --skill cve-verify

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill: CVE Verify
2
3	After a fix is applied by `/cve-fix-apply`, verify the CVE is actually resolved
4	by scanning the compiled output. Source-level scans can give false negatives
5	when transitive dependencies override the fixed version at build time.
6
7	## Step 1: Run the verify script
8
9	Run `scripts/verify.sh` which builds the binary (Go) or regenerates lockfiles
10	(Node.js) and re-scans for the CVE:
11
12	```bash
13	bash scripts/verify.sh "${REPO_DIR}" "${CVE_ID}" "${LANG}" "${TARGET_GO_VERSION:-}" "${BUILD_LOCATION:-.}"
14	```
15
16	The script:
17	- For Go: builds the binary and runs `govulncheck -mode binary` (gold standard).
18	Falls back to source scan if build fails.
19	- For Node.js: regenerates lockfile and runs `npm audit`
20	- For Python: re-runs `pip-audit`
21	- Writes structured result to `autofix-output/cve-verify-result.json`
22
23	## Step 2: Interpret the result
24
25	Read `autofix-output/cve-verify-result.json` and evaluate the `verdict` field.
26
27	\| Verdict \| Meaning \|
28	\|---------\|---------\|
29	\| `fixed` \| CVE no longer detected — safe to create PR \|
30	\| `still_present` \| CVE still detected after fix — do NOT create PR \|
31	\| `scan_failed` \| Verification scan could not run — manual review needed \|
32
33	Use judgment for edge cases:
34	- If `still_present`: the fix was insufficient. This can happen with transitive
35	dependency conflicts, Go replace directives overriding the fix, or lockfile
36	conflicts. Do NOT create a PR — add a Jira comment explaining the fix was
37	attempted but CVE persists, manual investigation is required.
38	- If `scan_failed`: check the `scan_output_summary` for the root cause. If the
39	build failed due to the fix itself (e.g., incompatible version), the fix
40	approach may need to change.
41
42	## Caller contract
43
44	The orchestrator reads `verdict`:
45	- `fixed` → push branch, create PR
46	- `still_present` → do NOT create PR, add Jira comment explaining fix was insufficient
47	- `scan_failed` → skip with documentation, manual review needed
48
49	## Gotchas
50
51	- Binary scan is the gold standard for Go; source scan can miss transitive dependency overrides that re-introduce the vulnerable version at build time
52	- A `still_present` verdict means do NOT create a PR — post a Jira comment instead explaining the fix was attempted but the CVE persists
53	- SCAN_TIMEOUT defaults to 300s; set it higher for repos with many main packages or slow build times

People who liked this also viewed

6 picks

Type