Triaging SCA Results
Warning
The functionality described below is in the process of being rolled out. Some of these features may not yet be available in your account.
Management of Risks
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.
While viewing the Risk Details page for a specific risk, you can open a side panel by clicking on the Edit button on the header bar, with tabs for New Action (i.e., making changes to state and severity) and for viewing History of changes made.
 |
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:
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.
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).
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.
How to Change the Risk State and Severity
To change the risk state and severity:
On the Projects page, hover over the Results button for the desired project and select SCA.
On the Scan Results page, click on the Risks tab. The All Risks sub-tab is displayed.
Click on a risk to open the Risk Details page for that risk.
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.
To change the state, click on the State field, and select from the drop-down list the desired state.
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).
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.
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 Management of Packages panel > History tab. 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, for state changes, the new state is shown alongside the previous state.
 |
Management of Packages
Notice
In the past, we have experienced unexpected delays in releasing this feature. We now plan to make it available in the coming months.
You can reduce noise in you system when you feel that a certain package (in the SCA results viewer) does not pose a threat or where there is no available fixed version of the package. This is done by changing the State of the package as needed. By default all packages are assigned the state Monitored. You can change the state to Muted so that the vulnerabilities associated with that package won’t be shown as risks to your project. You can also “Snooze” a package so that it is muted for a fixed period of time after which it will automatically revert back to being a regular monitored package.
Notice
When the designated snooze period ends, an auto-scan (i.e., automatic scan recalculation) is triggered in order to update the project data and risk counters to include data for the package that has been returned to Monitored state.
While viewing the Package Details page for a specific package, you can open a side panel by clicking on the State button on the header bar, with tabs for New Action (i.e., making changes to the state) and for viewing History of changes made.
 |
Changing the Package State
The package state can be modified based on your AppSec team's decision whether to have the package affect the project score or have it muted permanently or temporarily (snoozed).
Monitored (default) - vulnerabilities are displayed based on the risk score.
Muted - vulnerabilities associated with the package will permanently not be shown as risks to your project.
Snoozed - vulnerabilities associated with the package will be muted temporarily. It is required to choose a date for the snooze to expire.
Important
Only users with the roles update-package-state-mute and update-package-state-mute-if-in-group can mute packages.
Important
Only users with the roles update-package-state-snooze and update-package-state-snooze-if-in-group can snooze packages.
To change the package state:
On the Projects page, hover over the Results button for the desired project and from the scanner drop-down click on SCA.
On the Scan Results page, click on the Packages tab. The All Packages sub-tab is displayed.
Click on a package to open the Package Details page for that package.
In the tab's header bar, click on the State button (showing the current state).
The Management of Packages panel opens.
Note
Alternatively, you can open the Management of Packages panel by clicking on the Comments button in the Customization section at the bottom of the Package Details page.
To change the state, click on the State Change field, and select from the drop-down list the desired state.
Note
After changing the state, you are required to add a comment before the option to Approve the change becomes available.
In the Add a Comment section, enter your comment.
Click Approve.
The new State is immediately shown in the web application. However, the package 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 package indicating that recalculation is required.
Viewing Package Change History
Once a State change has been made, a red dot is shown next to the relevant Package. This indicates that you need to run a scan recalculation in order to update all of the result counters to reflect the change.
State changes are shown in the Package Details page. Muted packages will have a pink background for the header bar with a muted icon and Snoozed packages will have a yellow background for the header bar with a snoozed icon.
 |
In addition, a detailed history of all changes is shown in the Management of Risk panel > History tab. 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, for state changes, the new state is shown alongside the previous state.
 |
Managing Legal Risks
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.