Home / Knowledge hub / Fix verification
Knowledge hub
Fix verification
Proving a fix works by repeating the original exploit against the new code.
What it means
Fix verification is the step after a fix is written. It checks that the original flaw is really gone. The strongest method is to repeat the exact exploit that proved the finding, against the new version of the application, and see it fail. If it still works, the fix did not work.
It is different from a fresh scan. A scan looks for known patterns and may miss the same flaw reached by a slightly different route. Repeating the original steps tests the specific thing that was broken, and a small variation of it, which is what an attacker would try next.
Why it matters
A closed ticket feels like safety, but a merged change proves only that code was written. Fixes that miss are common: the check is added to the web page but not the API, one route is protected and its twin is not, or a filter blocks one spelling of the input and not another. Verification catches them before an attacker does.
It also gives you something to show. An auditor asking how you know a critical finding is closed can be shown the original exploit failing against the new build. This is the principle behind a closed-loop retest and the content of a retest report.
How it shows up
In practice it means keeping the reproduction steps with the finding, running them against the fixed build, and recording the result. Run it in a test environment that matches production. Try the neighbouring cases too: other methods, other roles, other routes to the same data.
Common mistakes are verifying by reading the diff only, closing on the developer's word, and testing once on the happy path. Add the exploit as an automated test where possible, so a later change that brings the flaw back is caught as a regression.
Questions people ask
Fix verification, answered
Is fix verification the same as a rescan?
No. A rescan looks for known patterns across the whole app. Verification repeats the exact exploit for a specific finding and nearby variations.
Both are useful, but only verification proves that particular flaw is closed.
Who should verify a fix?
Ideally someone other than the developer who wrote it, using the original evidence. The tester who found the flaw is best placed, since they know the route.
Automated replay of the exploit can do the same job.
What if the exploit no longer works but the flaw remains?
That can happen if the fix blocks only the exact input. Test variations such as other encodings, methods and endpoints.
A good verification covers the cause, not just the one request.
Does verification need production access?
Not usually. A staging environment that matches production is safer and enough for most fixes.
Check the same configuration, because differences can hide or cause the flaw. Where production must be used, agree the safe steps first.
Can fix verification be part of CI?
Yes. Turning the exploit into an automated test lets the pipeline fail a build if the flaw returns.
This turns a one-time fix into lasting protection. The test then stays in place for every later build, at almost no cost.
Sources
Where this comes from
Related
Terms that sit next to this one
Closed-loop retest
Re-running the exact exploit after a fix, so the finding closes only on proof.
Retest
Running the test again to confirm that a reported flaw has really been fixed.
Retest report
A short report confirming which earlier findings are now closed and which remain.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Security regression test
An automated test that fails if a fixed vulnerability ever returns.
How do you know it is fixed?
A fix is proven by re-running the exact exploit against the new code, not by a fresh scan. That is how we close findings. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.