Manage Runtime

Sensors

The Runtime Cluster Management enables users to install Runtime Sensors on their clusters, view the clusters that have been installed, and access detailed information about the clusters, nodes, and sensors that monitor them. This capability also provides users with the health status of their sensors and allows them to determine if their environment is being monitored correctly and easily. To access Cluster Management, navigate to the "Cluster Management" section under the "Runtime" menu.

Enabling and Disabling Runtime Sensors

Sensors are deployed as a DaemonSet and installed by default on each cluster’s nodes. After installation using Helm, runtime sensors can be disabled on demand.

Value	Description	Example
`<node_name>`	A single node	`kubectl label nodes my_node disable_jfrog_runtime=true`
`<node1 node2 node3>`	A list of nodes	`kubectl label nodes node1 node2 node3 disable_jfrog_runtime=true`
`--all`	All nodes	`kubectl label nodes --all disable_jfrog_runtime=true`

Clusters

View Cluster Status

The Runtime Cluster Management Cluster Inventory allows you to view the status of clusters monitored by JFrog Runtime.

Navigate to the Cluster Management section under the Runtime menu.
Once the Controller has been installed, view the list displaying the monitored clusters and their status.
Use this information to track cluster health and proactively address any potential issues.

Inspect Cluster

The Cluster Detailed View in the Runtime Cluster Management offers in-depth insights into the selected cluster and its monitored nodes, enabling you to track sensor health and swiftly detect potential infrastructure issues..

Click on a cluster in the Cluster Inventory pane.
View detailed information, including the list of nodes running under the cluster and their corresponding Runtime Sensor statuses.

In Controller Only mode, node-level sensor details will not be available.

Automatic Security Scanning

Enable automatic security scanning for any container image detected through Runtime Visibility. When a cluster is configured for this capability, the system checks whether each runtime-observed image has corresponding security data. If not, it automatically triggers indexing and scanning based on repository characteristics.

Automatic scanning is a prerequisite for the Vulnerability Prioritization Dashboard. Without it, the dashboard's funnel and vulnerability table will show incomplete data because unscanned images have no vulnerability or applicability information. To ensure full dashboard coverage, enable at least SCA and Vulnerabilities Contextual Analysis for each cluster.

In the platform, under Administration, go to Runtime > Cluster Management.
Under Clusters, hover over the cluster you wish to configure.
From the cluster menu, select Configure.
The Scan Configuration window opens.
In the Scan Configuration window, select the scanners you want to enable for the cluster, including SCA and any Advanced Security scanners such as Vulnerabilities Contextual Analysis, Secrets, Applications, Services, or IaC.
Click Apply to save the configuration.

Runtime Scope

Runtime Scope ensures that every image detected by Runtime sensors in your Kubernetes, OpenShift, or Fargate environments is automatically scanned by Xray and Advanced Security.

This configuration eliminates manual steps and guarantees that all running images are systematically evaluated for vulnerabilities, secrets, and exposures as soon as they are observed in your clusters.

Configure Runtime Scope for a Cluster

Navigate to Administration > Runtime > Cluster Management.
In the Cluster Inventory table, locate the cluster you want to configure.
From the menu, select Configure.
The Scan Configurations window opens.
Select which security scans to enable (SCA, Secrets, Contextual Analysis, Exposures, etc.) and set retention.
Click Apply.

Batch Configuration

In Cluster Management, select multiple clusters.
Click Batch Configure and apply scanners/retention settings to all selected clusters.

A coverage summary appears in the Clusters Configuration Security Coverage panel, showing how many clusters are configured with each type of scanner.

Vulnerability Prioritization Dashboard

The Vulnerability Prioritization Dashboard provides a centralized view of CVEs detected across all running container images. It combines vulnerability data from JFrog Xray and Advanced Security with runtime intelligence from deployed sensors to help security teams focus on the most critical issues.

Prerequisites

For the dashboard to display complete data, the following must be in place:

At least one cluster must be connected with a running controller (Runtime Integrity or Runtime Impact).
Automatic Security Scanning must be enabled for your clusters with at least SCA and Vulnerabilities Contextual Analysis selected. Without this, the funnel and vulnerability table show incomplete data.
Runtime Impact (Controller + Sensors) is required for the Validated in Runtime funnel stage. In Controller Only mode, all other funnel stages function normally.

Monitoring Runtime Status

The dashboard displays two status indicators that reflect the readiness of your runtime environment:

Scan Status

Indicates whether running images have been scanned by Xray.

Status	Description	Action
`not_scanned`	No running images have been scanned	Enable Automatic Security Scanning for your clusters
`partial`	Some running images have been scanned	Check that all clusters have scanning configured; some images may be from unconfigured clusters or scanning may still be in progress
`scanned`	All running images have been scanned	No action needed

Installation Status

Indicates the Runtime deployment level across your clusters.

Status	Description	Dashboard Impact
`no_runtime_installed`	No Runtime clusters are connected	Dashboard has no data; install Runtime on at least one cluster
`controller_only`	Controller is running but sensors are not deployed	All funnel stages work except "Validated in Runtime"
`full`	Full sensor installation (Controller + Sensors) on at least one cluster	All funnel stages are available, including runtime validation

