17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor

Most vulnerability tooling scans artifacts: a container image, a dependency manifest, a repository. That produces enormous lists dominated by libraries that are shipped but never loaded, and by vulnerabilities in code paths the application never executes.

Dynatrace takes a different position. Runtime Vulnerability Analytics (RVA) detects and evaluates vulnerabilities in your environment based on what's actually running, not just what's deployed. Dynatrace OneAgent monitors loaded libraries, runtime components, and data flows in real time. That single distinction is the most important thing to carry into the exam for this topic.

---

The Two Vulnerability Classes

Dynatrace explicitly separates:

• Third-party vulnerabilities, which arise when your application uses a specific library or language runtime containing vulnerabilities. Covered here.
• Code-level vulnerabilities, which arise when Dynatrace Application Security detects a vulnerability in your code by evaluating the requests passing through your applications. Covered in Section 17.3.

Do not confuse them on the exam: a vulnerable version of a logging library is third-party; an SQL injection reachable through a request parameter in your own code is code-level.

---

Why Runtime Detection Changes the Answer

Because OneAgent observes the running process, Dynatrace knows things a scanner cannot:

The result is far fewer findings, each of which is genuinely actionable. When a scenario contrasts "our scanner reports 4,000 vulnerabilities" with "Dynatrace reports 26 critical," it is testing whether you understand that runtime evidence removes the noise rather than hiding it.

---

The Davis Security Score

CVSS is the industry-standard severity score, but CVSS was designed to be risk-averse, which means that for any given vulnerability the assigned score assumes the worst-case scenario. That is appropriate for a global advisory and unhelpful for prioritizing your environment, because everything ends up high or critical.

The Davis Security Score (DSS) is Dynatrace's environmental refinement. Its properties are precisely testable:

• It starts from the base CVSS score and applies metrics reflecting environmental factors.
• The factors are public internet exposure and whether data assets are reachable from the affected entity.
• DSS is never higher than the base CVSS. The environmental values can only lower the score or leave it unchanged.
• Davis does not assume the worst-case scenario, which is what makes it more accurate for prioritization.

Mechanically, Davis uses the Modified Attack Vector (MAV) metric to reflect public internet exposure, and where the original confidentiality and integrity values assume data exposure or manipulation is possible but Davis determines there are no reachable data assets accessible by the affected service, it lowers the corresponding modified confidentiality and integrity values.

The DSS scale

The scale runs from 0.1 (lowest risk) to 10.0 (most critical risk). Memorize the four bands — they appear directly in questions.

Worked example

A library vulnerability carries a base CVSS of 9.8 (critical). Dynatrace finds it loaded in two processes:

• Process A — an internet-facing API service with a live connection to the customer database. Little or no environmental reduction applies; DSS stays near 9.8 and the finding remains critical.
• Process B — an internal batch job with no inbound internet path and no reachable data assets. Davis lowers the modified attack vector and the modified confidentiality and integrity values; DSS drops substantially, perhaps into the medium band.

Same CVE, same library version, two very different DSS values — because the environment differs. A scanner that reports both as 9.8 gives the security team no way to sequence the work. This example is the single best way to explain DSS in an exam answer.

---

The Davis Security Advisor

Even a well-prioritized list is a list. The Davis Security Advisor is displayed in Third-Party Vulnerabilities above the vulnerability list on the Third-party vulnerabilities page, and it recommends the fixes that would most improve the overall security of your environment.

The insight it encodes: vulnerabilities are not independent. A single runtime or library upgrade frequently closes many findings at once, because dozens of CVEs are resolved by moving one component to a supported version. The Advisor identifies those highest-leverage actions, so the team's next sprint removes the most risk per unit of effort rather than working top-down through a sorted list.

When a scenario asks "where should a resource-constrained team start?", the Advisor is the intended answer — not "fix everything scored 9.0 and above."

---

Vulnerability States and Coverage

Findings move through open, resolved, and muted (open) states, and they are constantly reassessed and may change risk level over time as the environment changes — a service newly exposed to the internet can raise the DSS of an existing finding without any code change.

Coverage is the companion concern, and it is measured explicitly. The overview reports supported hosts (running technologies Dynatrace supports), monitored hosts (those with vulnerability analytics enabled and not excluded), and excluded hosts (removed by monitoring rules or disabled technologies). Host coverage is calculated based on the last 70 minutes, and changes take up to 10 minutes to appear when coverage increases and up to 70 minutes when it decreases.

The operational lesson: a low vulnerability count is only good news if coverage is high. Zero findings across 40% coverage means nothing at all.