Security scanners surface thousands of findings per environment. Most teams default to ranking by CVSS severity, but static scores flag many findings that are never exploited in practice as critical. Real risk depends on live context: is the vulnerable code running, is an exploit available, and does the affected resource touch sensitive data or a business-critical workflow?

The Datadog Runtime Prioritization Engine combines runtime behavior, exploitability, exposure, and business context from Observability and Security data to identify the 5% of findings that pose real, exploitable risk, so you can focus only on what matters.

How it works

The Runtime Prioritization Engine is designed to be explainable. For each finding, Datadog evaluates five risk dimensions using production context and shows why the finding was prioritized.

The Runtime Prioritization Engine prioritizes a finding when these signals indicate real, exploitable risk in your environment. Findings that do not meet the prioritization criteria stay visible, but move out of the active triage queue.

CISA BOD 26-04 remediation timelines

The Runtime Prioritization Engine computes remediation timelines that follow the risk-based approach in CISA Binding Operational Directive (BOD) 26-04. It combines signals for reachability, exposure, exploitability (including CISA KEV status), business criticality, and actionability.

Datadog computes each vulnerability’s remediation timeline according to the directive and adds it to the finding as one of the following values:

• three_days_and_forensic_triage
• three_days
• fourteen_days
• sixty_days
• fix_on_system_upgrade

The due date computed from this timeline appears directly on the vulnerability finding. Datadog also records the date the vulnerability’s CVE was added to the CISA KEV catalog as a @vulnerability.cisa.kev_added_at timestamp on the finding.

For more information, see How CISA’s BOD 26-04 changes vulnerability prioritization.

Crown Jewels

Crown Jewels are the resources that support your most critical business functions (services, hosts, databases, containers, etc.). Datadog automatically infers them from observability data such as APM trace flow, service dependencies (fan-in), SLOs, traffic, incidents, and more.

Crown Jewels update continuously as your environment changes. You can also add your own Crown Jewels manually in Datadog Cloud Security.

Ownership

Ownership identifies the team or service owner responsible for fixing a security finding. Datadog infers ownership from observability metadata such as service tags, team tags, deployment metadata, on-call configuration, source control links, service catalog entries, and more.

When ownership is known, the engine can route findings to the right team instead of leaving security teams to manually chase remediation owners.

Filter findings by runtime signals

Datadog adds the runtime signals it observes to vulnerability findings. Use these signals in the Vulnerability Explorer, combined with any other criteria.

Package is running

When Runtime Package Prioritization is enabled, Datadog adds package-level runtime context 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 a tag when it observes runtime context. An absent tag means Datadog did not observe the context; it does not mean the package is unused. Use the tags to prioritize what to fix first, not to rule findings out.

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

Runtime context persists for the lifetime of an image version: after a package is observed running, findings for that image keep it. Because container images are immutable, it 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 context to every container image vulnerability finding, with no additional Agent configuration. Search, filter, and group by this tag:

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 the container image findings that were not detected running:

-@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.

How the running context is determined

Datadog detects running images with either the Datadog Agent or Agentless Scanning, but the two differ in where the context comes from and how often it refreshes:

Get started

1. Enable Runtime Package Prioritization on the Agent to surface the Package is running signal on vulnerability findings. See the instructions to do so for Kubernetes, Docker, or Linux deployments. See Setting Up Cloud Security.
2. Open the Cloud Security Summary in Datadog. Prioritized findings are surfaced at the top of each funnel and in the Security Inbox.

Further reading

Additional helpful documentation, links, and articles:

Understand Cloud Security severity scoringDOCUMENTATION Detect and remediate vulnerabilities with Cloud SecurityDOCUMENTATION Review prioritized findings in the Security InboxDOCUMENTATION Prioritize security findings with the Datadog Runtime Prioritization EngineBLOG Securing the AI era: Outpace AI-powered attacks with unified security and observabilityBLOG How CISA’s BOD 26-04 changes vulnerability prioritizationBLOG How we replaced our host vulnerability scanner with the Datadog AgentBLOG