Creating a Policy
The policy creation flow involves naming the policy, setting up rules for the policy, and assigning projects to it.
You can set up a general rule for all scanners or set up one or more rules for individual scanners. Additionally, to break software builds for a scanned repository that violates the configured rules, you can toggle on the Break the build upon violations option. This option is available for both the general rule for All scanners and for rules for Individual scanners.
If you set a rule for All scanners, specify policy violation conditions regardless of the scanner type by selecting which severities for detected vulnerabilities will trigger a policy violation. Upon a policy violation, the pull request will be updated with an indication of the policy name, the configured severities for Net new detected vulnerabilities, and whether the build was broken. Additionally, the same information will be displayed in the Incidents table.
If rules are set for Individual scanners, define rules for each policy that outline a custom compliance threshold. Each rule, in turn, will include one or more conditions that describe specific vulnerabilities associated with the policy. Options for configuring conditions differ according to the scanner for which the rule is being created. The possible types of conditions are described below.
Upon policy violation, the pull request will be updated with the configured scanners findings, specifying which vulnerabilities were detected for each configured rule. For additional information, refer to Code Repository Integration Usage & Results
 |
How to create a new policy
To create a policy:
In the main navigation, select Resource Management
> Policies.Click on Create New Policy.
In the Policy Details section, provide the following information:
Policy Name - Enter a name for the policy.
Description (optional) - Add a description.
Associated Tags (optional) - Click to expand the display, and then enter the desired tags for the policy.
Click Save & Continue
The screen expands to present the Rules and Project sections.
Rules section
Set up a single rule for all scanners or set up one or more rules for individual scanners.
To break software builds for a scanned repository that violates the configured rules, toggle on the Break the build upon violations option. This option is available for both the single rule for All scanners and for Individual rules.
All Scanners - Set up a rule for all scanners by selecting which severities for detected vulnerabilities will trigger a policy violation.
By Scanner - Set up a one or more rules for individual scanners.
Policies can be set for the following scanners:
SAST scanner - SAST Policy Conditions.
SCA scanner - SCA Policy Conditions.
IaC Security scanner - IaC Security Policy Conditions.
Container Security scanner - Policy Management - Container Security Conditions
To create an All Scanners rule:
Click on All Scanners.
Select the checkbox next to each severity level for which a newly identified vulnerability is considered a policy violation.
If violation of this policy will break the build, turn on the Break build toggle.
To add one or more By Scanner rules:
Select the By Scanner radio button.
Notice
If a policy has multiple rules, if any one rule is violated, then the policy is considered violated (OR operator).
Click on Select Scanner to open the dropdown menu, and select the scanner for which you would like to add a rule.
Click on + Add Rule.
The rule configuration panel opens on the right side of the screen.
In the Rule Name field, enter a name for the rule.
Click + Add Condition and configure the condition. Options for condition configuration differ according to the scanner for which the rule is being created. The configuration options for each scanner are described below.
Projects section
You can designate the policy you're creating as the default policy. This policy will then be applied to all scans of both new and existing projects. Alternatively, you can apply the policy to specific projects only.
To set the policy as the default policy, select the Default Policy checkbox. Note that only one default policy can be activated at a time.
To assign the policy to one or more specific projects:
Click + Assign to Projects.
The Select Projects to Assign panel opens on the right side of the screen.
Select the checkbox next to each project you would like to assign.
It is possible to search for projects using the Search field. You can also select the Select All in View option to select all currently loaded projects.
Click Assign Projects.
Click Save Policy.
The policy is created and activated.
Configuring Policy Conditions
Each By Scanner rule specifies one or more policy conditions that relate to a specific scanner. The options for defining conditions differ for each scanner. The following sections explain the options for configuring conditions for each type of scanner.
SAST Policy Conditions
A SAST rule consists of one or more conditions. A rule is considered violated only if all conditions are fulfilled (AND operator). However, each condition is assessed independently so that not all conditions need to be fulfilled in relation to a single entity for the rule to be violated.
For example, if you set one condition for 3 or more High severity vulnerabilities, and another condition for 2 or more New vulnerabilities. If there are 5 High severity vulnerabilities that are all Recurrent and also 3 New vulnerabilities that are all Low severity, the rule will nonetheless be considered violated.
Currently, only conditions that relate to vulnerabilities are supported for the SAST scanner.
The following table describes the elements used to create a SAST condition.
SAST Vulnerability Conditions
Rule Subject | Options | Operator | Value |
|---|---|---|---|
Severity |
| > >= <+ < = | Integer The number of vulnerabilities of the specified severity. |
Result Status |
| > >= <= < = | Integer The number of vulnerabilities in the specified status. |
Query Name | In Contains |
| |
Aging | > >= <= < = | Specify the age of the result, i.e., how long since the result was found for the first time (in days). | |
Categories | In Contains |
|
SCA Policy Conditions
The following sections describe the various types of SCA policy conditions that can be configured.
Package Conditions
Type | Description | Values specified |
|---|---|---|
Is Used | The rule applies only to packages that are being used in the project. TipAvailable only for projects that support the Exploitable Path feature. | none |
Is Outdated | The rule applies only to packages for which a more recent version is available. | none |
Named | The rule applies only to packages with the specified name. | Full name of the package. |
Name Contains | The rule applies only to packages that have the specified string in their name. | String that is contained in the package name. |
Version is Higher than | The rule applies only to packages with a version higher than the specified version. | The minimum allowed version number. If the current version number is below this value, it will violate the policy. |
Version is Lower than | The rule applies only to packages with a version lower than the specified version. | The maximum allowed version number. If the current version number is below this value, it will violate the policy. |
Is not a Dev dependency | The rule only applies to packages that aren’t Dev dependencies. | none |
Is not a Test dependency | The rule only applies to packages that aren’t Test dependencies. | none |
Is a Direct dependency | The rule only applies to Direct dependencies (not to Transitive dependencies). | none |
Vulnerability Conditions
Type | Description | Values specified |
|---|---|---|
has Exploitable Path | There is an Exploitable Path through which the vulnerable methods are actually used in your code. See Exploitable Path TipThis is only supported for Projects in which the Exploitable Path feature is activated. | none |
has a Remediation Recommendation | Checkmarx offers a remediation recommendation for eliminating the vulnerability from your Project. See Remediation Tasks Tab TipThis is only supported for Projects in which the Exploitable Path feature is activated. | none |
CVSS score is greater than or equal to | The CVSS score of the vulnerability is greater than or equal to the specified value. TipThe latest available CVSS version is used for this assessment. | Specify the minimum CVSS score for this condition. |
Severity level is | The vulnerability has the specified severity level. | Select one or more severity levels (Critical, High, Medium, Low, Info) for the vulnerabilities in this condition. |
CWE Category is | The vulnerability has the specified CWE. | Specify the number of the CWE. |
CVE ID is | The vulnerability has the specified CVE ID. | Specify a CVE ID, e.g., CVE-2019-2391. |
number of Days Since Publication is greater than | The number of days since the vulnerability was published is greater than the specified value. | Specify the maximum allowed number of days. If the current number of days is above this value, it will violate the policy. |
Suspected Malware Risk Conditions
Type | Description | Values specified |
|---|---|---|
Is Malicious | The rule only applies to Malicious packages. | none |
Severity level is | The rule only applies to a Suspected Malware risk with the specified severity level. | Select one or more severity levels (Critical, High, Medium, Low, Info) for the vulnerabilities in this condition. |
License Conditions
Type | Description | Values specified |
|---|---|---|
Named | Specify one or more specific licenses for this condition. | Select one or more licenses from the dropdown list of licenses in your account. |
License severity is | The Legal Risk has the specified severity level. | Select one or more severity levels (Critical, High, Medium, Low, Info) for this condition. |
IaC Security Policy Conditions
An IaC Security rule consists of one or more conditions. A rule is considered violated only if all conditions are fulfilled (AND operator). However, each condition is assessed independently so that not all conditions need to be fulfilled in relation to a single entity for the rule to be violated.
For example, if you set one condition for 3 or more High severity vulnerabilities, and another condition for 2 or more New vulnerabilities. If there are 5 High severity vulnerabilities that are all Recurrent and also 3 New vulnerabilities that are all Low severity, the rule will nonetheless be considered violated.
Currently, only conditions that relate to vulnerabilities are supported for the IaC Security scanner.
The following table describes the elements used to create an IaC Security condition.
IaC Security Vulnerability Conditions
Rule Subject | Options | Operator | Value |
|---|---|---|---|
Severity |
| > >= <= < = | Integer The number of vulnerabilities of the specified severity. |
Result Status |
| > >= <= < = | Integer The number of vulnerabilities in the specified status. |
Aging | > >= <= < = | Specify the age of the result, i.e., how long since the result was found for the first time (in days). |
Container Security Policy Conditions
Warning
This feature is not yet available in production environments.
Container Security rules are comprised of Conditions and Condition Groups.
Condition - A Condition is made up of a Property, a Condition and a Value that define which results fulfill this condition. For example, a condition with Property = "a Vulnerability", Condition = "Is" and Value = "Critical" will be fulfilled if at least one critical severity risk is identified in the scan.
For some conditions, it is possible to specify multiple values. In this case, an OR operator is applied between values. For example, if "Critical" and "High" are both specified, then either a critical or high severity vulnerability will fulfill the condition.
Condition Group - A Condition Group is a set of related conditions. All of the conditions in a single group must be fulfilled (an AND operator), and they must exist in relation to the same instance in order for the overall condition group to be considered fulfilled. So, in the previous example, if we would add a condition to the group with Property = "an Image Name", Condition = "Contains", and Value" = "production", then only a critical or high severity vulnerability in a "production" image would fulfill the group of conditions.
You can add multiple Condition Groups to a rule. In this case, all condition groups must be fulfilled (AND operator), but the conditions in each group do not need to apply to the same instance. So, in the previous example, if each condition was added as a separate group, then the rule would be violated if there was a critical or high severity vulnerability anywhere in the project, and it would also be violated if there was an image with a name containing "production" even if there were no risks in that image.
Image Conditions
Type | Operators | Values | Multiple values |
|---|---|---|---|
Image Name | is is not in not in contains does not contain starts with ends with | Free text |
|
Image Tag | is is not in not in contains does not contain starts with ends with | Free text |
|
Package Conditions
Property | Operators | Values | Multiple values |
|---|---|---|---|
Name | is is not in not in contains does not contain starts with ends with | Free text |
|
Version | is is not is greater than is less than is equal to | e.g, 1.2.3 |
|
Is Malicious | is | True / False |
|
Vulnerability Conditions
Property | Operators | Values | Multiple values |
|---|---|---|---|
CVE ID | is is not in not in contains does not contain starts with ends with | Free text following CVE ID format, e.g., CVE-2019-2391. |
|
Severity level | is is not in not in | Critical, High, Medium, Low, None |
|
State | is is not in not in | To Verify Not Exploitable Proposed Not Exploitable Confirmed Urgent |
|