--- title: Runtime Prioritization Engine description: Datadog, the leading service for cloud-scale monitoring. breadcrumbs: >- Docs > Datadog Security > Cloud Security > Triage and Prioritize > Runtime Prioritization Engine --- > For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt). # Runtime Prioritization Engine {% callout %} # Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com {% alert level="danger" %} This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}). {% /alert %} {% /callout %} 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{% #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. | Dimension | Question it answers | Example signals | | ------------------------ | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Reachability** | Is the vulnerable component actually running? | Affected image observed running on a production workload. Vulnerable package observed executing at runtime. | | **Exposure** | Can attackers reach it? | Resource publicly accessible from static network analysis. Runtime evidence of exposure to active attacks. | | **Exploitability** | Are attackers likely to exploit it? | Public exploit code exists. Finding actively exploited in the wild (listed in [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)). High exploit probability ([EPSS](https://www.first.org/epss/)). | | **Business criticality** | Would a compromise have high impact? | Resource supports a critical business function (Crown Jewel). Runs with elevated privileges and processes sensitive data. | | **Actionability** | Can the right team fix it? | Service owner identified. Fix or mitigation available. | 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{% #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](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk). It combines signals for reachability, exposure, exploitability (including [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) status), business criticality, and actionability. Datadog computes each vulnerability's remediation timeline according to the directive. The due date appears on the vulnerability finding. For more information, see [How CISA's BOD 26-04 changes vulnerability prioritization](https://www.datadoghq.com/blog/cisa-bod-26-04-vulnerability-prioritization/). {% image source="https://docs.dd-static.net/images/security/cloud_security_management/bod_26_04_remediation_timeline.006272ed7e52290c71f7f41232f6dd4a.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/cloud_security_management/bod_26_04_remediation_timeline.006272ed7e52290c71f7f41232f6dd4a.png?auto=format&fit=max&w=850&dpr=2 2x" alt="The Cloud Security Vulnerabilities Explorer shows CISA BOD 26-04 remediation timelines and due dates on vulnerability findings." /%} ## Crown Jewels{% #crown-jewels %} [Crown Jewels](https://docs.datadoghq.com/security/cloud_security_management/crown_jewels.md) 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 %} [Ownership](https://docs.datadoghq.com/security/cloud_security_management/review_remediate/ownership_agent.md) 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{% #filter-findings-by-runtime-signals %} Datadog adds the runtime signals it observes to vulnerability findings. Use these signals in the [Vulnerability Explorer](https://app.datadoghq.com/security/csm/vm), combined with any other criteria. ### Package is running{% #package-is-running %} When [Runtime Package Prioritization](https://docs.datadoghq.com/security/cloud_security_management/setup/agent/kubernetes.md#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: | Runtime context | Tag | | ------------------------ | ---------------------------------- | | Package is running | `@risk.is_package_running:true` | | Accessed by root process | `@package.is_running_as_root:true` | | SUID binary present | `@package.has_suid:true` | 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{% #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: | Runtime context | 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 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{% #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: | Agent | Agentless | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Requires** | [Cloud Security vulnerability scanning](https://docs.datadoghq.com/security/cloud_security_management/vulnerabilities.md) and [container monitoring](https://docs.datadoghq.com/containers.md) enabled on the Agent. | [Agentless Scanning](https://docs.datadoghq.com/security/cloud_security_management/setup/agentless_scanning.md) on the cloud account. | | **Source of the context** | [Container monitoring](https://docs.datadoghq.com/containers.md) data: the containers Datadog observes running on the hosts the Agent monitors. | Agentless Scanning, which records the images running on a resource at the time the scan runs. | | **Update frequency** | Hourly, when Datadog re-evaluates the image's findings. | Once per Agentless scan of the resource, every 12 hours. | | **Container-level detail** | The side panel of a finding in the [Vulnerability Explorer](https://app.datadoghq.com/security/csm/vm) lists the containers that recently ran the image. | Not available. | ## Get started{% #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](https://docs.datadoghq.com/security/cloud_security_management/setup/agent/kubernetes.md#runtime-package-prioritization), [Docker](https://docs.datadoghq.com/security/cloud_security_management/setup/agent/docker.md#runtime-package-prioritization), or [Linux](https://docs.datadoghq.com/security/cloud_security_management/setup/agent/linux.md#runtime-package-prioritization) deployments. See [Setting Up Cloud Security](https://docs.datadoghq.com/security/cloud_security_management/setup.md). 1. Open the [Cloud Security Summary](https://app.datadoghq.com/security/csm) in Datadog. Prioritized findings are surfaced at the top of each funnel and in the [Security Inbox](https://docs.datadoghq.com/security/security_inbox.md). ## Further reading{% #further-reading %} Additional helpful documentation, links, and articles: - [Understand Cloud Security severity scoring](https://docs.datadoghq.com/security/cloud_security_management/triage_and_prioritize/severity_scoring.md) - [Detect and remediate vulnerabilities with Cloud Security](https://docs.datadoghq.com/security/cloud_security_management/vulnerabilities.md) - [Review prioritized findings in the Security Inbox](https://docs.datadoghq.com/security/security_inbox.md) - [Prioritize security findings with the Datadog Runtime Prioritization Engine](https://www.datadoghq.com/blog/runtime-prioritization-engine/) - [Securing the AI era: Outpace AI-powered attacks with unified security and observability](https://www.datadoghq.com/blog/datadog-security/) - [How CISA's BOD 26-04 changes vulnerability prioritization](https://www.datadoghq.com/blog/cisa-bod-26-04-vulnerability-prioritization/)