A vulnerability confirmed by real traffic,
not a scanner's guess.
Datadog Runtime Code Analysis, Datadog's IAST, runs inside the APM tracer. It marks external input as tainted, follows it through the running code, and reports a finding only when that input reaches a vulnerable point. We enable it on the services that take external traffic, confirm the tracer can carry it, and operate it every month so the finding next to the trace has an owner.
Quick facts
Related
- APM, the tracer this runs inside
- Code Security, the group this belongs to
- App and API Protection, the same tracer, blocking the attack rather than reporting the weakness
The finding that cannot be argued with, because the request already happened
The usual response to a static finding is that the input is validated upstream, so the pattern is unreachable. Sometimes that is true. Runtime Code Analysis settles it. If a request's header ended up in a shell command, the tracer saw it happen, and the finding carries the trace that proves it.
Input followed, not pattern-matched. URLs, bodies and headers are tagged as tainted on arrival. The tracer follows them through transformations, concatenations and function calls, and reports when they reach a sink such as a query, a command or a file path.
Severity that reflects the sink. SQL injection, command injection and server-side request forgery sit at the top. Cross-site scripting and path traversal next. Weak hashing and insecure cookies below. Missing headers at the bottom. Thirty-five rules in all, varying by language.
The service, highlighted where the engineers already look. A vulnerable service is flagged in the Security view of the APM Catalog. From there, one click reaches its traces, logs and hosts. The security finding and the operational context are the same screen.
Findings that close themselves when the code is fixed. A finding not seen again on a running service closes after a set period, sooner on a new deployment. One that returns within the following months reopens rather than duplicating. The list reflects what is deployed.
Enabled in an environment with no traffic, on a tracer three versions old, and declared clean
How it bills. Runtime Code Analysis is part of Code Security. Bought on its own, it is billed per host, per month, counting hosts where it is enabled and sending spans to Datadog. In a Code Security bundle it is covered by the per-committer meter and runs on any host with the Datadog Agent. Either way each service it covers needs the Agent and the Datadog SDK. APM is not required, though Datadog bills APM intake for the security traces it sends. Datadog publishes the meters and rates for Code Security and for APM. The lever is which services carry it. A service that takes external input is a candidate. An internal batch worker that reads from a queue it trusts is not, and enabling it there adds tracer overhead for findings that cannot exist.
The configuration traps. Enabled in staging only, where the traffic is a smoke test, so the tainted input never reaches most of the code and the empty findings list is read as a clean bill. Enabled in production on every service at once, without checking latency on one first, so the first thing anyone notices is the CPU graph. A tracer version that predates the feature on a third of the services, so the coverage map has holes nobody drew. The rule set assumed to be the same across Java and Node.js, when a class of finding exists in one and not the other. A finding that closed because traffic to that endpoint stopped, read as a finding that was fixed.
Field noteThe most common gap we see is that APM is on and this is not. The tracer is already there, the services already send traces, and the configuration flag was never set because the APM rollout was an observability project and nobody on it owned security.
Field noteThe pattern we keep finding is a runtime finding that matches a static finding somebody had closed as unreachable. The validation was upstream, in a service that had since been changed. Neither tool was wrong. The estate had moved.
Field noteTracer version drift decides the coverage. One service on an old library emits traces and no findings, and it looks covered to anyone who checks only that the tracer is present. The version check is the step that gets skipped.
Field noteFindings on the low tier, the missing header and the weak random, are the ones that stay open longest. Each is a one-line fix. None is urgent on its own, so none is scheduled, and the count of open findings stays flat for a year.
One service first. Latency measured. Then the tier that takes external traffic.
Runtime Code Analysis is delivered inside the Code Security Accelerator, four weeks, fixed scope. It needs the Datadog tracer on the services in scope. If the tracer is not there yet, LaunchPad or the Infrastructure Observability Accelerator comes first, and this follows.
- List the services that take external input. Edge services, APIs, anything that reads a request a user or a third party sent. Internal workers are excluded with the reason recorded.
- Check the language and the tracer version on each. Java, .NET, Node.js and Python only. The tracer must be a version that carries the feature. Services that fail either check are upgraded or left on static analysis.
- Enable it on one representative service. In production, where the traffic is real. Latency, CPU and error rate are compared in APM against the fortnight before. The result is written down before anything else is enabled.
- Roll out by tier. Edge services first, then the services they call. Each tier is checked in APM before the next starts. Configuration ships through your deployment tooling, not by hand.
- Work the first findings with the owners. Critical and high findings are read with the trace that produced them. The ones in the runtime we operate, we fix. The rest leave with an owner, a severity and the evidence attached.
- Hand over, in writing. Services in scope and excluded, tracer versions, the latency comparison, rule coverage per language, muted findings with reasons, and the open findings on the day we finished.
Access is admin on the Datadog organisation and read access to the deployment tooling that ships tracer configuration. We do not need production shell access, and we do not need write access to your code. Fixes are proposed to your developers, not committed by us.
Coverage is a property of the tracer, and the tracer changes with every deployment
A new service ships on a supported language without the flag. A tracer is pinned during an incident and stays pinned. An endpoint stops taking traffic and its finding quietly closes. Managed Observability is the monthly service that keeps the coverage and the findings matching the services that are running now.
Every month, the new findings are read with their traces. Critical and high findings on external-facing services go to the owner that week. The rest are recorded with a severity and a date. Nothing is left in a state nobody has looked at.
Coverage follows the deployments. New services on supported languages are enabled when they appear in APM. Tracer versions are checked against the feature's minimum, and the services behind it are raised with the team that owns the deployment.
Closed findings are checked for why. A finding that closed because the code changed is a fix. One that closed because the endpoint stopped receiving traffic is not, and it is noted so it is not counted as one.
The low tier gets a date. Missing headers and weak randomness are batched into one change per service with the owning team, so the long tail of one-line fixes stops being a flat line on the findings graph.
We operate the stack. You own the product.
We are not a security company, and this is not a penetration test. We are a managed runtime operator. We run the tracer and switch the detection on where it belongs. We read what it finds against the trace and fix what sits in the runtime we operate. The rest goes to the team that owns the code, with the evidence attached. We operate and evidence the runtime controls that support your compliance obligations. The code and the fix stay yours.
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 Runtime Code Analysis, answered plainly
How does Datadog Runtime Code Analysis differ from static analysis?
Static analysis reads the source and reports a pattern that could be exploitable. Runtime Code Analysis watches the running service. The tracer marks external input such as URLs, request bodies and headers as tainted, follows it through the code including after it is transformed or combined, and reports a finding only when tainted input reaches a vulnerable point. A static finding says the pattern exists. A runtime finding says real traffic reached it. Both have their place, and the second is the one to fix first.
How is Datadog Runtime Code Analysis billed?
Runtime Code Analysis is part of Code Security. Bought on its own, it is billed per host, per month, counting hosts where it is enabled and sending spans to Datadog. In a Code Security bundle it is covered by the per-committer meter and runs on any host with the Datadog Agent. Every service it covers needs the Agent and the Datadog SDK. APM itself is not required, though Datadog still bills APM intake for the security traces it sends. Datadog publishes the current meters and rates for Code Security and for APM. We do not publish prices. We do decide, with you, which services carry it, because a batch worker with no external input has nothing for it to find.
Which languages does Datadog Runtime Code Analysis support?
Java, .NET, Node.js and Python, through the Datadog tracing library for each. The detection rules differ by language. A rule that exists for Java may not exist for Python, and some rules exist for one language only. We check the rule coverage for each service's language before it is enabled, so nobody assumes a vulnerability class is covered when it is not for that runtime.
Does Datadog Runtime Code Analysis slow the service down?
It adds work to the tracer, because following tainted input through the code costs more than recording spans. The effect depends on the language, the framework and the request shape. We enable it on one service first, compare latency and CPU in APM against the fortnight before, and only then roll it out by tier. If a service shows an effect the team will not accept, it is left on static analysis and the reason is recorded.
What does Critical Cloud do with Runtime Code Analysis every month?
Managed Observability reviews each month's new findings against the services and traces they came from, and works the critical ones with the owning team. It confirms that newly deployed services on supported languages have it enabled and checks tracer versions. It watches for findings that closed because the service stopped seeing traffic rather than because the code changed. It reports what was found, fixed and routed. A critical finding on a service that takes external traffic is raised the week it appears.
- Datadog products: every product, and how we implement and run each one
- Code Security: the group, and how findings reach the developer
- APM: the tracer, the sampling and the service map this depends on
- Code Security Accelerator: repositories, scanners, rules and gates, in four weeks
Findings with the trace attached. Coverage that matches the tracer.
Tell us which services take external traffic and which languages they run. We will tell you which ones can carry Runtime Code Analysis today, what the tracer needs first, and what it takes to run it.