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 State can be changed and Notes can be added for results identified by any of the scanners. The Severity can only be changed for SAST and IaC Security vulnerabilities.

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.

Warning

For SCA vulnerabilities, State changes can only be made on the most recent scan of the project. If the project has multiple branches, the change must be made on the branch that was scanned most recently.

Changing the State

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 Triaging a Single Vulnerability.

Changing the Severity Level

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 Triaging a Single Vulnerability.

Adding Comments

If you would like to attach additional information to a vulnerability you can add it as a comment. 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 comments will be available for future reference when viewing this scan. The comments will also be applied to this vulnerability in subsequent scans.

In this section: