A vulnerability is not fixed until someone has checked the fix. Developers are confident, but partial fixes, fixes in the wrong environment and regressions are common. Retesting closes the loop.

How it works

After a fix is deployed, the same test that found the vulnerability is run again against the live application. If it no longer triggers, the finding can be closed with confidence. If it still triggers, it goes back to the developer with fresh evidence.

Why it matters

• Confirms that fixes actually work in the deployed environment.
• Gives auditors proof of remediation.
• Avoids waiting for the next full scan to find out.

Best practices

• Retest every High and Critical finding after its fix.
• Keep the retest result with the original finding.
• Retest in the same environment where the issue was found.
• Run a full rescan periodically to catch regressions.

How Vooki Pro helps

• One-click retest runs the same detector that raised the finding against the live application.
• Clear verdicts: Still Vulnerable, Fixed, or Needs Manual Review, with the fresh response attached.
• The retest result stays with the finding and appears in reports.
• Retest from the command line with vooki-pro-cli retest.

Frequently asked questions

Why retest instead of rescanning?

A retest checks just the fixed issue in seconds, while a full rescan takes longer and covers much more.

What if a retest is inconclusive?

Check it manually using the reproduction steps and the fresh response.

Related: Scanning applications behind a WAF or rate limits · Compliance reporting from DAST results