Datadog Retired Its Host Scanner: 4 Lessons From the Migration

Datadog’s security team had a scanner that could not finish its job: a full pass of the host fleet took longer than the scanner’s credentials lasted. Its fix was to stop running a separate scanner at all. The interesting part of Datadog’s write-up is not the product choice, since the company was always going to use its own tool. It is the method for proving a replacement scanner is not quietly worse, which applies to any vulnerability tooling swap.

The Framework

The old scanner authenticated to each host over SSH and inspected installed packages. As the fleet grew, a full assessment took more than 18 hours, but the credentials expired after 12. Hosts at the back of the queue never got scanned. Longer-lived credentials or more scanners would have kept the security team running dedicated infrastructure and managing network access to every host.

The Datadog Agent was already on every host for observability. When configured, it collects a package inventory and sends it through its existing data path, and Cloud Security matches that inventory against known vulnerabilities. The team acted as “Customer Zero,” running both systems in parallel for six months and judging the replacement against four requirements. Each one is a reusable test.

1. Coverage Must Follow the Host Lifecycle

A scanner can assess every host it reaches and still miss new or short-lived hosts that never enter its schedule. Moving scanning into Agent configuration meant coverage was enabled by the same workflow that provisioned the host. Datadog measured scan freshness, the share of in-scope hosts with a completed scan in the past 24 hours, and kept it above 99%. It used the Cloud Security coverage analysis API to find hosts missing the Agent or misconfigured. A point-in-time host count would have hidden machines falling behind.

2. Compare Unique CVEs, Not Finding Counts

Raw totals were useless. The old scanner grouped multiple CVEs under one plugin, while Cloud Security listed each CVE separately. The two tools also identified a containerd fork differently. Datadog compared unique CVEs per asset and investigated each meaningful difference before concluding either tool had missed something. One difference was a genuine product gap: Cloud Security initially flagged every installed kernel, while the old scanner excluded unloaded ones. The product team fixed it before cutover.

3. Findings Must Fit How Infrastructure Ships

A vulnerable OpenSSL version in an AMI used by hundreds of API hosts should be one fix, not hundreds of tickets. Because findings carried production context such as public exposure and service criticality, teams could trace repeats to a shared image, publish a new AMI, and replace hosts. The full findings set stayed available for compliance even as prioritization narrowed what engineers saw first.

4. Audit Evidence Must Survive the Swap

The replacement had to produce evidence for SOC 2 Type II, ISO 27001, PCI DSS, and FedRAMP High work. Datadog uses the same live findings for internal reviews and audits, filtered by owning team, instead of static exports that go stale. After cutover it retired the remote scanning credentials and the dedicated scanner infrastructure.

Where It Doesn’t Apply

The post omits the numbers a buyer would want: fleet size, the old scanner’s name, the Agent version, and cost, though Datadog says it compared cost. Agent-based scanning also assumes an agent on every host. Datadog’s own documentation recommends agentless scanning first for broad visibility, then the Agent on core assets over time.

Source: Datadog

Content created with AI assistance and reviewed for accuracy.