Triaging SCA Results

Checkmarx SCA tracks specific risk instances throughout your software development lifecycle (SDLC). After reviewing the results of a scan, you can triage the results and modify these predicates accordingly. If the identical risk instance is identified in subsequent scans of the same project, the predicate will automatically be applied to that instance.

A risk instance is defined as a specific risk affecting a specific package in a specific project. Therefore, changes that you make to the predicate of a risk aren’t applied to the identical risk when it is found in a different project. Also, if the risk affects other packages in your project, the changes won’t be applied to those risks.

For Vulnerabilities and Suspected Malware risks each risk instance has a predicate associated with it, which is comprised of the State, Severity and Comments.

For Vulnerabilities, in addition to standard triage predicates, you can enrich your workflow by incorporating Vulnerability Exploitability eXchange (VEX) information to assess whether a vulnerability is actually exploitable in your product. SeeVulnerability Exploitability eXchange (VEX) for more details.

For Legal Risks, you can adjust the state of the related license, marking it as Effective or Not Effective. Learn about triaging legal risks below.

Triaging Risk State and Severity

A risk state is assigned to each risk instance in your Project. Initially, the state of each new risk is set as To Verify, indicating that it is a new finding that hasn’t yet been assessed by your AppSec team. The severity is determined primarily based on the CVSS score of the vulnerability. Your AppSec team can adjust the risk state to one of the following options:

Notice

The states mentioned above are pre-configured for all Checkmarx One accounts. In addition, you can create custom states in your account. Once they are created, you can assign those custom states to results.

Custom states is currently supported for SAST, SCA, IaC Security and Container Security results. It is not yet available for all tenant accounts. For more info, see Custom States.

• Not Exploitable - Select this state if your team has determined that this risk doesn’t pose a threat to your application (and isn’t expected to cause a risk at any time in the future).

  Note

  When a Risk is marked as Not Exploitable, in the All Risks page the CVE is marked with a strikethrough line, and the Risk Details page is grayed out. Also, Not Exploitable risks aren't counted in the risk summary counters.

• Proposed Not Exploitable - Select this state if your team has suggested tentatively that this risk doesn’t pose a threat to your application.

• Confirmed - Select this state if your team has confirmed that this risk does pose a threat and requires mitigation.

• Urgent - Select this state if your team has determined that this risk poses an imminent threat and requires urgent mitigation.

Based on your AppSec team's determination, the score can be adjusted to a score between 0.0 and 10.0 with the following severity breakdown:

• Critical - 9.0 to 10.0

• High - 7.0 to 8.9

• Medium - 4.0 to 6.9

• Low - 0.1 to 3.9

• Info - 0.0

Note

Only users with the permissions Update-result-severity or Update-result-severity-if-in-group can change the risk severity or score.

Guidelines for Triaging Risks

Before defining a new state for a Risk or package, it is important to ensure not only the security threat that the Risk currently poses but the threat that it may cause at any stage in your project’s development and deployment. On the other hand, it is sufficient to ensure that the presence of the Risk in this particular package and in this Project does not pose a threat, even if the Risk would pose a threat if it is identified in a different package and/or a different Project.

The following are some common reasons for changing the state of Risk or package:

• There is no exploitable path from your source code to the package that contains the Risk.

• The Risk doesn't affect the OS that you're running.

• You don't consider the threat to be severe enough to require remediation.

• Snoozing or muting a package will reduce noise in the system if there is no available fixed package version.

Vulnerability Exploitability eXchange (VEX)

Vulnerability Exploitability eXchange (VEX) enables you to triage vulnerabilities in open-source dependencies using a standardized, machine-readable format that communicates whether a known vulnerability, such as a CVE, actually affects your software. In many cases, a product may include a component that is technically vulnerable while the vulnerability itself is not exploitable within the specific product context. VEX allows vendors and stakeholders to clarify real exploitability status, reducing alert noise and improving risk prioritization.

After completing VEX triage, the associated information can be exported within SBOMs and other reports. Reports generated in XML, JSON, or CSV formats automatically include VEX data. In contrast, when exporting an SBOM, VEX information is not included unless explicitly selected during export. VEX is supported for CycloneDX SBOMs only; not supported for SPDX format. For more information on exporting VEX-compliant SBOMs, see Generating SBOM Report for a Project.

Notice

This capability complements existing triage workflows. All current triaging methods remain fully supported.

VEX Triage Model

Below are tables describing the various VEX fields that define the exploitability assessment:

Field	Required	Description
State	Yes	Defines exploitability status
Justification	Required when state = Not affected	Explains why vulnerability does not affect product
Response	Optional	Action to be taken (Cannot fix, Update, etc.)
Detail	Optional	Free-text notes

State Options

State	Description
Resolved	Vulnerability has been remediated.
Resolved with pedigree	Vulnerability has been remediated and evidence of the changes are provided in the affected components pedigree, containing verifiable commit history and/or diff(s).
Exploitable	Vulnerability may be directly or indirectly exploitable.
In triage	Vulnerability is being investigated.
False positive	Vulnerability is not specific to the component or service and was falsely identified or associated.
Not affected	Vulnerability does not affect the component or service.

Justification Options

