What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Current language support matrix and per-language feature parity: confirm
- Product naming and packaging within the Datadog platform: verify
- Whether static analysis and IAST are licensed as one SKU: verify
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's approach starts from a component most of its customers have already deployed: the APM tracing library. The same dd-trace agent that produces distributed traces is extended to carry security instrumentation, so enabling code security is closer to setting an environment variable than installing a new runtime agent. Once switched on, the library tags data arriving from request parameters, headers, cookies and bodies as tainted, propagates those tags through string operations and framework calls, and reports when tainted data reaches a sink such as a SQL statement, a shell invocation, a path resolution or a redirect target.
Findings land in the Datadog platform alongside traces, so a vulnerability is attached to the specific request that triggered it and to the service map entry for the affected service. Related capability in the same family flags weak cryptographic primitives and insecure configuration observed at runtime, and reports which dependencies were actually loaded and executed rather than merely declared in a manifest. The intended value is not a new scanner but one telemetry pipeline covering performance, errors, attacks and code weaknesses.
Where it fits
This runs in whatever environments you already instrument: staging, load test environments, and in some deployments production itself, since the overhead profile is designed to be similar in kind to tracing. Ownership usually sits with the platform or SRE team who already administer Datadog, with application teams consuming findings in dashboards they visit for other reasons. The prerequisite is real: you need Datadog APM deployed and a supported runtime, otherwise none of this applies.
Strengths
- Rollout cost is unusually low for IAST when tracing is already in place, since there is no second agent to certify and deploy.
- Vulnerabilities correlate directly with traces, service ownership and deployment metadata, which shortens the path from finding to owner.
- Runtime dependency observation narrows composition analysis noise to code that actually loads.
- Results reach developers in a tool they already open, rather than in a security console nobody logs into.
Limitations
- Coverage depends entirely on traffic. Endpoints nobody exercises produce no findings, and quiet code reads as clean code.
- Hard coupling to the Datadog platform: adopting it for security means accepting that vendor for observability too.
- Language coverage and propagation depth are narrower than long established agent based IAST products, and parity across supported runtimes is uneven.
Who it suits
Sensible for engineering organizations already standardized on Datadog who want runtime security signal without a separate agent rollout or a separate console. Not a fit for teams using another observability stack, for those needing broad language coverage, or for anyone who wants findings before the application is deployed and receiving traffic.
Used Datadog Code Security (IAST)? Recommend it under your own name and title.
Recommend this tool