Study guide
17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor
Key Takeaways Explain This Topic AI
Runtime Vulnerability Analytics detects and evaluates vulnerabilities based on what is actually running, not just what is deployed, using OneAgent's view of loaded libraries and data flows.
Third-party vulnerabilities arise when an application uses a library or language runtime containing a known vulnerability.
The Davis Security Score refines the base CVSS score using environmental factors such as public internet exposure and reachable data assets, and it is never higher than the base CVSS.
The DSS scale runs from 0.1 to 10.0 with four risk levels: low 0.1-3.9, medium 4.0-6.9, high 7.0-8.9, and critical 9.0-10.0.
The Davis Security Advisor recommends the fixes that would most improve the overall security of the environment, so remediation effort is spent where it removes the most risk.
Last updated: September 2026
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:
- Runtime fact Consequence
- Whether the vulnerable library is actually loaded Shipped-but-unloaded libraries are not raised as risk
- Which process groups and hosts run it Exact blast radius, not a repository name
- Whether the process is exposed to the public internet Adjusts real-world exploitability
- Whether data assets are reachable from the affected service Adjusts real-world impact
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
- Risk level DSS range
- Low 0.1 – 3.9
- Medium 4.0 – 6.9
- High 7.0 – 8.9
- Critical 9.0 – 10.0
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.