Create Policies

This is a Step-by-Step Guide to Creating a Policy in Xray. To learn more about Policies, click here

1. Navigate to Xray → Watches & Policies.
2. Click New Policy.
3. Enter a Policy Name (e.g., "Production Security Policy").
4. (Optional) Add a Description explaining the policy’s purpose.
5. Choose the Policy Type:
   • Security Policy – Detects vulnerabilities in artifacts.
   • License Compliance Policy – Enforces open-source license rules.
   • Operational Risk Policy – Flags outdated, deprecated, or unmaintained dependencies.
6. Click Add Rule to create a new rule. Each policy consists of rules that define the conditions and enforcement actions.
7. Apply on Scope attaches the Policy to a Watch. Policies are enforced through Watches, which monitor repositories, builds, and release bundles.
8. Select an existing Watch.
9. Click Save & Apply.

Security Policy Rules

If you selected Security Policy, configure one of the Rule Types

1. CVEs
   1. Define the Rule Category:
      • By Minimal Severity:
        • Critical (Highest risk)
        • High
        • Medium
        • Low (Least severe)
        • All Severities
      • By the CVSS Score Range (0-10)
      • By specific CVE IDs
   2. Enable Except if a Fix Version is not available to filter vulnerabilities without a fix version.
   3. Enable Skip not applicable CVEs to filter vulnerabilities that do not impact your environment. (JFrog Advanced Security required)
   4. Enable Skip if not in Runtime to suppress violations for container images that have not been observed running in a connected Kubernetes cluster. (JFrog Advanced Security and a connected Runtime controller required.) Available for Minimal Severity, CVSS Score, and CVE IDs rule categories. See Skip If Not In Runtime.
   5. Enable Skip base image to exclude components that originate from the container base image from generating violations for this rule. Use this option to focus enforcement on issues introduced in your own image layers rather than inherited base-image findings. The skip is evaluated per rule. See Skip Base Image.
2. SAST
   1. Detects SAST issues in 1st party source code
3. Malicious Packages
   1. Detects 3rd party packages that the JFrog Security Research team has identified as malicious.
4. Exposures
   1. Select one or more exposure categories and set a Minimal Severity
5. Package Version
   1. Select the package type
   2. Type the package name
   3. Select the package versions

Example Security Rules:

• Block downloads of artifacts with Critical CVEs.

• Fail builds if vulnerabilities have a CVSS score of 9 or higher.

• Send email notifications for newly discovered High and Critical vulnerabilities.

License Compliance Policy Rules

If you selected License Compliance Policy, configure the License Rule Type:

• Banned Licenses – Prevents the use of specific licenses (for example, GPL-3.0).
• Allowed Licenses – Ensures artifacts only use approved licenses.
• Custom Licenses – Custom licenses defined in JFrog Catalog are also available in the license selection dropdown. If a custom license is assigned to a package, it's used for policy evaluation alongside or instead of the detected license.
• Skip base image – When enabled on a license rule, Xray does not generate license violations for components that originate from the container base image. The skip is evaluated per rule. See Skip Base Image.

Example License Compliance Rule:

• Notify the use of GPL-3.0 and AGPL in production.

• Allow only MIT, Apache 2.0, and BSD licenses.

• Fail builds if a banned license is detected.

Skip Base Image (Security and License Rules)

Skip base image is an optional criterion you can enable on individual Security or License Compliance policy rules. When enabled, Xray does not generate violations for vulnerable or non-compliant components that originate from the container's base image.

During scanning, Xray tags base-image components with a From Base marker (the same marker shown in the SBOM tree and scan result tables). When a rule has Skip base image enabled and a matching component is tagged as originating from the base image, that rule does not produce a violation for it.

The skip is evaluated per rule. If a component is from the base image:

• A rule with Skip base image enabled does not produce a violation for it.
• A different rule in the same policy that does not have the option enabled can still produce a violation for that same component.

This option applies to security violations and license violations, including impact analysis. It affects only components identified as coming from the base image. Components introduced in your own image layers continue to generate violations as normal.

In the policy wizard, the option appears as a checkbox labeled Skip base image with the tooltip: Mark to skip violations for components that originate from the container base image. The rules summary shows a checkmark when the criterion is set on a rule.

REST API

In a rule's criteria object, set "skip_base_image": true or false. The field is valid on Security and License Compliance rules. If the feature flag is disabled, the API returns an error stating that the skip-base-image policy criterion is not enabled.

Operational Risk Policy Rules

If you selected Operational Risk Policy, configure the Rule Category:

1. Minimal Severity
   1. High (Highest risk)
   2. Medium
   3. Low (Least severe)
2. Custom Condition
   • End-of-Life Software – Flags packages that are no longer maintained.
   • Deprecated Components – Detects libraries marked as obsolete.
   • Unmaintained Open-Source Projects – Flags packages with no updates in over 12 months.
   • High-Impact Updates – Identifies major version changes with breaking updates.

Example Operational Risk Rule:

• Alert developers if a dependency has not been updated in 12+ months.

• Fail builds if a package is flagged as end-of-life.

• Block downloads of deprecated components.

Set Enforcement Actions

Violation will be generated by default for each policy violation

• Trigger Webhook after the policy is violated
• Create a Jira ticket for each policy violation
• Notify the Watch recipient via email
• Notify the Developer of the resource via email
• Notify email for the configured email address list
• Fail builds if vulnerabilities are detected. You can add a grace period before a build fails, giving teams time to address policy violations without immediate disruption.`
• Block downloads of artifacts. You can add a grace period before an artifact is blocked from downloading, giving teams time to address policy violations without immediate disruption.
• Block Release Bundle Promotion and distribution actions in the Release Lifecycle. You can add a grace period before blocking promotion of Release Bundle, giving teams time to address policy violations without immediate disruption.`

Best Practices for Policy Configuration in Xray

• Use Separate Policies for Different Environments – Apply stricter policies in production than in development.
• Customize Severity Thresholds – Focus on critical risks first to avoid false positives.
• Enable Exposures and Contextual Analysis – Prioritize vulnerabilities that pose real-world threats.
• Regularly Review and Update Policies – Keep policies aligned with new security threats and compliance requirements.