How a retest verifies a fix
Updated · By Rokkhe team
A Rokkhe retest checks one accepted finding after a fix. Someone proposes it from the finding page with the secure behaviour the fix should produce and up to twelve bypass attempts, and a second reviewer approves it before it runs as a governed scan. The engine replays the original proof and every bypass attempt, and Rokkhe records remediated, still vulnerable or inconclusive, so the finding closes on fresh evidence.
Why not close a finding when the fix merges?
A merged pull request shows that code changed, not that the issue is gone. Rokkhe proposes fixes as pull requests your team reviews and never merges them itself (/docs/remediation); a retest is how the fix is checked.
What goes into a retest request?
- The expected secure behaviour: what the fixed system should do instead.
- One to twelve bypass attempts, each distinct: the variations the fix also has to stop.
- A scan mode and a rationale for the reviewer.
When the retest is proposed, the finding's accepted proof is snapshotted and its SHA-256 digest recorded, so the retest answers the claim that was accepted rather than a later version of it.
Who approves it?
A second reviewer. The API refuses an approval from the person who proposed the retest, so retests run in team workspaces; a personal workspace has one member and cannot approve one. Proposing, approving and launching need the Owner, Admin, Security lead or Analyst role.
What happens when it runs?
The approved retest is queued as a governed scan of the original target, bound to an engagement and a signed execution profile. The engine replays the original proof and reports one outcome for every required bypass attempt (blocked, vulnerable or inconclusive), each with its evidence. The result is written once, with its own SHA-256, bound to the finding's digest.
How is the verdict decided?
| Verdict | Requires |
|---|---|
| remediated | The original proof and every bypass attempt were blocked. |
| still vulnerable | At least one replay or bypass attempt reproduced the issue. |
| inconclusive | At least one outcome could not be determined. |
The API refuses a verdict that contradicts its outcomes, and a result that omits or substitutes a required bypass attempt. A retest whose run fails or is stopped ends as failed or cancelled, with none of the three verdicts.
Which findings can be retested?
Dynamic findings that an independent validator accepted as reproduced (/learn/how-rokkhe-validates-a-finding), on a deployment in database mode. Governed runs analyse repository targets today. /docs/retests lists the API and every check.