Skip to main content

Policy Management

Overview

Policy Management is a mechanism to identify security risks across projects and scans.

Organizations often handle hundreds or even thousands of projects that undergo daily scans, with each project generating distinct scan results. To pinpoint projects with specific types of results, security engineers must manually review and prioritize findings.

By using policies, organizations can easily detect projects that violate their established security rules. For example, an organization may want to understand whether specific projects contain any high-severity findings from static code analysis or feature particular types of open-source packages, such as the recent log4j concerns.

Policy Management does not stop at identification alone; it enables organizations to develop automated responses for project violations, for example, to block a software build if it is violating a policy.

Once a scan is completed, the policies associated with the respective projects are assessed. These policies are then matched against the findings from the scan results.

Checkmarx One generates and maintains an incident report containing details of projects that violated policies during the scan. In upcoming versions, it will be possible to automate email notifications regarding these violations.

Permissions

To execute various actions in the Policy Management feature, a user needs to be assigned one of the following permissions:

  • create-policy-management - Create policies.

  • delete-policy-management - Delete policies.

  • manage-policy-management - Update, delete, create and view policies.

  • update-policy-management - Update policies.

  • view-policy-management - View policies.

Policy Configuration

This section explains how to create a policy to flag specific situations requiring attention. The policy creation flow involves naming the policy, setting up rules for the policy, and assigning projects to it.

Users can set up a single rule for all scanners or set up one or more rules for individual ones. Additionally, to break software builds for a scanned repository that violates the configured rules, users can 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.

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 condition sets 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.

Creating_a_New_Policy.gif

How to create a new policy

Creating a Policy

To create a policy, perform the following:

  1. In the main menu, select Scan Management Scan_Management.png > Policies.

  2. Click on Create New Policy.

  3. 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.

  4. Click Save & Continue

    Policy_Details.png

    The screen expands to present the Rules and Project sections.

Rules section

Note

This functionality might not yet be available in your production environment.

Set up a single rule for all scanners or set up one or more rules for individual ones.

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 or individual scanners.

    Policies can be set for the following scanners:

    Policy_Rules.png

Add one or more Rules, as follows:

  1. Click on Select Scanner to open the dropdown menu, and select the scanner for which you would like to add a rule.

    Image_455.png

  2. Click on + Add Rule.

    The rule configuration panel opens on the right side of the screen.

    Image_457.png

  3. In the Rule Name field, enter a name for the rule.

  4. 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

Assign the policy to one or more Projects as follows:

  1. Click + Assign to Projects.

    The Select Projects to Assign panel opens on the right side of the screen.

  2. 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.

    Image_462.png

  3. Click Assign Projects.

  4. Click Save Policy.

    The policy is created and activated.

Configuring Policy Conditions

Each policy rule consists of one or more conditions. Any condition violated in a rule will violate the whole rule, create an incident, and be logged in the Incidents tab under the main Policy Management page. When clarifying conditions for rules in Policy Management, select a Rule Definition - Severity, Result Status, or Additional Vulnerabilities - an Operator - =, <=, >=, In, Contains - and a Value. Each policy rule relates to results from a particular scanner. The possibilities for conditions differ for each scanner. The following sections explain the options for configuring conditions for each scanner.

SAST Policy Conditions
In the Add a SAST Rule pane, perform the following:

  1. In the Rule Definition section, click Select Entity and select the desired entity from the dropdown list. Currently, the only supported type is Vulnerability.

    Add_SAST_Rule.png

  2. Click + Add Condition to create a new condition to the rule.

  3. Configure the Rule Subject, Operator, and Value:

    • Rule Subject: 

      or

      or

      • Severity: Critical/High/Medium/Low/Info

      • Result Status: New/Recurrent

      • Additional Vulnerabilities:

        • Query Name: Selecting IN as an operator opens a funnel to choose your query, including its language and group (organized by severity level). Selecting Contains allows for a free-text search.

        • Aging: The age of the result. How long since the result was found for the first time (in days).

        • Categories: Selecting IN opens a selection tree listing security standards with vulnerability types as sub-categories. To fulfill the condition, select at least one of each.

    • Operator: > / >= / < / <= / =/ IN/ CONTAINS

    • Value: Numeric value

      Add_SAST_Rule2.png

    For example, if you configure the Rule Subject as "High" for the Entity Type "Vulnerability," with the Operator set to "greater than" (">"), and the Value as "2," any project containing 3 or more high-severity SAST vulnerabilities will violate the rule.

    It is possible to configure more than one rule.

    An AND relationship links entities and conditions. This means that all specified conditions must be met simultaneously for the associated entities to be considered.

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.

Tip

Available 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

Is Malicious

The rule only applies to packages that are identified as Malicious Supply Chain vulnerabilities.

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

Tip

This 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

Tip

This 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.

Tip

The 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 (High, Medium, Low) for the vulnerabilities in this condition.

CWE Category

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 minimum allowed number of days.

If the current number of days is below this value, it will violate the policy..

Supply Chain Risk Conditions

Type 

Description 

Values specified 

Severity level is

The vulnerability has the specified severity level.

Select one or more severity levels (High, Medium, Low) 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.

Legal Risk level is

The Legal Risk has the specified severity level.

Select one or more severity levels (High, Medium, Low) for this condition.

IaC Security Policy Conditions
In the Add an IaC Security Rule pane, perform the following:

  1. In the Rule Definition section, click on Select Entity, and and then select the desired entity from the dropdown list. Currently, the only supported type is Vulnerability.

    Add_IaC_Security_Rule.png

  2. Click + Add Condition

  3. Configure the following:

    • Rule Subject:

      • Severity - High/Medium/Low

        or

      • Result Status - New/Recurrent

    • Operator: > / >= / < / <= / =

    • Value: Numeric value

      Add_IaC_Security_Rule2.png

    Notice

    For example, if for Entity Type Vulnerability, you set the Rule Subject as High, Operator as ">", and Value as 2. Then a project with 3 or more High severity IaC Security vulnerabilities will be in violation of this rule.

    Note

    • It is possible to configure more than one rule.

    • Entities and conditions are linked by an AND relationship. This means that all specified conditions must be met simultaneously for the associated entities to be considered.

Viewing Policies and Incidents

After a policy is created and saved, two tables are presented.

  • Policies - Contains all the configured policies.

    When hovering on a policy, a three-dot icon appears on the right side. 

    It is possible to perform the following actions for each policy:

    • Edit the policy

    • Delete the policy

    • Pin the policy to the top of the table.

      Policies_More_Options.png

  • Incidents - Shows all of the incidents in which policies were violated. An incident for All scanners policy will present the net new vulnerabilities rule with the configured severities which violated the policy. For Individual scanners policy, the following information will be presented in the table: Policy name, rule name, scan ID, project name, branch name, policy tags, scan date.

In this section: