Retests

Verify a fix by replaying an accepted finding's proof and its bypass attempts, once a second reviewer approves.

A retest re-checks one accepted finding after a fix. It replays the finding's original proof and every bypass attempt you list, then ends with one verdict: remediated, still vulnerable or inconclusive. The finding's proof is frozen when the retest is proposed, so the verdict answers the same claim the finding made.

#What can be retested?

• Findings an independent validator accepted as reproduced. Those come from governed runs; /learn/how-rokkhe-validates-a-finding explains the validation.
• Dynamic findings. Known-CVE dependency findings cannot be retested this way.
• Deployments in database mode. In local file mode the finding page says retests are unavailable.
• Team workspaces. A retest needs a second reviewer, and a personal workspace has one member; there, rescan the repository instead.

#How does a retest run?

1. Propose — from the finding page, give the expected secure behaviour (what the fixed system should do), one to twelve bypass attempts, a scan mode and a rationale. The finding's proof is snapshotted with its SHA-256 digest.
2. Approve — a second reviewer approves it. The API refuses an approval from the person who proposed it.
3. Launch — the approved retest is queued as a governed scan of the original target, bound to an engagement and a signed execution profile. The launch takes an idempotency key and is not retried.
4. Verdict — the engine replays the original proof, reports one outcome for every required bypass attempt, and records the verdict with its evidence.

#What does each verdict mean?

A retest whose run fails or is stopped ends as failed or cancelled, with none of the three verdicts.

#What does the API check?

• The verdict matches the outcomes: remediated is refused if anything was not blocked, still vulnerable without a reproduction, and inconclusive without an inconclusive outcome.
• Every required bypass attempt has exactly one outcome with evidence. None may be omitted or substituted.
• The result is bound to the frozen finding digest and carries its own SHA-256, so an altered result is refused.

#Who can run one?

Proposing, approving and launching need a role that runs security workflows: Owner, Admin, Security lead or Analyst. Viewers see retest state without the controls.

#API