Updating Vulnerabilities
Last updated
Last updated
Check YouTube for more tutorials: https://youtube.com/@attackforge
Once a vulnerability has been created, you can then update the vulnerability in a number of ways.
Considering updating vulnerabilities is part of the role for a pentester, only users with Edit access to the project can perform this function.
However, any project team member can add remediation notes & mark a vulnerability as Ready For Retesting. This allows customers, developers & engineers to track remediation performed for a given issue, and inform once the vulnerability is ready to be retested.
From the vulnerability page, click on Edit.
If you need to upload further evidence to a vulnerability, you can upload it from the Evidence section.
Review Notes in AttackForge can be created against Vulnerabilities and Project Executive Summary.
Review notes help teams keep track of the changes needed, and all communication in one place.
You must have Edit permissions on the project to view and create review notes.
If you need to perform QA on multiple vulnerabilities, or would like to review each vulnerability one-by-one (from one screen) - you can select the vulnerabilities then click on Actions -> Edit.
Here you can review and update each vulnerability individually, and cycle through each vulnerability as needed.
If you need to perform a bulk overwrite on selected fields across many vulnerabilities - you can select the vulnerabilities then click on Actions -> Overwrite .
You can opt into each field you would like to update, at one time for all selected vulnerabilities.
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.
Once a vulnerability is ready for retesting, any user on the project can mark the vulnerability as Ready for Retesting from the vulnerability page or using bulk actions.
The audit trail for the vulnerability will also get updated to reflect the change in status.
Project team members can update the vulnerability remediation history and create remediation notes.
During remediation testing, vulnerabilities can be Closed and Re-Opened depending on the outcome.
You can bulk add new tags for each selected vulnerability if the tag does not already exist.
You can bulk add new custom tags for each selected vulnerability if the custom tag does not already exist. Otherwise if the custom tag already exists, it will update its value.
You can bulk-update Remediation SLA on vulnerabilities to a new future date.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
You can re-apply the Remediation SLA on vulnerabilities. This will remove the existing SLA, and replace it with a new SLA from the SLA ruleset defined in Administration module.
If no SLA exists on the vulnerability, a new SLA will be applied.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
Duplicating vulnerabilities will clone a vulnerability. This means you will end up with two (2) of the same vulnerability. As the clone is a unique vulnerability, it will be treated as such from a dashboard/analytics/reporting perspective.
Vulnerabilities in AttackForge get created on projects. A vulnerability is linked to either one or more projects.
With the exception of Administrators, a user can only see vulnerabilities for which they have access to the project(s) linked to those vulnerabilities.
Linking vulnerabilities will make vulnerabilities available on other projects. Users on the linked projects will have view and edit access to the linked vulnerabilities, depending on their access level on the linked projects.
Linking vulnerabilities is useful when consolidating vulnerabilities into projects for remediation or tracking.
!IMPORTANT: When linking vulnerabilities, keep in mind: - Vulnerabilities are not transferred. Vulnerabilities will become available on the new project, and will also remain available in the current project. You can link a vulnerability to many projects. - Vulnerabilities are not copied. This means there will be no duplication of vulnerabilities in your dashboards, analytics, tables, etc. - Vulnerabilities are universal. Any changes to these vulnerabilities in either project will universally apply. - Assets assigned to each vulnerability will be added to the new projects' scope.
If a user deletes a linked vulnerability, it will only be deleted from its project. It will not be deleted on other linked projects for that vulnerability.
You can re-assign a vulnerability to another project. Once a vulnerability is re-assigned, it will no longer be available on the current project. All remediation notes, review notes & evidence will also be relocated to the new project.