To move from controller_only to full, reinstall Runtime with the Controller and Sensors option in Administration > Runtime > Cluster Management > Install Runtime.

Viewing the Prioritization Funnel

The prioritization funnel displays counts at each stage, showing how the total vulnerability count narrows as filters are applied:

All Vulnerabilities — Total distinct CVEs across all scanned running images.
Critical & High — Only Critical or High severity.
Applicable — Confirmed exploitable by Contextual Analysis.
With Fix Version — A fix version is available from the package maintainer.
Validated in Runtime — Confirmed as actively loaded or executed by Runtime sensors.

Each stage is cumulative. A sudden increase at any stage may indicate new images deployed without scanning, a new vulnerability disclosure affecting running components, or a change in cluster configuration.

Viewing Live Assessment Highlights

The highlights widget provides at-a-glance risk indicators:

Malicious Packages — Number of detected malicious packages and the count of affected images. Malicious packages are identified by JFrog Xray's automated scanners and research team.
Critical & Applicable CVEs — Count of Critical severity vulnerabilities confirmed applicable by Contextual Analysis, along with the number of images affected.
Integrity Violations — Number of images where a discrepancy was detected between the source artifact in Artifactory and the running binary. This may indicate tampering or images pulled from untrusted registries.

Viewing the Running Images Trend Chart

The trend chart displays a 30-day time-series of:

Total running images per day
Scanned vs. unscanned image counts
Vulnerability counts broken down by severity (Critical, High, Medium, Low, Unknown)

Use this chart to monitor whether your security posture is improving over time. A rising count of unscanned images or increasing vulnerability numbers may indicate that new workloads are being deployed without adequate scan coverage.

The chart data is computed daily from snapshots. If the chart shows a calculating status, the snapshot computation is still in progress — it will resolve automatically.

Integrity Violations

Runtime continuously monitors running container images for integrity discrepancies by comparing them against their source artifacts in JFrog Artifactory. When a violation is detected, it appears as a risk indicator on the affected image in the Live Assessment dashboard.

Viewing Integrity Violations

Navigate to Runtime > Live Assessment > Images.
Images with integrity violations display an Integrity Violation risk badge.
Click on an affected image tag to open the Image Tag Details view.
Select the Integrity Violation tab to see the full explainability view.

Understanding the Explainability View

The Integrity Violation tab provides a structured investigation view with three collapsible sections:

Evidence — "What was found?"

The evidence section shows forensic details specific to the violation type:

Digest Mismatch: Displays the Runtime Digest (Actual) side-by-side with the Artifactory Digest (Expected). Both digests include copy-to-clipboard functionality, and the Artifactory digest provides a direct link to view the artifact in Artifactory.
Missing Source: Shows an Artifact Not Found status indicator along with the Registry Path where the image was expected to be found.
Post-Deployment Tag Update: Displays a timeline showing the Deployment Time and Tag Update Time with the elapsed time difference between them. Below the timeline, the digest comparison is shown (same as Digest Mismatch).

Location — "Where is the Violation?"

Shows the infrastructure context where the violation was detected:

Field	Description
First Detected	Timestamp when the violation was first identified
Cluster	The Kubernetes cluster where the image is running
Namespace	The namespace containing the affected workload
Workload	The specific Kubernetes workload (Deployment, StatefulSet, etc.)
Node	The cluster node running the container

Recommendations — "What Steps are Recommended?"

Provides actionable remediation guidance specific to the violation type:

Digest Mismatch (Critical): Treat as a security incident. Trace the source using Build Owner and Deployed By fields. Isolate the workload and force a redeployment to pull the correct image.
Missing Source (High): Check retention policies for accidental deletion. Validate whether the image was sideloaded bypassing Artifactory (Shadow IT). If deleted in error, restore from Trash Can; if unauthorized, terminate the workload.
Post-Deployment Tag Update (Medium): Check if a CI/CD pipeline recently pushed a new build to the same tag. Short-term: restart the workload to pull the updated image. Long-term: switch to immutable tags or digest-based (SHA256) deployments.

Integrity Status Values

The system tracks the following integrity statuses internally:

Status	Violation?	Description
No Issues	No	Image digest matches Artifactory — no violation
Untrusted Registry	No	Image is from an untrusted registry (separate risk, not an integrity violation)
Invalid Image Source	Yes → Missing Source	Source artifact not found in Artifactory
Invalid Image Integrity	Yes → Digest Mismatch or Post-Deployment Tag Update	Digest mismatch detected; violation subtype depends on whether the image tag is mutable or immutable

Mutable vs. Immutable Tags

The violation subtype for Invalid Image Integrity is determined by whether the image tag is considered mutable:

Mutable tags (e.g., latest, main, master, dev, develop, staging, stable, nightly, edge, canary, alpha, beta, rc, snapshot, head) → Post-Deployment Tag Update (Medium)
Immutable tags (e.g., v1.0.0, 1.2.3-alpine, semver patterns, commit SHAs) → Digest Mismatch (Critical)