Don't trust the fix. Re-run the exploit.
Validate Fix replays the exact exploit that proved a finding against your patched app, and only closes the finding once it no longer works.
How it works
Four steps from patch to proof
- 01
Ship the fix
Patch the code, merge the fix pull request Vulnix opened, or change the configuration. However you fix it.
- 02
Press Validate Fix
On the finding, start a narrowly scoped run against just that finding's asset. It is not a new pentest.
- 03
The exploit is replayed
The agent runs the exact exploit that proved the finding, in an isolated sandbox, against your patched app.
- 04
You get a verdict
Confirmed fixed closes the finding. Still vulnerable keeps it open, with the proof of why.
The verdict
Three answers, never a maybe dressed as a yes
Confirmed fixed
The original exploit no longer works. The finding is marked fixed, with the re-test on record.
Still vulnerable
The exploit still works against the patch. The finding stays open, so a fix that missed is never closed by accident.
Inconclusive
The target didn't answer in a way that settles it. You get the attempt back to try again, free.
Fix it in the code
From finding to fix pull request to proof
For a whitebox finding, Vulnix can open a GitHub pull request with the fix already applied. Merge it, then press Validate Fix to prove it worked against the running app.
- Fix pull requests for eligible whitebox findings, when you ask
- The agent's suggested fix for every finding
- The re-test recorded on the finding
Why it matters
Close findings with evidence
The same exploit, not a new guess
It replays what proved the finding in the first place, so the question it answers is exactly the one you have.
Narrow by design
Only that finding's asset is touched, so a check takes far less than a pentest and never uses one.
A real re-test, not a toggle
Marking a finding fixed is your word for it. Validate Fix is evidence you can show an auditor or a customer.