Skip to main content

Managing (Triaging) Vulnerabilities

Overview

Checkmarx One tracks specific vulnerability instances throughout your SDLC. This means that after the initial scan of a Project, if an identical vulnerability is detected again in a subsequent scan of your Project it is automatically marked as a Recurrent vulnerability.

Notice

For SAST vulnerabilities, a recurrent vulnerability instance is defined as a vulnerability with the identical Source Node and Sink Node as well as the identical Attack Vector elements. If even minor changes were introduced to any of these elements (even though the nature of the threat is the same), it will be treated as a separate vulnerability instance.

Each vulnerability instance has a Predicate associated with it, which is comprised of the following attributes: ‘state’, ‘severity’ and ‘notes’. After reviewing the results of a scan, you have the ability to triage the results and modify these predicates accordingly. If a subsequent scan discovers a vulnerability with the identical vulnerability instance, its status will be marked as a Recurrent, and any changes that have been made to the predicate (state, severity and comments) are applied to the result in the new scan. For example, if you marked a vulnerability as Urgent and it was identified again in a subsequent scan, it will automatically be marked again as Urgent.

Notice

Changes that are made to the predicate of a vulnerability instance are applied only to that Project. So, if the identical vulnerability instance is present in a different Project, the edited predicate won’t be applied to that instance of the vulnerability.

Changing the Result Predicate

The Severity and State can be changed and Notes can be added for results identified by any of the scanners.

The result predicate can be edited using the following methods:

Changes are implemented across the entire platform, so that a change made via API or IDE plugin will be reflected in the web application, as well as the reverse.

Warning

Only users with the Checkmarx One role update-result (e.g. a risk-manager) are authorized to make changes to the predicate. Only users with the role update-result-not-exploitable (e.g. an admin) are authorized to mark a vulnerability as Not Exploitable.

Changing States

There are five possible States that a vulnerability can have: To Verify, Not Exploitable, Proposed Not Exploitable, Confirmed or Urgent. All new vulnerabilities are initially marked as To Verify, meaning that the risk from this vulnerability has not yet been verified. During the onboarding process (and subsequent result reviews) you should assign the correct State to each vulnerability.

  • If you determine that a vulnerability is a false positive, then you should mark it as Not Exploitable. This will cause Checkmarx to stop showing this vulnerability in subsequent scans of this Project.

    Warning

    Only mark a vulnerability as Not Exploitable if you are certain that there is no potential risk from this item at any point in your product’s lifecycle. If it does not currently pose a risk but may cause a risk in the future then it should not be marked as Not Exploitable.

    For example, it may not pose a risk at this point because you are not yet in production, but in a production environment it will pose a risk. Or, it may not pose a risk because you are currently running on a local server but if in the future the app is deployed to the cloud it will pose a risk. In these cases do not mark the State as Not Exploitable, rather you should just lower the severity level or add a comment indicating that it doesn’t currently require mitigation.

    Warning

    Checkmarx does not consider adding validation steps to be a foolproof solution to AppSec vulnerabilities (because they leave the threatening input values in place, as opposed to sanitizers which replace the threatening input values). Therefore, we do not recommend marking a vulnerability as Not Exploitable on the basis of a validation step.

  • If you suspect that a vulnerability is a false positive but want to verify this further, then it should be marked as Proposed Not Exploitable.

  • If you determine that a vulnerability does in fact pose a risk which should be addressed at some point in the development process, then it should be marked as Confirmed.

  • If you determine that a vulnerability poses an acute risk which needs to be addressed immediately, then it should be marked as Urgent.

For detailed instructions on how to change a vulnerability state, please refer to ???.

Permissions

To change result states, a user needs to be assigned one of the following permissions:

  • update-result - Update all the result states except Not exploitable, update all severities, and add notes.

  • update-result-if-in-group - Update all the result states except not exploitable, update all severities, and add notes, only if a user is a member of a project group.

  • update-result-not-exploitable - Update the result state only to Not exploitable. Users can also update all severities, and add notes only when the vulnerability state is not exploitable.

  • update-result-not-exploitable-if-in-group - Update the result state only to Not exploitable. Users can also update all severities, and add notes, only when the vulnerability state is not exploitable, and only if a user is a member of a project group.

  • Update-result-states - Update all the result states except not exploitable.

  • Update-result-states-if-in-group - Update all the result states except not exploitable only if a user is a member of a project group.

  • Update-result-all-states - Update all the result states.

  • Update-result-state-not exploitable - Update the result state only to Not exploitable.

  • Update-result-state-not exploitable-if-in-group - Update the result state to Not exploitable only if the user is a member of a project group.

  • Update-result-state-propose-not-exploitable - Update the result state only to Propose not exploitable.

  • Update-result-state-propose-not-exploitable-if-in-group - Update the result state only to Propose not exploitable, and only if the user is a member of a project group.

Changing Severity Levels

Another method for triaging results is to adjust the Severity level. Checkmarx automatically assigns a Severity level to each new vulnerability, based on our assessment of the risk that it poses. Possible Severity levels are High, Medium, Low and Info. If you feel that in your circumstances a particular vulnerability poses a greater or lesser risk, then you can adjust the Severity level accordingly. Just like for State changes, recurrent vulnerabilities will automatically be assigned the Severity level that you specified for this vulnerability.

For detailed instructions on how to change a vulnerability severity, please refer to ???.

Permissions

To change result severities, a user needs to be assigned one of the following permissions:

  • update-result - Update all the result states except Not exploitable, update all severities, and add notes.

  • update-result-if-in-group - Update all the result states except not exploitable, update all severities, and add notes, only if a user is a member of a project group.

  • update-result-not-exploitable - Update the result state only to Not exploitable. Users can also update all severities, and add notes only when the vulnerability state is not exploitable.

  • update-result-not-exploitable-if-in-group - Update the result state only to Not exploitable. Users can also update all severities, and add notes, only when the vulnerability state is not exploitable, and only if a user is a member of a project group.

  • Update-result-severity - Update only the result severities.

  • Update-result-severity-if-in-group - Update the result severities only if a user is a member of a project group.

Adding Notes

If you would like to attach additional information to a vulnerability you can add it as a note. For example, this could be used to suggest mitigation strategies or to explain the rationale behind a change that you made to the state or severity. These notes will be available for future reference when viewing this scan. The notes will also be applied to this vulnerability in subsequent scans.

Permissions

To add notes, a user needs to be assigned one of the following permissions:

  • update-result - Update all the result states except Not exploitable, update all severities, and add notes.

  • update-result-if-in-group - Update all the result states except not exploitable, update all severities, and add notes, only if a user is a member of a project group.

  • add-notes - Add or edit notes.