Usually no. A working exploit is risky to hold, hard to scope and proves less than it seems. Offer safer evidence instead: the analysis result, a call path or its absence, configuration facts and, where needed, a harmless test in a non production copy. If an auditor insists, involve your security lead first.
What the auditor is really asking
"Prove it is not exploitable" is shorthand for "show me you looked". They want to see a method, a result and a date. They rarely want a live attack, and most are not equipped to receive one.
Why an exploit is a poor exhibit
- It proves a different thing. A failed exploit attempt shows one approach failed on one day. It does not show the flaw is absent.
- It creates risk. Exploit code in a shared folder or ticket is something you now have to protect.
- It may break things. Running attacks against a live system can cause outages or data effects nobody planned.
- It is hard to repeat. An auditor cannot easily rerun it, which weakens it as evidence.
Safer exhibits, in order of preference
- Analysis output. The reachability result for the pinned build, with tool version and date. The CISA minimum elements for VEX note that timestamps follow international standards, which is a hint that dates are part of the evidence.
- A call path or its absence. Either the path from an entry point to the vulnerable function, or a statement that none was found.
- Configuration facts. A feature flag setting, a disabled module, or a build option that removes the code. Show the config and the build output that reflects it.
- A harmless test. For example, a unit test that shows the vulnerable function is never invoked by your code, run in a non production copy.
- A VEX statement. A not affected status with a justification label, which the OpenVEX specification requires or, alternatively, an impact statement.
When a live test is justified
Sometimes a customer or regulator expects a penetration test result. That is a separate engagement with scope, rules of engagement and a report from a qualified tester. It is not something to improvise in an audit meeting.
If you do run a safe validation, write down what was tested, what was not, and the environment. Be precise about the limit of the result. The OpenVEX specification itself says a justification such as the attacker being unable to control the vulnerable code can be difficult to prove conclusively.
Wording for the meeting
Try this: "We do not keep exploit code. Here is the analysis for this build, the configuration that disables the module, and the test that shows the function is not called. We will re-run it at the next release."
That answer is calm, specific and repeatable. It also shows a process, which is what the audit is about.
Quick check
What if the auditor says they will not accept anything less than a demonstration?
Escalate to your security lead and agree a safe form, such as a controlled test in an isolated environment with a written scope.
Is a negative exploit test proof of safety?
No. It shows one attempt failed. Pair it with analysis and configuration evidence.
Safeguard's reachability analysis and evidence automation produce dated records you can hand over without holding exploit code. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
