Creating Xray Policies and Rules

Triggering Violations Using Policy Rules

Policies contain user-defined rules allowing you to trigger violations for specific vulnerability or license breaches by setting a license or security criteria, with a corresponding set of automatic actions according to your needs.Rules are processed according to the ascending order in which they are placed in the Rules list on the Policy. If a rule is met, the subsequent rules in the list will not be applied.

Xray supports the following policy types:

Security Rules

A Security Rule allows you to create a set of rules around security vulnerabilities. There are two possible criteria:

1. Minimal Severity(Minor, Major, Critical, All): The minimal security vulnerability severity as it is in the JFrog vulnerabilities database. If the artifact or build contains a vulnerability with the selected severity or higher, the rule will meet the criteria, the automatic actions will be executed, and the policy will stop processing.

2. CVSS Score(1-10): The CVSS score range to apply to the rule. This is used for a fine-grained control, rather than using the predefined severities.The score range is based on CVSS v3 scoring, and CVSS v2 score is CVSS v3 score is not available.

3. Generate violations only when fixed versions are available: Xray will not generate violations for issues that do not contain a fixed version. If a fixed version is available later, the violation will be generated.

License Rules

许可规则允许你to create a set of rules around license compliance. There are three possible criteria:

• Allowed Licenses: Specifies an Allow List of OSS licenses thatmaybe attached to a component. If a component has an OSS license outside the specified Allow List, The rule will meet the criteria, a violation will be generated, automatic actions will be executed, and the policy will stop processing.

• Banned Licenses: Specifies a Block List of OSS licenses thatmay notbe attached to a component. If a component has any of the OSS licenses specified, The rule will meet the criteria, a violation will be generated, automatic actions will be executed, and the policy will stop processing.

• 不允许未知的许可证: Specifies the wanted behavior for components whose license cannot be determined. A violation will be triggered if a component with unknown license is found.

Policy Violation Automatic Actions

An action determines the automatic response to a detected Policy violation. You can define one or more action within each Policy Rule. Actions include the following:

• Generate Violation (Minor, Major, Critical): The severity of the violations that is generated if the criteria is met.

• Notify Email:This action lets you specify email addresses to which Xray should send an email message about a violation when one is triggered. For this to work, you need to have a mail server configured in Xray.

• Notify Watch's Recipients:This action lets you send an email to all the watch recipients about a violation when triggered.

• Notify Deployer:This action lets you send an email to the user that deployed the component about a violation when triggered.

• Create Jira Ticket: This action enables the Jira ticket creation in the Policy rules

• Trigger Webhook:This action lets you specify webhooks you have configured in Xray that should be invoked when a violation is triggered (See payload below).

• Block Download:This action lets you specify that artifacts should be blocked for download and allows you to select one of these options:

  • Block Download: When set, Artifactory will block download of artifacts that meet the Artifact Filter and Severity Filter specifications for this watch.
  • Block Unscanned: When set, Artifactory will block download of artifacts that meet the Artifact Filter specifications for this watch, but have not been scanned yet or the Xray data has been removed due to a retention policy. For more information on Xray Data Retention, seeIndexing Xray Resources.
• Block Release Bundle distribution:This action lets you specify that Release Bundles should be blocked for download if they meet the policy criteria rule.

• Fail Build:This action lets you specify that if a CI server requests a build to be scanned, and the Watch triggers a violation, Xray will respond with an indication that the build job should fail.
  This action is only available if the Watch is defined with Builds as target type.

  • Grace Period: There are many cases where you do not want to fail the first build, for example, some violations are not showstoppers, and you would like to look into them later without stopping the build creation. You can set a grace period for a number of days that you define according to your needs. During the grace period you define, the build will not fail and all violations are ignored during this period. An automaticIgnore Ruleis created for the grace period with the following criteria:
    • On the specific vulnerability/license
    • On the specific component
    • On any version of the specific build
    • On the specific Policy
    • On the specific Watch

    Once the grace period ends, the Ignore Rule is deleted, and if the build contains violations, those violations are created and the build will fail.
    

Creating a Policy

Step 1 Setting the General Policy Settings

1. In theAdministrationmodule, selectWatches& Policiesand from thePoliciestab clickNew Policy.

   JFrog Cloud New Interface (Beta)

   Go to Xray, and selectWatches & Policies. To learn more, clickhere.

2. Select the policy rule type and configure the rule.

   • Security: Lets you create a set of rules around security vulnerabilities. Choose how you want Xray to respond to each vulnerability severity.

   • License: Lets you create a set of rules around allowed/banned sets of licenses.
     

   • Operational Risk:Lets you create a set of rulesabout the operational risk of using open source software components. For more information, seeComponents Operational Risk.
3. Set thepriorityin which rules areprocessed. Drag and drop the rules to place them according to their priority.
4. Set the Rule Criteria.
   If the criteria is met, then the automatic actions of this rule are executed and the policy is considered as processed (no further rules will be checked).
   
5. Set automatic actions to run if a criteria is met.

Step 2 Creating a Policy Rule

Configure the the basic policy settings and select your policy type - Security or License.

Configure a Security Rule

