From b7109d7c7ee46d7f1efdd78e6f8f572148cf8ec5 Mon Sep 17 00:00:00 2001 From: Jesse Carey Date: Fri, 21 Aug 2026 15:43:20 -0400 Subject: [PATCH 1/2] Add Is Image Running to Runtime Prioritization Engine docs Split "Filter findings by runtime signals" into two subsections: "Package is running" (existing content) and a new "Image is running" subsection covering the @risk.is_image_running signal. Co-Authored-By: Claude Opus 5 (1M context) --- .../runtime_prioritization_engine.md | 27 +++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md index a5533642c30..9ec9ccead7c 100644 --- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md +++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md @@ -55,7 +55,11 @@ When ownership is known, the engine can route findings to the right team instead ## Filter findings by runtime signals -When [Runtime Package Prioritization][4] is enabled, Datadog adds the runtime signals it observes to container image vulnerability findings for packages installed by an operating system package manager (`apt`, `yum`, or `apk`). Search, filter, and group by these tags: +Datadog adds the runtime signals it observes to vulnerability findings. Search, filter, and group by these signals in the [Vulnerability Explorer][11], combined with any other criteria. + +### Package is running + +When [Runtime Package Prioritization][4] is enabled, Datadog adds package-level runtime signals to container image vulnerability findings for packages installed by an operating system package manager (`apt`, `yum`, or `apk`). Search, filter, and group by these tags: | Signal | Tag | |---|---| @@ -65,7 +69,7 @@ When [Runtime Package Prioritization][4] is enabled, Datadog adds the runtime si Datadog adds a tag when it observes a signal. An absent tag means Datadog did not observe the signal; it does not mean the package is unused. Use the tags to prioritize what to fix first, not to rule findings out. -Use the tags in the [Vulnerability Explorer][11], combined with any other criteria. For example, high and critical vulnerabilities that are running and have a fix available: +For example, high and critical vulnerabilities that are running and have a fix available: ``` @risk.is_package_running:true @severity:(high OR critical) @remediation.is_available:true @@ -73,6 +77,23 @@ Use the tags in the [Vulnerability Explorer][11], combined with any other criter Signals persist for the lifetime of an image version: after a package is observed running, findings for that image keep the signal. Because container images are immutable, the signal reflects what has run in that image. When the image is no longer deployed, its findings age out and close. +### Image is running + +Datadog adds an image-level runtime signal to every container image vulnerability finding, with no additional configuration. Search, filter, and group by these tags: + +| Signal | Tag | +|---|---| +| Image detected running in the last 12 hours | `@risk.is_image_running:true` | +| Time the image was last detected running | `@risk_details.is_image_running.evidence.detected_at` | + +Datadog detects running images from [Live Containers][12] on hosts where the Datadog Agent is deployed, and from the cloud provider's service inventory for images covered by [Agentless Scanning][13]. Detection is periodic, so short-lived workloads such as CI jobs and batch tasks are not always detected. Act on `true`; `false` means Datadog did not detect the image running in the last 12 hours, not that the image is stopped. + +`@risk.is_image_running` is always `true` or `false` on container image findings, and absent on host, host image, and serverless findings. To prioritize running images across every asset type, exclude the findings known to be stopped instead of matching on `true`: + +``` +-@risk.is_image_running:false +``` + ## Get started 1. Deploy the Datadog Agent, version **7.79.0** or later, with Cloud Security enabled. On Kubernetes, use **7.81.0** or later for the most complete signal coverage. See [Setting Up Cloud Security][3]. @@ -94,3 +115,5 @@ Signals persist for the lifetime of an image version: after a package is observe [9]: /security/cloud_security_management/setup/agent/docker/#runtime-package-prioritization-preview [10]: /security/cloud_security_management/setup/agent/linux/#runtime-package-prioritization-preview [11]: https://app.datadoghq.com/security/csm/vm +[12]: /containers/ +[13]: /security/cloud_security_management/setup/agentless_scanning/ From 116995f6a4f2838a36a11b5bc9795276a3e5ee4d Mon Sep 17 00:00:00 2001 From: Jesse Carey Date: Fri, 21 Aug 2026 16:16:54 -0400 Subject: [PATCH 2/2] Expand Is Image Running section Cover configuration expectations, Agent and Agentless detection differences, signal interpretation, and where the signal appears alongside Live Containers. Co-Authored-By: Claude Opus 5 (1M context) --- .../runtime_prioritization_engine.md | 27 ++++++++++++++----- 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md index 9ec9ccead7c..5d1d086c93c 100644 --- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md +++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md @@ -55,7 +55,7 @@ When ownership is known, the engine can route findings to the right team instead ## Filter findings by runtime signals -Datadog adds the runtime signals it observes to vulnerability findings. Search, filter, and group by these signals in the [Vulnerability Explorer][11], combined with any other criteria. +Datadog adds the runtime signals it observes to vulnerability findings. Use these signals in the [Vulnerability Explorer][11], combined with any other criteria. ### Package is running @@ -79,21 +79,34 @@ Signals persist for the lifetime of an image version: after a package is observe ### Image is running -Datadog adds an image-level runtime signal to every container image vulnerability finding, with no additional configuration. Search, filter, and group by these tags: +Datadog adds the **Container Image Running** signal to every container image vulnerability finding, with no additional Agent configuration. Search, filter, and group by this tag: | Signal | Tag | |---|---| | Image detected running in the last 12 hours | `@risk.is_image_running:true` | -| Time the image was last detected running | `@risk_details.is_image_running.evidence.detected_at` | -Datadog detects running images from [Live Containers][12] on hosts where the Datadog Agent is deployed, and from the cloud provider's service inventory for images covered by [Agentless Scanning][13]. Detection is periodic, so short-lived workloads such as CI jobs and batch tasks are not always detected. Act on `true`; `false` means Datadog did not detect the image running in the last 12 hours, not that the image is stopped. - -`@risk.is_image_running` is always `true` or `false` on container image findings, and absent on host, host image, and serverless findings. To prioritize running images across every asset type, exclude the findings known to be stopped instead of matching on `true`: +The tag is always `true` or `false` on container image findings, and absent on host, host image, and serverless findings. To prioritize running images across all asset types, exclude what is known to be stopped: ``` -@risk.is_image_running:false ``` +For a window other than 12 hours, query `@risk_details.is_image_running.evidence.detected_at`, the time of the last detection in epoch milliseconds. This field has no facet and is independent of `@risk.is_image_running`. + +How Datadog detects a running image depends on how the image is scanned: + +| | Agent | Agentless | +|---|---|---| +| **Requires** | [Cloud Security vulnerability scanning][14] and [container monitoring][12] enabled on the Agent. | [Agentless Scanning][13] on the cloud account. | +| **Registries** | Any. | Amazon ECR, Azure Container Registry, or Google Artifact Registry. See [compatibility][15]. | +| **Source** | [Live Containers][12] reporting. | The cloud provider's service inventory, read at scan time. | + +Without container monitoring, or for an image in an unsupported registry, the tag reads `false`. + +Each detection restarts the 12-hour window, so a continuously running image does not read `false`. Nothing reports a stop and detection is periodic, so act on `true` and treat `false` as weaker evidence, especially for short-lived workloads such as CI jobs. The signal attaches to a specific image digest and does not change severity. + +The severity breakdown shows how long ago Datadog last detected the image running. When the tag is `true`, the vulnerability side panel lists that image's containers from [Live Containers][12], including ones that have since exited. Live Containers does not monitor Agentless-scanned workloads, so no containers appear for them. + ## Get started 1. Deploy the Datadog Agent, version **7.79.0** or later, with Cloud Security enabled. On Kubernetes, use **7.81.0** or later for the most complete signal coverage. See [Setting Up Cloud Security][3]. @@ -117,3 +130,5 @@ Datadog detects running images from [Live Containers][12] on hosts where the Dat [11]: https://app.datadoghq.com/security/csm/vm [12]: /containers/ [13]: /security/cloud_security_management/setup/agentless_scanning/ +[14]: /security/cloud_security_management/vulnerabilities/ +[15]: /security/cloud_security_management/setup/agentless_scanning/compatibility/