how to verify a patch actually fixes the CVE

TL;DR

Never trust the version bump alone. Verify with three checks: the scanner is clean, the original vulnerable behavior no longer reproduces, and the vulnerable code path is actually gone from what you ship. Close the ticket only when all three pass.

how to verify a patch actually fixes the CVE

Use this when

• You just merged a security fix and need to prove it works
• A vulnerability ticket is ready to close and you want evidence, not hope
• An auditor or customer asks for proof of remediation
• Dependabot or your scanner still shows the alert after you patched

Not for

• Writing the patch or choosing the fixed version
• Building an exploit for a vulnerability (defensive verification only)
• Load or regression testing the patched release

Steps

1. Confirm the fixed version is what is actually running.

Check the lockfile, the container image, and the deployed artifact all carry the patched version. A bumped manifest with a stale image is the classic false finish.

Expected: lockfile, image digest, and running version all match the fixed version from the advisory.

2. Re-run the scanner.

Run the same scanner that found the issue, plus your lockfile audit. The alert should be gone or marked fixed.

Expected: clean scan output for that CVE. Save the report as your evidence.

3. Reproduce the original behavior on the fixed version.

Take the conditions from the advisory (the vulnerable input, the misconfigured path, the crafted request) and try them against the fixed build in a safe test environment. Nothing bad should happen.

Expected: the exploit condition fails safely, the app behaves normally.

4. Confirm the vulnerable code path is gone.

Grep the shipped artifact for the vulnerable function, config, or pattern named in the advisory. Sometimes the version bump pulls the fix but your code pins the old behavior through a workaround.

Expected: no trace of the vulnerable pattern in what ships.

5. Check nothing else broke.

Run the test suite and smoke-test the feature the patch touched. Security patches sometimes change behavior.

Expected: green tests, feature works as before.

6. Record the verification and close the ticket.

Note the fixed version, the scanner evidence, and the date. Then close the alert or ticket.

Expected: a ticket closed with evidence attached, not just closed.

Variant phrasings

How do I know my CVE fix worked

Scanner clean plus the vulnerable behavior no longer reproduces plus the code path confirmed gone. All three, not one.

Scanner still shows the alert after patching

Check the lockfile and the deployed image separately. Usually the code is fixed but the scanner is reading a stale manifest or a cached layer.

Proving remediation for an audit

The scanner report plus a dated note of the version check and the reproduction attempt is what auditors accept. Keep all three.

Why it happens

Patches fail silently more often than people expect: wrong lockfile regenerated, cached image layers, vendored copies of the library, or the fix landing in a dependency your code overrides. The version number in the manifest is a claim, not proof, which is why verification is its own step.

Edge cases

• Patch exists but breaks your app: if the fixed version changes behavior you depend on, you need the mitigation path instead of the patch. Document it and verify the mitigation instead.
• Advisory says fixed but scanner disagrees: trust the code-path check over either. Read the actual diff of the fix and confirm your build includes it.
• Multiple services share the fix: verify each deployment, not just the library. One stale deploy keeps you exposed.
• No proof-of-concept available for the CVE: fall back to the code-path check and the scanner. You cant reproduce what nobody published, so document that limit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jFl4EcFKkss9sQHmeFCBDw