Once a vulnerability has been created for an asset on a project, you can then update the vulnerability in a number of ways.
Considering updating vulnerabilities is part of the role for a pentester or assessor, 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 let you know once the vulnerability is ready to be retested.
Update Vulnerability
From the vulnerability page which you can access by drilling down from the project dashboard, you can use the page menu to select Edit Vulnerability.
Upload Evidence to Vulnerability
If you need to upload further evidence to a vulnerability, you can select Upload Evidence
Update/Review Vulnerabilities One-by-One
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 this option.
Bulk Overwrite Selected Fields Only
If you need to perform a bulk overwrite on selected fields across selected vulnerabilities - you can select this option.
Bulk Overwrite All Fields
If you need to perform a bulk overwrite on all fields across selected vulnerabilities - you can select this option.
!WARNING - this will overwrite all fields on every vulnerability you have selected. Use with caution.
Mark Vulnerability Ready for Retesting / Not Ready for Retesting
Once a vulnerability is ready for retesting, any user on the project can mark the vulnerability as Ready for Retesting from the vulnerability page menu.
The audit trail for the vulnerability will also be updated to reflect the change in status.
Any user can also mark the vulnerability as Not Ready for Retesting to set it back to Open status.
Add Remediation Note
As a vulnerability is in the process of remediation, project team members can update the vulnerability audit trail to include remediation notes. These notes are also synced with JIRA.
Mark Vulnerability as Closed / Re-Opened
During remediation testing, vulnerabilities can be Closed and Re-Opened depending on their status.
You can also bulk update status for vulnerabilities as follows:
Mark as Ready for Retesting
Mark as Not Ready for Retesting
Mark as Open
Mark as Closed
Bulk Add Tags
This feature will add new tags for each selected vulnerability if the tag does not already exist on the affected asset.
To customize an existing CVSS score for vulnerabilities on the project, include the following at the start in the tags:
CVSS:3.1
CVSSv3.1 Base Score:
CVSSv3.1 Temporal Score:
CVSSv3.1 Environmental Score:
CVSS:3.0
CVSSv3.0 Base Score:
CVSSv3.0 Temporal Score:
CVSSv3.0 Environmental Score:
Bulk Add ReportGen Fields/Tags
This feature will add new ReportGen tags for each selected vulnerability if the tag does not already exist on the affected asset.
To customize an existing tag - if the tag/name already exists on the affected asset, it will update its value to the new supplied value.
Update Affected Asset on a Vulnerability
You can update the affected asset for a vulnerability:
Or perform bulk update across multiple vulnerabilities:
Update SLA on Vulnerabilities
You can bulk-update SLAs on vulnerabilities to a new future date.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
This can also be performed on an individual vulnerability:
Re-apply SLAs on Vulnerabilities
You can bulk re-apply SLAs on vulnerabilities. This will remove the existing SLA on the vulnerability, and replace it with a new SLA from the SLA ruleset defined in Administration --> Configuration --> SLAs.
If no SLA exists on the vulnerability, a new SLA will be applied.
This option should be used for projects with a Manual SLA option set.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
This can also be performed on an individual vulnerability:
Remove SLA for Vulnerabilities
You can remove SLAs for vulnerabilities.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
This can also be performed on an individual vulnerability:
Duplicate Vulnerabilities
You can also duplicate vulnerabilities:
Delete Vulnerabilities
You can delete vulnerabilities individually:
Or you can bulk delete vulnerabilities:
Assign Vulnerabilities to Another Project
As an Admin user, 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 & evidence will also be relocated to the new project.