How to interpret retest results

Last updated 2 months ago

Every retest ends with a clear result that automatically updates the vulnerability's status, so you always know where each finding stands.

Possible results

Fixed: the remediation was confirmed and the vulnerability is no longer exploitable.
Partially fixed: the fix reduces the issue, but doesn't eliminate it completely.
Not fixed: the vulnerability is still exploitable.
Blocked: the environment prevented the test — for example, the target wasn't reachable, the IP wasn't allowlisted, or the credentials were invalid.

👉 Each result comes with evidence explaining exactly what was found.

How results affect the vulnerability

Fixed moves the vulnerability to Fixed status and marks it as verified by Strike.
Any other result keeps it in Pending Fix, and you can request a new retest once the fix is adjusted or the environment is unblocked.
The most recent retest always defines the current status.

Retest evidence

Every completed retest includes:

A written analysis of what was tested and what was observed.
Attached evidence files you can download.

👉 The same quality standard applies whether the retest was run by the Retest Agent or by a Striker.

Retest history

The vulnerability detail view includes a Retest history section with every attempt in chronological order:

Date and who requested it.
The result of each retest.
A preview of the evidence and attached files, expandable to the full record.
If a retest is underway, it appears at the top as in progress.

👉 This gives you an auditable trail from detection to verified fix.