Skip If Not In Runtime

Skip if not in Runtime is an optional condition on an Xray security policy rule. When you enable it, Xray does not generate violations for container images that have not been observed running in a connected Kubernetes cluster within the lookback window.

Most registries hold far more images than you deploy. Old tags, abandoned builds, and release candidates can keep producing CVE violations even when nothing is exposed in production. This condition scopes a rule to images that are live in your clusters, so violations reflect real exposure rather than theoretical exposure.

This page explains how the condition works, how to enable it in the UI and REST API, and how to combine it with your existing policies.

Prerequisites

• JFrog Advanced Security — Without Advanced Security, the condition is unavailable in the UI and the REST API.
• At least one connected Runtime controller — JFrog Runtime is included with Advanced Security. You need a controller reporting from at least one Kubernetes cluster. For connection steps, see Manage Runtime.
• Docker container images — The condition has no effect on other package types.

Runtime Impact (sensors) is not required. The condition uses orchestration-level data (which images are running), which the Runtime controller provides.

How It Works

When Xray evaluates a security policy rule with Skip if not in Runtime enabled, it performs an extra check before creating a violation:

1. Is the scanned artifact a container image? If not, Xray ignores the condition and evaluates the rule normally. No violations are skipped.
2. Has this image been observed running in a connected cluster within the lookback window? If yes, the rule applies normally and Xray creates a violation. If no, Xray suppresses the violation for this rule.

Because the check suppresses the violation itself, every action attached to the rule is suppressed with it. If no violation is generated, nothing fails a build, blocks a download, fails a pull request, or blocks a release bundle promotion or distribution.

Lookback Window

"Running" does not mean running at this exact second. Xray treats an image as in runtime if it was observed in a connected cluster within a configurable lookback window.

• Default: 24 hours
• Supported range: 24 hours (minimum) to 10 days (maximum)
• Configured in: Xray system.yaml (shared.skipIfNotInRuntimeTimePeriod)

This setting is not customer-configurable. If you need a window other than the 24-hour default, contact JFrog Support. A short window keeps the policy focused on what is live. A longer window is more forgiving of workloads that scale to zero, run on a schedule, or cycle between deployments.

Scope: Container Images Only

The condition applies to Docker container images only. Runtime presence is meaningful for artifacts that are deployed and executed as workloads. JFrog does not observe standalone packages (for example npm, Maven, or PyPI) running in a cluster, so there is no runtime signal to evaluate. For non-container artifacts, the rule behaves as it would without the condition.

Entitlement and Connectivity States

The experience differs depending on Advanced Security entitlement and whether Runtime controllers are connected:

Enable the Condition in the UI

To enable Skip if not in Runtime on a security policy rule:

1. Go to Application > Xray > Watches & Policies.
2. Create or edit a Security policy, then add or edit a rule.
3. Under Rule Type, select CVEs.
4. Choose a rule category: Minimal Severity, CVSS Score, or CVE IDs.
5. In the If panel, enable Skip if not in Runtime.
6. Configure the rule actions under Then, save the rule, and save the policy.

The condition appears alongside Except if a Fix Version is not available and Skip not applicable CVEs. Hover the info icon for the inline explanation: suppress violations for images that have not been seen running in a connected cluster. Applies to Docker and container images only.

Enable the Condition via REST API

Set skip_if_not_in_runtime to true inside the rule criteria object. The field is supported on policy create and update.

{
  "name": "docker-runtime-high-severity",
  "type": "security",
  "description": "Fail builds for High+ CVEs on images running in the cluster",
  "rules": [
    {
      "name": "high-in-runtime",
      "priority": 1,
      "criteria": {
        "min_severity": "high",
        "skip_if_not_in_runtime": true
      },
      "actions": {
        "fail_build": true
      }
    }
  ]
}

Without Advanced Security, the API returns 403 Forbidden:

{
  "errors": [
    {
      "status": 403,
      "code": "JAS_ENTITLEMENT_REQUIRED",
      "message": "skipIfNotInRuntime requires JFrog Advanced Security entitlement.",
      "learnMoreUrl": "https://jfrog.com/advanced-security-contact-us/"
    }
  ]
}

Best Practices

Use this condition as a prioritization layer on top of your existing policies, not as a replacement:

1. Keep a baseline policy that is Runtime-agnostic. For example, block Critical CVEs on everything. This is your compliance and gatekeeping posture and should not depend on what happens to be running today.
2. Add a second, Runtime-scoped policy for urgency. Use the same or narrower CVE criteria, enable Skip if not in Runtime, and attach higher-friction actions such as notify on-call, create a Jira ticket, or fail the build. Because this rule fires only for images that are live, anything it produces is worth immediate attention.

Limitations and Known Behavior

• Applies to Docker container images only. Other package types are evaluated normally.
• Requires at least one connected Runtime controller. Without runtime data, the condition is inert and violations are generated as usual.
• The lookback window is not customer-configurable. The default is 24 hours. Contact JFrog Support to request a value between 24 hours and 10 days.
• The condition takes effect on the next scan. Existing violations are re-evaluated when the affected artifacts are rescanned.
• There is no indication in the violations list that a violation was skipped. Suppressed violations simply do not appear.
• There is no automatic rescan when a new image starts running. If an image starts running after it was scanned, its violations are re-evaluated on the next scan cycle.