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.
   6. To generate violations only for vulnerabilities in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog, select Match only CVEs listed in CISA KEV. See Match Only CVEs Listed in CISA KEV.
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.

Match Only CVEs Listed in CISA KEV

The CISA KEV Catalog identifies vulnerabilities that attackers have exploited in real-world incidents.

Match only CVEs listed in CISA KEV is an optional criterion for CVE security rules. When you select it, the rule generates a violation only if the vulnerability includes a CVE in the CISA KEV Catalog. The vulnerability must also match the rule category and every other criterion you configure.

For example, you can combine a minimum severity of High with Match only CVEs listed in CISA KEV to focus the rule on High and Critical vulnerabilities with known exploitation.

When CISA KEV data changes, Impact Analysis updates affected indexed resources and re-evaluates their watches and policies. For more information, see Continuous Monitoring.

Skip Base Image (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.