Four thousand CVEs is a count.
Forty on exposed services is a plan.
Datadog Vulnerability Management scans hosts, container images and serverless functions for known CVEs and ranks each one by what is running, where it is exposed and whether an exploit exists. We implement it inside the Datadog you already run, decide with you which scanner covers which estate, and operate it every month so each vulnerability is routed to a rebuild rather than a spreadsheet.
Quick facts
Related
- Cloud Security, the group this belongs to
- Software Composition Analysis, the same CVEs in the repository, before the build
- Container Monitoring, the running containers the findings attach to
The vulnerable package, the image it came from, and whether anyone outside can reach it
A scanner that only knows the CVSS score puts a critical in a build tool above a high in a web framework. The build tool was left inside an image on a batch host nobody can reach. The web framework is on the login service. Vulnerability Management knows which host is in production, which service is exposed and which exploit is public, and ranks accordingly.
Scanned from two sides. Agentless Scanning reads hosts, images and serverless functions from the cloud side with nothing installed, every twelve hours. The Agent scans operating system packages on the hosts it runs on, in real time, and adds the runtime context the ranking needs.
A severity score that knows your estate. CVSS adjusted by public exploit availability, CISA's known exploited list, EPSS, production status, exposure to attack, sensitive data and privileged access. The order it produces is the order to fix in.
Findings grouped by what built them. The same vulnerable package in forty containers is one base image. Datadog maps the running container to the image and, with annotations added at build time, to the repository, so the fix is one rebuild rather than forty tickets.
The SBOM, kept rather than assembled. The Infrastructure Packages Catalog lists every package on every scanned host and image, and exports it as a software bill of materials. The questionnaire that asks for one gets a file rather than a project.
A registry full of images nobody runs, a twelve-hour scan read as a failed patch, and a list sorted by CVSS
How it bills. Vulnerability scanning is part of Datadog Cloud Security and is included in both plans, CSM Pro and CSM Enterprise, billed per host protected, whether by the Agent or by Agentless Scanning, with containers metered against a per-host allotment. Agentless Scanning runs scanner instances inside your own cloud account, so their compute and networking costs arrive on the cloud bill rather than the Datadog one. It also needs the right to create and copy snapshots of the volumes it reads. On Amazon ECR and Google Artifact Registry it scans images at rest in the registry as well as the ones running. Datadog publishes the meters and rates. The lever is scope: which accounts and regions, which hosts, and which of those get the Agent instead.
The configuration traps. Every registry scanned, so findings on images that were built once and never deployed sit in the same list as the ones serving traffic. The Agent rolled out without SBOM collection enabled, so the hosts that matter most have the least context. The list sorted by CVSS because that is the column everyone recognises, which puts the batch host above the login service. No link from container to source, so a finding names an image digest and nobody can say which repository to rebuild.
Field noteThe most common gap we see is the base image. One image used by every service in the estate carries the same vulnerable library, and the findings list shows it once per container. The fix is one rebuild and a redeploy. The list makes it look like a quarter's work.
Field noteAgentless Scanning reports on a twelve-hour cycle. A host is patched in the morning, still shows the vulnerability at lunch, and the patch is reported as not working. Nothing failed: the next scan has not run. The hosts that need a finding to clear the same day are the ones that get the Agent, which scans in real time.
Field noteRegistry scanning reads images at rest as well as the ones running, and the images that never run carry the most findings: experimental builds, old tags, the image from a proof of concept. They are real findings on nothing, and they pull the review away from the images that are serving traffic.
Field noteThe pattern we keep finding is the highest CVSS on the least exposed host. A compiler or a debugging tool left in a batch image by a build stage, on a service with no route from the internet. Datadog's severity score weighs exposure, environment and exploit availability and moves it down, and a list sorted by CVSS puts it back on top.
Agentless for breadth. The Agent for depth. Base images before individual findings.
Vulnerability Management is delivered inside the Cloud Security Accelerator, four weeks and fixed scope, alongside the other Cloud Security capabilities you have chosen. If Datadog is new to the estate, LaunchPad runs the platform rollout first. The vulnerability sequence is the same either way.
- Scope the scanners. Agentless Scanning across the accounts that hold production, deployed through your infrastructure as code. The Agent's SBOM collection enabled on the hosts and clusters where runtime context matters. Registries limited to the repositories that deploy.
- Link containers to source. Image annotations added in the build pipeline, so a finding on a running container names the repository and the team, not a digest.
- Set the view by Datadog Severity Score. Production, exposed and exploitable first. The CVSS column stays visible and stops being the sort order.
- Group by base image. The first list is reduced to the images that produce it. Each image gets an owner and a rebuild, and the findings it carried close together on the next scan.
- Route the rest. Findings on hosts and images in the runtime we operate come to us. Findings on application images go to the owning team with the package, the fixed version and the repository attached. Accepted risks are recorded with a reason and an expiry.
- Hand over, in writing. Scanner scope per account, registries in scope, hosts with the Agent, the base image owners, the exceptions, the SBOM export, and the open findings on the day we finished.
Access is admin on the Datadog organisation, the Agentless Scanning role in the cloud accounts applied through your infrastructure as code, and Agent rollout through your deployment tooling. We do not patch hosts we do not operate, and the rebuilds for application images go through your pipeline.
New CVEs arrive every week. New images arrive every deploy.
A base image goes out of support. A new service ships from a template nobody scanned. A CVE that was theoretical gets a public exploit and jumps the queue. Managed Observability is the monthly service that keeps the scanners, the ranking and the rebuild list matching the estate as it is now.
Every month, the new findings are worked by score and by image. What changed in the exploit landscape, which images now carry it, who owns the rebuild. Hosts and images in the runtime we operate are rebuilt by us. The rest leave with an owner.
Coverage follows the estate. New accounts get Agentless Scanning. New clusters get the Agent with SBOM collection. New repositories get annotations in their build. Decommissioned hosts leave the bill.
The two scanners are kept in agreement. Hosts covered by one scanner and not the other are reconciled. So are images that run but were never scanned in the registry, and findings that cleared on the Agent but not on the agentless cycle. There is one answer to "is it fixed".
The SBOM is always current. Exported on request from the packages catalog, with the date, for the customer questionnaire and the auditor. Exceptions with reasons and expiry dates sit alongside it as the record of what was accepted and why.
We operate the stack. You own the product.
We are not a security company, and we do not pretend to be. We are a managed runtime operator. We run the vulnerability scanning inside your Datadog and keep the two scanners covering the estate. We rebuild the hosts and images that sit in the runtime we operate. The rest we route with the package, the fixed version and the evidence attached. Which risks you accept and which images you rebuild first stay your decisions. We operate and evidence the runtime controls that support your compliance obligations.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Vulnerability Management, answered plainly
What does Datadog Vulnerability Management scan?
Hosts, host images, container images including the containers running from them, and serverless functions. Agentless Scanning reads AWS, Azure and Google Cloud workloads from the cloud side, covers operating system and application packages, rescans every twelve hours and can scan container registries. The Datadog Agent scans operating system packages on the hosts and containers it runs on, in real time, and adds the runtime context that drives the ranking. Lambda and Fargate are covered by Agentless Scanning only. Most estates run both, and the scope of each is an implementation decision.
How is Datadog Vulnerability Management billed?
Vulnerability scanning is part of Datadog Cloud Security and is included in both plans, CSM Pro and CSM Enterprise, billed per host protected, whether by the Agent or by Agentless Scanning. Agentless Scanning runs scanner instances inside your own cloud account, so their compute and networking costs arrive on the cloud bill rather than the Datadog one. Datadog publishes the meters and rates. We do not publish prices. We decide with you which accounts and hosts are in scope, and which hosts get the Agent rather than the agentless scan.
How does Datadog rank vulnerabilities?
Each vulnerability starts from its CVSS base score and is adjusted into a Datadog Severity Score. The adjustment uses what Datadog knows about the threat: whether a public exploit exists, whether it appears in CISA's known exploited list, and its EPSS likelihood. It also uses what Datadog knows about your estate: whether the workload is in production, whether it is exposed to attack, whether it handles sensitive data and whether it runs with privileged access. The result is that a critical CVE on an internal batch job can rank below a high one on an internet-facing service, which is the order the fixes should go in.
Does Datadog Vulnerability Management patch anything?
No. It finds, ranks and routes. The fix is a rebuild of the base image, a package upgrade or a rebuild of the host image, applied through your pipeline. Datadog shows which images carry the vulnerable package and, with image annotations added at build time, links a running container back to the repository that built it. Where the host or image sits in the runtime we operate, we do the rebuild. Where it does not, the finding goes to the owning team with the image, the package and the fixed version attached.
What does Critical Cloud do with Vulnerability Management every month?
Managed Observability reviews the new vulnerabilities by Datadog Severity Score rather than raw count and groups them by base image, so one rebuild closes many findings. It confirms that agentless and Agent coverage still match the estate, and reports what was found, fixed and routed. Hosts and images in the runtime we operate are rebuilt by us. The rest go to a named owner with the evidence attached, and the SBOM is kept current for the next questionnaire.
- Datadog products: every product, and how we implement and run each one
- Cloud Security: the group, with vulnerabilities alongside posture, identity, compliance and workload protection
- Software Composition Analysis and Container Monitoring: the dependency before the build, and the container the finding runs in
- Cloud Security Accelerator: scope, rules, routing and the first triage, in four weeks
Ranked by what is running. Fixed by rebuilding what built it.
Tell us how many base images the estate runs on and which services face the internet. We will show you what Vulnerability Management would rank first, who should own each rebuild, and what it takes to keep the list short.