Skip to content

Back to the catalog

Datadog AI-Native SAST
datadoghq.comarticle

Datadog AI-Native SAST

Datadog describes its open-sourced AI-native SAST tool, which uses LLMs (including Claude Opus) to add context-aware reasoning on top of traditional static analysis, cutting false positives for vulnerabilities like SQL injection and command injection. The pipeline runs identification, context retrieval, LLM analysis, and post-processing steps, uses incremental scanning to control LLM cost after an initial full-repo scan, and is benchmarked against the OWASP Benchmark framework where it beats Datadog's traditional SAST (even LLM-filtered) on most vulnerability categories.

TL;DR Datadog open-sources an LLM-powered, incremental SAST tool that outperforms traditional rule-based SAST on the OWASP Benchmark.
Document

What it is

Datadog's open-source AI-native SAST tool, integrated with Datadog Code Security. It augments rule-based SAST with LLM reasoning to cut false positives. The blog's value beyond the summary is where it does and does not improve on traditional SAST, and the cost model that makes it usable at scale.

Where it actually helps (and doesn't)

On the OWASP Benchmark (true-positive rate / recall vs. their traditional SAST already augmented with LLM false-positive filtering):

  • Context-dependent vulns — SQL injection, command injection, where data flow across files must be traced: AI-native true-positive rate is at least 3× higher.
  • Context-independent vulns — weak randomness, weak encryption algorithms: similar accuracy across both tools. No meaningful gain here.

The tool is explicitly scoped to "high-impact and high-prevalence vulnerabilities" rather than the broad rule set of traditional SAST — so it does not replace existing coverage. Datadog runs both together and surfaces findings side by side.

How the cost model constrains use

Each file analysis makes multiple LLM calls, so a full-repo scan is slow and costly, more so with higher-latency models (Claude Opus is named as an example). The architecture that makes this affordable:

flowchart TD
  A[Onboarding: full repo scan] --> B{File content or<br/>context changed?}
  B -->|yes| C[Incremental analysis]
  B -->|no| D[Skip - reuse result]

A complete scan runs once at onboarding; afterward only changed files (or files whose context changed) are re-analyzed. Datadog LLM Observability tracks latency, token usage, LLM call count, and estimated cost.

What to do

If you evaluate this, calibrate expectations by vulnerability class: expect large recall gains for injection-family bugs, and roughly parity for crypto/randomness issues — don't retire traditional SAST for those. Budget for the onboarding full scan as the cost spike; steady-state cost tracks change volume, not repo size. If you already run Datadog Code Security, findings are enhanced automatically with an exploitation explanation and suggested fix per vulnerability.

Caveats

  • Benchmark numbers are self-reported on OWASP Benchmark and compare against Datadog's own traditional SAST (with LLM filtering), not against third-party tools.
  • No absolute per-category rates, token costs, or model versions are given — only relative ratios and Claude Opus as a latency example.
  • The rationale for open-sourcing is cut off in the fetched text, and the repository link is not included here.

Technologies named here

Techniques named here