Updating Vulnerabilities
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, 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.
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 Edit from actions menu.
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 Overwrite from actions menu.
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 ensure vulnerabilities are getting acknowledged by technical teams, and a plan for when those vulnerabilities are aiming to be fixed/addressed is captured.
The vulnerability will now track Target Remediation Date.
Once a vulnerability is ready for retesting, any user on the project can mark the vulnerability as Ready for Retesting from the vulnerability page.
The audit trail for the vulnerability will also be updated to reflect the change in status.
Project team members can update the vulnerability remediation history include remediation notes.
During remediation testing, vulnerabilities can be Closed and Re-Opened depending on the outcome.
This feature will add new tags for each selected vulnerability if the tag does not already exist.
This feature will add new custom tags for each selected vulnerability if the tag does not already exist. Otherwise if the custom tag already exists, it will update its value.
You can bulk-update SLA on vulnerabilities to a new future date.
!IMPORTANT: Only Admins and Project Coordinators are allowed to perform this operation.
You can 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 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.
You can remove SLA for vulnerabilities.
!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 2 of the same vulnerability. As the clone is a unique vulnerability, it will be treated as such from a dashboard/analytics/reporting perspective.
Linking vulnerabilities will make those 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.
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.
Last modified 5mo ago