What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Language coverage differs between vulnerability analytics and runtime blocking: confirm the current matrix per module
- Module packaging and naming within the platform: confirm with vendor
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
Dynatrace's security modules are built on OneAgent, the same instrumentation already deployed for performance monitoring. OneAgent injects into process runtimes and instruments bytecode, so it knows which libraries a Java or .NET process has actually loaded, at which version, in which container, on which host. Runtime Vulnerability Analytics matches that live inventory against vulnerability data and then layers context that manifest scanning cannot supply: whether the process is reachable from the internet, whether the vulnerable code path is exercised, whether the workload touches data the platform has classified as sensitive, and how many instances are affected. The result is a risk score derived from deployment reality rather than CVSS alone, which is the main argument for doing this at runtime.
Runtime Application Protection works at the execution point. Instrumentation sits where injection actually resolves, such as SQL statement execution, command invocation and JNDI lookup, and evaluates whether the operation was influenced by untrusted input. Detections can monitor or block, and because the decision happens where the payload is interpreted, encoding tricks that defeat upstream pattern matching are less effective.
Where it fits
This is production and pre-production runtime, operated by teams who already treat Dynatrace as their observability platform. OneAgent deployment is the gating prerequisite, and where it is already standard the security modules are largely an entitlement and configuration exercise rather than a new rollout. Security teams get the console and the risk view, platform teams own agent coverage. It does not replace pipeline scanning: nothing here evaluates code before it runs.
Strengths
- Vulnerability findings carry exposure and reachability context from the running process, which cuts the noise that library manifests generate.
- Automatic discovery means new services picked up by OneAgent enter the security view without separate onboarding.
- Blocking at execution points rather than the network edge sidesteps a whole class of evasion problems.
- The topology model used for performance troubleshooting is available for incident context, which shortens investigation.
Limitations
- Deep coverage is strongest for Java and .NET. Other runtimes have narrower capability, particularly for blocking.
- Everything depends on OneAgent being deployed and permitted to inject, which is not always possible in restricted or serverless environments.
- This is an add-on to a large commercial platform, so adopting it for security alone rarely makes sense, and it deepens an existing vendor dependency.
Who it suits
Well matched to enterprises already running Dynatrace broadly who want runtime context to prioritize a vulnerability backlog they cannot patch at volume. A poor fit for teams without OneAgent, for estates weighted toward runtimes with thinner support, or for anyone wanting protection independent of their monitoring vendor.
Used Dynatrace? Recommend it under your own name and title.
Recommend this tool