> For the complete documentation index, see [llms.txt](https://support.attackforge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.attackforge.com/app/getting-started/retesting.md). # Retesting & Remediation ## Overview AttackForge tracks the remediation history for all vulnerabilities - from `Open`, to `Retesting` & `Closed`. This helps to understand the status of a vulnerability - at any point in time - when you or the customer needs it. Every vulnerability has its own history which contains `Remediation Notes`, to help track what remediation actions were performed, when and by whom. AttackForge also tracks every `Round of Retesting` that has been requested or performed against the project to make the process simple & fast. ## Add Remediation Notes Any project team member can add remediation notes to a vulnerability. This can be used by engineering teams when updating the remediation actions performed on the vulnerability, or by pentesters when documenting observations during a retest. To view and create remediation notes, navigate to the vulnerability page and click on the `Remediation` icon on the right hand side.
To bulk add remediation notes, select the vulnerabilities and then click `Actions -> Add Remediation Note`.
## Remediation Plan If the `Remediation Plan` field is enabled (see Administration module), project team members can update the remediation plan for any of the vulnerabilities. This is useful to help get vulnerabilities acknowledged by technical teams, and plan for when those vulnerabilities will be fixed.
The vulnerability will now track `Target Remediation Date`.
You can use the `Target Remediation Date` to create `Custom Time-Based Emails` which automatically follow up on vulnerabilities for you.
## Assign Vulnerabilities for Retesting Any project team member can assign a vulnerability for retesting. This can be used by engineering teams indicating that a vulnerability has been resolved and can now be retested. You can assign a vulnerability for retesting by clicking on `Update Status -> Ready for Retesting` from the vulnerability page.
You will be prompted to enter an optional remediation note which is useful to help the security team understand what fixes have been put in place in order to indicate vulnerability is now ready for retesting.
You can view `Remediation History` by clicking on `Remediation` button on the vulnerability page.
You can also bulk assign vulnerabilities for retesting.
## Requesting a Retest
You can request a `Retesting Round` to be performed. To request a round of retesting, click on `Retesting` from the project menu, then click on `Request Retest`.
Select the test window when the retest can occur. Select the vulnerabilities you would like to include in this round of retesting. You can also add your own [Custom Fields](https://support.attackforge.com/app/getting-started/custom-fields-and-forms) to tailor your retest rounds to include the information you need. Click `Request Retest` when ready.
After submitting the request, you will receive a confirmation email. The administrators and anybody else configured will also be notified of your request. You will also see your request registered as a new round.
## Updating a Retest Round When the round is in the `Requested` status - the requestor can modify the details for the round by clicking on `Actions > Edit`. When the round is in the `Approved` status - only users with Edit access to the project can modify the round. When the round is in the `Completed` or `Cancelled` status - no modifications to the round is permitted.
## Approving a Retest Round Users with Edit access to the project can `Approve` the retest round. Approving a retest round signifies to the requestor that their request has been reviewed and accepted, and an email will be sent to the requestor to inform them of this. Once a round is approved - the requestor will no longer be able to edit the retest round. However, users with Edit access to the project will still be able to modify the round. This is ideal for use cases where the requestor fills in the minimal set of data - such as window and scope - and the security team then adjusts the fields, and adds their own custom fields such as assigned tester or notes - which then completes the entire data needed for the retest round. > **NOTE:** Approving a retest round is an optional step in the workflow.
## Performing a Retest Once a retest has been requested, the testers can commence the retesting. The vulnerabilities in-scope for the retest can be accessed from the `Retesting` section on the project.
Click on a vulnerability to bring up a list of in-scope vulnerabilities for the given round.
Perform your retesting for each vulnerability. Note you will need to have Edit permissions on the project in order to perform the retest. * **Check the Workspace** - get all the information and context you need to set up for the retest. * **View Remediation Notes** - to understand what steps have been taken to mitigate this vulnerability. * **Upload Evidence** - upload screenshots and proof of the findings/observations from the retest. * **Add Remediation Note** - add further remediation notes to include the findings/observations from the retest. * **Re-Open Vulnerability** - re-open the vulnerability if it is deemed to be not fixed. * **Close Vulnerability** - close the vulnerability if it is deemed to be fixed.
Once you have performed the retest for all the in-scope vulnerabilities, click on `Complete Round` from the actions menu for the round of retesting you are working on. An email notification will be sent to the project team to inform them that the retest is now completed. A record of the retested vulnerabilities will also be visible and also accessible in reports.
## Tracking Retesting You can track retesting history on a project by simply viewing the project dashboard page.
You can also see all your retest rounds on the project table:
## Cancelling a Retest Requestors and users with Edit access on the project can cancel a retest round if it is no longer required. Once a retest has been cancelled, no further actions can be taken for that round - however a new round can always be requested. All in-scope vulnerabilities for the cancelled round of retesting will be reset back to Open status. A remediation note will also be created to track the status change due to cancelled retest. You can cancel a retest by clicking on `Cancel Round` from the actions menu.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://support.attackforge.com/app/getting-started/retesting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.