Retesting

The retesting feature allows security teams to validate that a vulnerability marked as fixed has been genuinely remediated, confirming that Ethiack's engine is no longer able to identify it.

What findings can be retested automatically

Findings from Continuous Adversarial Exposure Validation can be retested automatically through the portal, with two exceptions:

• Vulnerabilities that have been deprecated and are no longer supported cannot be auto-retested
• Leaked credentials vulnerabilities, due to their nature, cannot be retested automatically.

More complex findings, typically originating from pentests, cannot be retested automatically or triggered through the portal; these must be requested manually:

• If the finding was reported by a human hacker, the retest request should be submitted as a comment directed to that hacker.
• Findings discovered by our agent will eventually support automatic retesting, but this is not yet available. In the meantime, retest requests should be submitted as a comment to our support team.

Retesting flow

1. Mark the finding as fixed

A team member updates the finding's status to Fixed. Once this is done, a retest button appears next to the status indicator.

2. Trigger the retest

Clicking the retest button instructs Ethiack's engine to re-examine the asset and verify the fix. While the retest is in progress, the button displays a loading spinner to indicate the validation is underway.

3. Outcome

Once the engine completes the validation, one of two outcomes occurs:

• Remains Fixed: the vulnerability could not be found again, confirming successful remediation.
• Reverts to Triaged: the vulnerability was still identified, meaning the fix was not effective and further action is required.

What happens if no retest is requested

Requesting a retest is the fastest way to validate a fix, but it is not required: all findings are eventually retested by Ethiack's engine as part of its continuous testing cycle.

To keep continuous testing efficient, the engine relies on change detection: assets that have not changed since the previous run are not re-examined on every pass, since constantly retesting unchanged assets would add little value. Every few runs, however, the engine performs a full coverage pass over the entire attack surface, re-verifying every asset regardless of whether it has changed.

This recurring full coverage is what guarantees that every finding is eventually retested, with the same outcomes as an on-demand retest:

• If a finding marked as Fixed can no longer be identified, it remains Fixed.
• If the vulnerability is identified again, the finding reverts to Triaged, indicating that further action is required.

The one difference from the on-demand flow is that the retest button is not updated: it only reflects the status of on-demand retests. As long as a finding remains marked as Fixed, you can be confident it was validated as fixed. If you need immediate validation of a specific finding, request an on-demand retest as described above.