To prove a patch fixed a vulnerability, confirm the fixed version is what actually runs in production, reproduce the unsafe behavior safely on the old build, show it no longer occurs on the new build, rescan, and store the results with the change record. A bumped version in a manifest alone is not evidence.
Four things to prove
- The fixed version is deployed. Not just committed. The artifact running in production contains it.
- The vulnerable code path is gone or unreachable. The fix applies to the way you use the package.
- The unsafe behavior no longer occurs. You tried it and it fails safely.
- The scanner agrees. The finding closes for the right reason.
Step by step
Confirm what runs. Read the version from the running system, not the repository. Use the SBOM of the deployed artifact, a package listing from inside the container, or a version endpoint. Compare it with the advisory's fixed version. Watch for shadowed copies: a second version of the same package pulled in by another dependency can keep the vulnerable code in your build even after you bumped the direct one.
Reproduce on the old build. In an isolated environment with fake data, run a minimal request or input that triggers the weakness, based on the advisory description. You are not building an exploit for use elsewhere. You are creating a safe test case. Keep it small and do not run it against systems you do not own.
Run the same test on the new build. Expect a rejection, a sanitized output or an error. Save both results side by side.
Add it as a regression test. If the case is cheap to run, commit it so a future downgrade or override trips a test. See security regression testing.
Rescan. Run your dependency scan against the deployed artifact. The finding should disappear because the package version changed, not because someone suppressed it. If it persists, check for a second copy or an unfixed branch of the advisory.
When you cannot reproduce
Some advisories describe conditions that are hard to trigger, or depend on configuration. In that case record the reason, check the diff of the fix against your usage, and rely on the version evidence. Say clearly that you verified the version and not the behavior. That honesty is better than a claim you cannot support.
Reachability matters here too. If your code never calls the vulnerable function, the patch still improves hygiene, but your reproduction attempt may show the path was never open. Record that.
What to store as evidence
| Item | Example |
|---|---|
| Advisory reference | Identifier and fixed version range |
| Before and after versions | From the deployed SBOM |
| Reproduction result | Request and response, old and new |
| Scan result | Finding closed, with date |
| Rollout record | Who deployed, when, which environment |
Auditors and customers asking about patching usually want this chain. For wider evidence practice, see build an attestation evidence index.
Safeguard's exploitability and reachability analysis helps you decide whether a vulnerable function is called, and its compliance and evidence automation can keep the scan and rollout records together. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the check separates a package that is present from a vulnerable function that is actually reachable.
Quick check
Is a clean scan enough proof?
It is part of the proof. Pair it with the deployed version and, where possible, a before and after test of the unsafe behavior.
Can I run an exploit against production to prove it?
No. Reproduce in an isolated environment you own, with fake data. Testing against production risks harm and is rarely needed.
Last reviewed: 19 October 2026.
