Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,11 @@

## 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. Use 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:

Check notice on line 62 in hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.sentencelength

Suggestion: Try to keep your sentence length to 25 words or fewer.

| Signal | Tag |
|---|---|
Expand All @@ -65,14 +69,44 @@

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:

Check notice on line 72 in hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.oxfordcomma

Suggestion: Use the Oxford comma in 'For example, high and'.

```
@risk.is_package_running:true @severity:(high OR critical) @remediation.is_available:true
```

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 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` |

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].
Expand All @@ -94,3 +128,7 @@
[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/
[14]: /security/cloud_security_management/vulnerabilities/
[15]: /security/cloud_security_management/setup/agentless_scanning/compatibility/
Loading