Justification	Description
Code not present	Code has been removed.
Code not reachable	Vulnerable code is not invoked at runtime.
Requires configuration	Exploitability requires a configurable option to be set/unset.
Requires dependency	Exploitability requires a dependency that is not present.
Requires environment	Exploitability requires a certain environment that is not present.
Protected by compiler	Exploitability requires a compiler flag to be set/unset.
Protected at runtime	Exploits are prevented at runtime.
Protected at perimeter	Attacks are blocked at physical, logical, or network perimeter.
Protected by mitigating control	Preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.

How to Change the Risk State and Severity

Triaging a Single Risk

To change the risk state and severity:

1. On the Projects page, hover over the Results button for the desired project and select SCA.

2. On the Scan Results page, click on the Risks tab. The All Risks sub-tab is displayed.

3. Click on a risk to open the Risk Details page for that risk.

4. Click on the Edit button.

   The Management of Risk panel opens.

   Notice

   Alternatively, you can open the Management of Risk panel by clicking on the Comments button in the Customization section at the bottom of the Risk Details page.

5. To change the state, click on the State field, and select from the drop-down list the desired state.

6. To change the severity, either click on the Rating field and select from the drop-down list the desired severity or customize the severity score using the + / - buttons.

   Note

   Changing the severity score from the drop-down list will assign the lowest severity from that level (e.g., selecting Medium, the risk will be assigned a score of 4.0).

7. In the Leave a Comment Before Saving section, enter your comment. For example, you can add resources related to the vulnerability, assessment of exploitability in the context of your code, remediation steps, assignment of responsibility for remediation etc.

   Warning

   After changing the state, you are required to add a comment explaining the rationale behind the change before the option to Approve the change becomes available.

8. Click Approve.

Triaging Risks - Bulk Action

To bulk action triage risks:

1. Go to SCA results viewer > Risks tab > All Risks sub-tab.

2. Select the checkbox next to each risk you would like to include in the bulk action triage, and click Manage States.

   The Management of Risks panel opens.

3. Make changes to the State, Rating, and Make a Comment Before Saving.

4. Click Approve.

   The changes are applied to all of the selected risks.

How to perform VEX triage

1. Follow the below procedure for Triaging a Single Risk, until and including step 7.

   Triaging a Single Risk

   1. On the Projects page, hover over the Results button for the desired project and select SCA.

   2. On the Scan Results page, click on the Risks tab. The All Risks sub-tab is displayed.

   3. Click on a risk to open the Risk Details page for that risk.

   4. Click on the Edit button.

      The Management of Risk panel opens.

      Notice

      Alternatively, you can open the Management of Risk panel by clicking on the Comments button in the Customization section at the bottom of the Risk Details page.

   5. To change the state, click on the State field, and select from the drop-down list the desired state.

   6. To change the severity, either click on the Rating field and select from the drop-down list the desired severity or customize the severity score using the + / - buttons.

      Note

      Changing the severity score from the drop-down list will assign the lowest severity from that level (e.g., selecting Medium, the risk will be assigned a score of 4.0).

   7. In the Leave a Comment Before Saving section, enter your comment. For example, you can add resources related to the vulnerability, assessment of exploitability in the context of your code, remediation steps, assignment of responsibility for remediation etc.

      Warning

      After changing the state, you are required to add a comment explaining the rationale behind the change before the option to Approve the change becomes available.

2. In the Management of Risk panel, use the toggle to enable VEX options.

3. By default, VEX state is mapped from the risk state set in the regular triage workflow as follows:

   • If the risk state = To Verify, the VEX state will default to In triage.

   • If the risk state = Not Exploitable, the VEX state will default to Not affected.

   • If the risk state = Confirmed, the VEX state will default to Exploitable.

4. Configure the various VEX fields. When state is set to Not affected, the Justification field will appear to its right.

5. Click Approve.

Viewing Risk Change History

Once a change has been made, the new State and Severity are immediately shown in the web application. However, the risk summary counters aren't recalculated until a new scan or scan recalculation is run on the project. Until the recalculation, a red dot will be displayed for the risk indicating that recalculation is required.

State changes are shown in the All Risks table. Not Exploitable risks are marked with a strikethrough line.

In addition, a detailed history of all changes is shown in the History tab in the Management of Risk and Management of packagespanels. For each change that was made, the name of the user who made the change and the time of the change are shown. In addition, the new state and/or severity is shown alongside the previous state/severity.

Packages often have several different licenses associated with them. This gives users the option to choose which license to consider "effective" for that package, i.e., which set of license restrictions they would like to follow. As long as you are abiding by the terms of the effective license, the other licenses don't constitute a legal risk. Therefore, Checkmarx only considers a risky license as constituting a Legal Risk if it is marked as the Effective license for that package.

Initially, the state of most licenses is set as To Verify. However, when there is a sole license for a package and it was identified in a reliable source, that license is automatically marked as Effective. You can then review the licenses and mark each license as Effective or Not Effective based on your assessment of the package usage. Changing the state of a license is done via the Checkmarx One web application, on the Risk Details page.

Learn more about Legal Risks here.

Many SCA triage decisions need to be applied consistently across multiple projects. When the same package, vulnerability, malware risk, or license appears in more than one project, triaging each instance individually can be time-consuming and lead to inconsistent results. The Global Inventory provides cross-project triage, allowing you to locate an item once and apply a single triage action to all of its occurrences across the tenant. This applies to packages, associated vulnerabilities and malware risks, as well as licenses, enabling scalable and consistent SCA triage across all projects.

For example, if you decide that a particular package is not a concern, you can search for all instances of that package in the Packages tab and mark them all as Muted.

Use the procedure below to triage items across projects in the Global Inventory.: