17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection

Section 17.2 covered vulnerabilities you inherited — a flawed library someone else wrote. This section covers vulnerabilities in your own code, and what happens when someone tries to exploit either kind.

---

Code-Level Vulnerabilities

Code-level vulnerabilities arise when Dynatrace Application Security detects a vulnerability in your code by evaluating the requests passing through your applications. They stem from coding errors, insecure libraries, or poor security practices, and addressing them helps prevent data breaches, system crashes, and unauthorized access.

The detection mechanism is the part that matters for the exam. This is not static analysis of source code. OneAgent already sits inside the running process observing method execution and data flow for PurePath purposes (Chapter 6); Application Security reuses that vantage point to trace untrusted input from where it enters the request to where it reaches a dangerous sink — a database driver, a command interpreter, a file API.

The consequences:

Typical detected classes include injection flaws (SQL, command, LDAP) and other input-handling weaknesses reachable through live traffic.

Configuration prerequisites

Code-level vulnerability detection is gated by several settings, and the exam does ask about the chain. A process is able to report code-level vulnerabilities when:

1. Code-level Vulnerability Analytics is globally enabled
2. OneAgent monitoring is enabled
3. The global code-level vulnerability detection control is set to Monitor for that process's technology
4. No monitoring rules exclude the process group from monitoring
5. The process is restarted after a configuration change

Step 5 is the one that catches people out in practice and in scenarios: enabling detection does not retroactively instrument an already-running process. If a scenario says "we enabled it an hour ago and still see nothing," the missing step is the restart. Note also the asymmetry in how quickly coverage changes are reflected: an increase in coverage takes up to 10 minutes to display, while a decrease can take up to 70 minutes.

---

Runtime Application Protection

Detection tells you a door is unlocked. Protection stops someone walking through it.

Dynatrace Runtime Application Protection leverages code-level insights and transaction analysis to detect and block attacks on your applications automatically and in real time.

Because the enforcement point is inside the process, it has information a network-perimeter device cannot have:

• A WAF inspects a request and guesses whether a string looks malicious, which produces false positives on legitimate input and false negatives on obfuscated payloads.
• Runtime Application Protection observes whether the untrusted input actually reaches a dangerous sink and alters its semantics — whether the string genuinely changes the structure of the SQL statement being executed.

That is why in-process protection can block with high precision and low false-positive risk, and it is the comparison exam questions most often draw.

Attack states

The Attacks view classifies each attempt, and the security overview shows the total number of attacks — exploited, blocked, and allowlisted — that occurred over the last 30 days:

Allowlisting exists because legitimate traffic occasionally resembles an attack — a security research tool, a penetration test, or an application that legitimately accepts SQL-like input. The trade-off is real, and the exam expects you to know that allowlisting is a deliberate exception, not a way to silence noise.

---

Detection and Protection Are Separate

A clean separation worth memorizing:

• Runtime Vulnerability Analytics — finds third-party and code-level weaknesses. Passive.
• Runtime Application Protection — blocks exploitation attempts in real time. Active.

An environment can run RVA without Protection, in which case attacks are visible only through their effects rather than being stopped. The security overview does not display attack counts at all if Application Protection is not activated and enabled — so an empty Attacks view can mean either "no attacks" or "protection is off," and confirming which is a legitimate exam answer.

---

The Combined Picture

The reason both capabilities live on the same platform as observability data is the correlation:

A critical code-level SQL injection exists in the payments service. It is internet-facing, its DSS is 9.4, it processes 40,000 requests per hour, and there have been 312 blocked attack attempts against it in the last 30 days.

Every element of that sentence comes from a different subsystem — Application Security, the Davis Security Score, service metrics from OneAgent, and the Attacks view — and together they justify an emergency change window in a way a scanner report never could. That combination of security findings plus live production context is the argument the Associate exam wants you to be able to make.