Verify fixes with reattacks

Request a reattack

When you have fixed your code or service configuration to address a reported vulnerability, you can request a reattack to validate the effectiveness of your effort. Reattacks are retests performed by Fluid Attacks’ tool and pentesters (the latter are available exclusively in the Advanced plan ).

Reattack requests can be sent from Fluid Attacks’ platform in the Vulnerabilities  and To do  sections. But you can also send them from VS Code  thanks to Fluid Attacks’ integration. This page is dedicated to sending reattack requests from the platform. These are the steps to do it from Vulnerabilities:

1. Go to the intended group ’s Vulnerabilities section and click on the weakness name.

   

2. Select the vulnerability to be verified by the reattack. Only entries with the ‘Vulnerable’ status and whose reattack status is neither ‘Requested’ nor ‘On hold ’ are eligible. Then click on the Reattack button.

   

1. In the pop-up window, provide a detailed description (minimum 10 characters) of the fix you implemented to address the vulnerability (if applies).

1. Click Confirm. The Reattack column for that vulnerability then displays the value ‘Requested’.

   

To request reattacks from the To do section, follow these steps:

1. Go to the To do section.

1. In Assigned vulnerabilities, select the vulnerability by its check box and click on Reattack.

1. Provide a justification (minimum 10 characters) in the pop-up window (if applies) and click Confirm.

After requesting the reattack you need to wait for the tool or pentesters to inform you of the outcome. If performed by the tool, the reattack may take several minutes. If performed by security analysts, the response time adheres to the conditions specified in the service-level agreement , i.e., a median of 16 office hours. Moreover, a new comment related to your request appears in the type of vulnerability’s Comments section. If applicable, a further comment  appears shortly after, where Fluid Attacks’ tool informs you of the reattack outcome. If security analysts are involved, they may add detailed comments along with the reattack outcome information.

Reattack outcomes

On the platform, there are two possible reattack outcomes which are informed in the Reattack column of the Vulnerabilities table .

1. Verified (vulnerable): The vulnerability is still exploitable. Fluid Attacks’ tool or pentesters provide evidence of the exploit, accessible in the Evidence section . You should attempt remediation again and then request another reattack.
2. Verified (safe): The vulnerability has been successfully remediated.

Reattack outcomes are recorded in the type of vulnerability’s Tracking  and Comments  sections.

Reattacks on hold

Reattacks might be temporarily delayed due to situations from your side, which Fluid Attacks calls “events.” To learn more about them, read Resolve events impeding tests . Delayed reattacks are shown in the Vulnerabilities table with the value ‘On hold’.

Once the events are resolved, the reattack request is automatically reactivated.

Reattacks for vulnerabilities detected by the automated tool

Bear in mind the following regarding reattacks for vulnerabilities detected by the automated tool:

1. No detailed justification is needed in your request as the tool does not take it into account. You are shown the following message instead.

1. If you suspect a false positive or determine the finding poses no risk due to other security measures, contact Fluid Attacks  or request the zero risk treatment , respectively, instead of a reattack.
2. The posts in Comments sections are simple messages mentioning vulnerabilities present and remediated resulting from the reattack.
3. If you have trouble remedying the vulnerability, consult the vulnerability  and fixes  documentation for code examples or use the Fluid Attacks features that leverage generative artificial intelligence  to have an idea of how to proceed.

Reattack a permanently accepted vulnerability

Despite having accepted a vulnerability permanently on Fluid Attacks’ platform, you can request a reattack if you determine you have remediated it.

The steps to request a reattack for a permanently accepted vulnerability are no different from those described above . After sending the request, the column Reattack shows the value ‘Requested’.

Error when requesting reattacks

Add new changes to your repository before requesting a new reattack

The platform prevents a reattack request if

1. the latest cloned version (last commit) of the repository associated with the vulnerability you are attempting to reattack is more than 1 day old,
2. the vulnerability is still present in that last commit (or even in a previous commit).

In such cases, the error message prompts you to update the repository before requesting the reattack.

These are the recommended steps when encountering this error:

1. Check the current version of the repository (in your remote version control system or remote container where the repository is hosted) and ensure the latest commit is recent and includes the fix.
2. Update the branch under evaluation (i.e., the one registered in the Scope section ) to include the current version of the repository.
3. Return to the platform and request the reattack  again.
4. If necessary, manually update the repository in Scope and request the reattack once its Status is OK.

You had already requested that reattack

If the reattack for the vulnerability has already been requested by you or your team and Fluid Attacks’ response is pending, the platform does not let you request it again. You can identify vulnerabilities for which this applies by looking for the ‘Requested’ value in the Reattack column.

You selected a vulnerability already marked as Safe

If the vulnerability is marked as ‘Safe’ in the Status column, that means it is no longer present in your system, therefore, it is no use to reattack that past detection.

You selected a vulnerability whose reattack is On hold

As explained above , the reattack for a vulnerability might be delayed due to some situation you must resolve first (fully explained in the Events section). The platform does not let you retry a reattack until after said delayed reattack has been effectuated and has found the vulnerability to be present still.

Your current subscription does not include reattacks for the selected vulnerability

Having downgraded to the Essential plan, you cannot request reattacks for vulnerabilities detected with penetration testing as a service, secure code review and reverse engineering (marked ‘PTAAS’, ‘SCR’ and ‘RE’ in the Technique column, respectively). You must upgrade back to the Advanced plan to request those reattacks.