SelectSecurityfrom the drop-down list and clickNew Ruleto set criteria and assign automatic actions.

配置一个许可规则

To create a new License Rule, selectLicensefrom the drop-down list and clickNew Rule.

Assign an Automatic Action to a Policy Rule

You can define one or more actions within each Policy Rule. To view a list of actions, seeAutomatic Actions.

Block Unscanned Artifacts

This configuration will block unscanned artifact download requests. The download timeout should beset by your system administrator.

Multiple License Permissive Approach

当一个组件检测到有多个许可证s, the policy rules apply on all of the licenses, thus if one of the multiple licenses meets the policy rule, a violation will be created anyways. The multiple license permissive approach enables you to have more flexibility in the policy level and to configure a more permissive approach that allows components that have at least one of the licenses as permitted to go through without triggering a violation even if some licenses are not allowed.

Triggering a Webhook

You can select a predefined Webhook as an automatic action in case a violations is found.

• Select theTrigger Webhookcheckbox and select predefined Webhook from the list.

The payload provided to any triggered webhook is a JSON object describing a list of Alerts.

The following shows an example payload for a webhook.

{“创建”:“2022 - 11 - 23 t15:13:19.005062109z”,”p_severity": "High", "watch_name": "webhook-example", "policy_name": "high-cve", "policy_rule": "high-cve", "issues": [ { "vulnerability_id": "XRAY-261308", "severity": "High", "type": "security", "provider": "JFrog", "created": "2022-11-16T10:36:39.205Z", "summary": "CVE-2022-42898 krb5: integer overflow vulnerabilities in PAC parsing (important)", "description": "DOCUMENTATION: A vulnerability was found in MIT krb5. This flaw allows an authenticated attacker to cause a KDC or kadmind process to crash by reading beyond the bounds of allocated memory, creating a denial of service. A privileged attacker may similarly be able to cause a Kerberos or GSS application service to crash. STATEMENT: Samba in RHEL does not implement the AD DC role and is not built against Heimdal, thus Samba is not affected by this CVE.", "impacted_artifacts": [ { "name": "manifest.json", "display_name": "mysql:8.0", "path": "default/dockers/mysql/8.0/", "pkg_type": "Docker", "sha256": "44f98f4dd825a945d2a6a4b7b2f14127b5d07c5aaa07d9d232c2b58936fb76dc", "sha1": "", "depth": 0, "parent_sha": "44f98f4dd825a945d2a6a4b7b2f14127b5d07c5aaa07d9d232c2b58936fb76dc", "infected_files": [ { "name": "krb5-libs:0:1.18.2-14.0.1.el8", "path": "", "sha256": "c8b498f4f6f42862326eae3df128ff9b0aea2a1f6da72dbb4c2716a8366c97a8", "depth": 0, "parent_sha": "e54b73e95ef388354463a761e4e93ce3dac29cb244b2dc0424f2f4afc6ddf5cd", "display_name": "8:krb5-libs:0:1.18.2-14.0.1.el8", "pkg_type": "Rpm" } ] } ], "cve": "CVE-2022-42898", "applicability": null }, { "vulnerability_id": "XRAY-97724", "severity": "High", "type": "security", "provider": "JFrog", "created": "2020-05-11T12:08:54.784Z", "summary": "** DISPUTED ** An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index. This only affects use of the --extra-index-url option, and exploitation requires that the package does not already exist in the public index (and thus the attacker can put the package there with an arbitrary version number). NOTE: it has been reported that this is intended functionality and the user is responsible for using --extra-index-url securely.", "description": "** DISPUTED ** An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index. This only affects use of the --extra-index-url option, and exploitation requires that the package does not already exist in the public index (and thus the attacker can put the package there with an arbitrary version number). NOTE: it has been reported that this is intended functionality and the user is responsible for using --extra-index-url securely.", "impacted_artifacts": [ { "name": "manifest.json", "display_name": "mysql:8.0", "path": "default/dockers/mysql/8.0/", "pkg_type": "Docker", "sha256": "44f98f4dd825a945d2a6a4b7b2f14127b5d07c5aaa07d9d232c2b58936fb76dc", "sha1": "", "depth": 0, "parent_sha": "44f98f4dd825a945d2a6a4b7b2f14127b5d07c5aaa07d9d232c2b58936fb76dc", "infected_files": [ { "name": "pip-20.2.4-py2.py3-none-any.whl", "path": "usr/share/python39-wheels/", "sha256": "e266d0fa6cead0e80c6c962edcce8156dcd8e9842bae72276bedb352adf1b300", "depth": 0, "parent_sha": "f6cfbf240ed7196ec43fc009b344e17a6c84451079f19efea7b3fd2dab9bd65e", "display_name": "pip:20.2.4", "pkg_type": "Pypi" } ] } ], "cve": "CVE-2018-20225", "applicability": null } ] }

Editing a Policy

Edit an existing Policy, from the Policy page, by hovering over it and clicking on the Edit icon on the right.

Edits made to a policy will automatically be applied to all watches the policy is assigned to. This will take affect only for newly scanned artifacts. You canmanually activate the watch on existing artifacts.