Application Security
Runtime vulnerability analytics
Dynatrace security is runtime-based, not a repository scan. Runtime Vulnerability Analytics (RVA) inspects the libraries actually loaded by running processes and matches them to known CVEs (third-party/open-source vulnerabilities), and detects code-level vulnerabilities by tracing untrusted input through the PurePath to a dangerous sink. Results become security problems in the same problem feed, with severity, affected process group, and - critically - exposure (is the workload internet-facing?) used for prioritisation. SCA/SBOM views inventory the components in use.
Runtime application protection
Runtime Application Protection (RAP) reuses the same instrumentation to detect attacks in flight - SQL injection, command injection, SSRF, JNDI injection, deserialization - and can block them. Detection is the default posture; blocking is a deliberate per-process-group configuration decision. Because detection happens inside the process, RAP can see attacks that a perimeter appliance misses (e.g. malicious input that reaches a sink through several services).
Requirements and traps
RVA and RAP need full-stack OneAgent with code-level monitoring on the relevant processes; enabling the capability per host or process group is a separate step from installing the agent. Users also need the right IAM permissions to see security problems. Trap: a vulnerability is a potential weakness; an attack is an observed attempt - a question about "someone tried SQLi and it was blocked" is RAP, not RVA. Trap: RVA does not scan source code or a container registry before deployment.
Worked rule of thumb
Prioritise by three filters, in order: is it in production, is it reachable from the internet, how severe is the CVE? A critical CVE in an internal, unreachable library ranks below a medium one on a public-facing service.