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 so that this rule doesn't raise violations for components that came from the container's base image. For more information, 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 doesn't raise license violations for components that came from the container's base image. For more information, 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 for Security and License Rules

A container image picks up vulnerabilities and licenses from the base image it's built on. Those findings usually belong to the team that maintains the base image, not the team that builds the application, and the application team can't fix them. Skip base image lets you leave those findings out of a rule, so a policy holds each team to what it actually controls.

When you enable Skip base image for a rule, that rule doesn't raise violations for anything that came from the base image. Anything added in your own image layers still raises violations as usual.

The checkbox appears in the policy wizard when you configure a CVE rule or a license rule. The rules summary shows a checkmark next to every rule that uses it.

Where You Can Use It

• Security policies on Minimal Severity, CVSS Score, or CVE IDs rules.
• License Compliance policies, on Banned, Allowed, and Custom license rules.
• Docker and OCI container images.

You can't use it on Specific Package, Suspicious Checksum, SAST, Exposures, Malicious Packages, or Operational Risk rules. Unlike Skip if not in Runtime, it doesn't require JFrog Advanced Security.

What to Expect

• The setting applies to one rule. If another rule, or another policy on the same Watch, doesn't have it enabled, that rule can still raise a violation for the same component. When more than one rule could match, Xray works through the rules in priority order, so check how your rules are ordered.
• The setting applies to violations Xray creates from now on. Violations that already exist stay as they are.
• Xray knows what came from the base image only if it has scanned that base image. If it hasn't, the component is treated as your own and the rule raises a violation.

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.