What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Per-language parity for blocking, code-level vulnerability detection and threat management: confirm current support matrix with vendor
- Product naming and module boundaries have shifted over time: confirm current structure
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Datadog Application Security rides on the tracing libraries you already deploy for APM. The same in-process library that creates spans also inspects request data at instrumented points: incoming parameters, headers, cookies, body content, and the calls the application makes outward into databases, filesystems and command shells. Detection runs in two layers. An in-application WAF evaluates request content against a managed ruleset for the familiar injection and traversal classes, and business logic signals watch authentication, account creation and similar flows. Because the decision happens inside the process, an alert arrives attached to the trace that produced it, so you see the service, endpoint, user and downstream calls rather than a source IP and a URL.
The library also reports which dependencies the running service actually loads, turning library vulnerability findings into a runtime-informed list rather than a manifest-derived one. Blocking arrives through remote configuration: you enable it from the Datadog UI and the change reaches running libraries without a redeploy, dropping a request, an IP or a user.
Where it fits
This is production runtime tooling, but the work of adopting it lands on whoever owns service instrumentation, usually platform engineering rather than the security team. The prerequisite is blunt: you need Datadog APM already deployed with reasonably complete tracing coverage, because anything not instrumented is invisible here. Security teams then operate it from the same console they use for infrastructure signals, and the strongest workflow is triage, moving from an attack signal to the trace, the service map and the deployment that introduced the exposure.
Strengths
- Attack signals arrive joined to the trace, so you get the code path and downstream effect instead of a request line in isolation.
- Blocking and rule changes push to running services through remote configuration, so response does not require a deploy cycle.
- Runtime library inventory narrows dependency findings to code the process actually loads, with no separate agent to deploy.
Limitations
- Coverage tracks APM instrumentation. Services that are not traced, or frameworks the tracer does not support well, are simply not protected.
- Feature parity across languages is uneven, and the newer detection and blocking capabilities typically reach Java and .NET before the rest.
- The value depends on committing to a single observability platform, which is a meaningful architectural dependency for something in your request path.
Who it suits
A natural extension for engineering organizations already standardized on Datadog, where adding protection is a configuration change rather than a new deployment project. Poor fit if your observability stack is elsewhere, if you need a dedicated protection layer independent of your monitoring vendor, or if your applications are not consistently instrumented.
Used Datadog Application Security? Recommend it under your own name and title.
Recommend this tool