Vulnerabilities concepts

• Latest Dynatrace
• Concept
• Updated on Oct 07, 2025

Understand essential concepts and key terms for the Vulnerabilities app.

How Dynatrace uses CVSS

Third-party vulnerabilities

Dynatrace uses the Common Vulnerability Scoring System (CVSS) to assess and contextualize vulnerabilities. CVSS provides a standardized framework for describing the severity, exploitability, and impact of vulnerabilities using structured vector strings and numerical scores. This scoring system forms the foundation for the Davis Security Score (DSS), which adds environmental context to help prioritize remediation.

CVSS data source

CVSS vector data is sourced from the Snyk vulnerability feed, which includes both CVSS v3 and CVSS v4 vectors when available.

Scoring logic

Dynatrace supports both CVSS v3 and CVSS v4 for vulnerability scoring. CVSS vector data is sourced from both the Snyk vulnerability feed and the National Vulnerability Database (NVD). When CVSS v4 vectors are available in the Snyk feed, they are used to calculate the Davis Security Score (DSS). If CVSS v4 is not available, CVSS v3 vectors are used as a fallback.

Scoring is based on the official CVSS v4 calculator provided by FIRST.org.

CVSS vectors

In the Vulnerabilities app, each vulnerability displays two types of CVSS vectors:

Both vectors are visible on the Prioritization page:

This visibility helps you understand how the CVSS score was derived and compare raw versus contextualized risk.

Dynatrace supports filtering by CVSS vector components for advanced triage. For practical examples and usage, see Filter by CVSS vectors.

Davis Security Score

Dynatrace calculates the severity of a vulnerability based on Davis Security Score (DSS), so you can focus on fixing vulnerabilities that are relevant in your environment, instead of on those that have only a theoretical impact.

DSS

An enhanced risk-calculation score based on the industry-standard Common Vulnerability Scoring System (CVSS). Davis AI is designed to provide a more precise risk-assessment score by considering additional parameters such as public internet exposure and whether or not data assets are reachable from an affected entity.

Risk-averse: Virtually all security products use the CVSS Base Score to set the severity of security vulnerabilities. CVSS was designed to be risk-averse, which means that, for any given vulnerability, the assigned score assumes the worst-case scenario. The CVSS specification does allow for some modifications based on environmental influences, but this is usually not factored into the risk score calculation, which leads to many high or critical vulnerability scores that the user needs to handle.

Accurate: Davis doesn't assume the worst-case scenario. Instead, Davis adapts the characteristics of the vulnerability to your particular environment, taking into consideration its structure and topology, and advises you as to which elements are at risk and how to handle security issues. With Davis AI, you can find out if the affected entity is reachable from the internet and if there is any data storage in reach of an affected entity.

Efficient: By including additional parameters in its analysis, Davis is designed to leverage data to more precisely calculate the security score and predict the potential risk of a vulnerability to your environment. By reducing the score of vulnerabilities that are considered less relevant for your environment, you gain time to focus on the most critical issues and fix them faster.

Vulnerability score calculation

Davis Risk Levels

The DSS scale ranges between 0.1 (lowest risk) and 10.0 (most critical risk):

Davis Risk Level	Vulnerability score range
Low	Vulnerabilities ranging between 0.1 and 3.9
Medium	Vulnerabilities ranging between 4.0 and 6.9
High	Vulnerabilities ranging between 7.0 and 8.9
Critical	Vulnerabilities ranging between 9.0 and 10.0

Calculation differences

The Davis Security Score (DSS) calculation differs between the Vulnerabilities app and the Third-Party Vulnerabilities app.

App	DSS assessment
Third-Party Vulnerabilities	DSS is assessed based on aggregating the scores of affected entities within the selected management zone.
Vulnerabilities	DSS is assessed based on the DSS of the affected entities within the selected segment.

Thus, the DSS (score and risk level) for vulnerabilities in Vulnerabilities can be lower than in Third-Party Vulnerabilities.

Example

A vulnerability with Critical severity affects two processes, Process_1 and Process_2.

How to use: You can prioritize vulnerabilities based on DSS.

Davis Security Advisor

Davis Security Advisor recommends the fixes that would most improve the overall security of your environment.

Basis for calculation

To calculate recommended fixes, Davis Security Advisor takes into consideration all third-party vulnerabilities that are currently open and not muted; resolved or muted vulnerabilities aren't taken into account. Fixes are tailored to your environment and ranked based on how much they improve the overall security of your environment.

Grouping

DSA groups specific libraries that trigger vulnerabilities to simplify remediation efforts. When calculating the advice, Davis Security Advisor ignores the specific version of the library. All shown libraries contain known vulnerabilities and should be updated to the latest version.

Advice ranking

Advice is ranked based on the severity of the third-party vulnerabilities. Advice regarding a critical vulnerability, for example, is ranked higher than advice for a high-severity vulnerability.

The severity of a vulnerability is calculated based on Davis Security Score (DSS), so you can focus on fixing vulnerabilities that are relevant in your environment, instead of on those that have only a theoretical impact.

Davis Assessment

Understand the risk factors and assessment modes considered when assessing a vulnerability.

Public internet exposure

Public internet exposure

One of the risk factors taken into consideration when determining the Davis Security Score. If there is public internet exposure, it means that vulnerabilities affect at least one process that is exposed to the internet.

States

How to use: You can filter vulnerabilities by Davis Assessment > Public internet exposure.

Further reading: How is public internet exposure determined?

Reachable data assets

Reachable data assets

One of the risk factors taken to consideration when determining the Davis Security Score. If there are any reachable data assets affected it means that vulnerabilities affect at least one process that has database access (runs a database service).

States

How to use: You can filter vulnerabilities by Davis Assessment > Reachable data assets.

Vulnerable functions

Third-party vulnerabilities

Vulnerable function

One of the risk factors to consider when evaluating a vulnerability (yet they are not considered for the DSS calculation). If there are any vulnerable functions in use, there is at least one process using a vulnerable function (this might indicate a higher exploitation risk).

Class

The class that contains the vulnerable function related to the vulnerability.

• Example: org.apache.http.client.utils.URIUtils

Function usage

Shows whether the vulnerable function is being used by your application. Based on whether your application uses the vulnerable function, you can assess the impact on your environment. The usage of a vulnerable function is calculated on the process level and is aggregated to the process group level, which results in a count of affected process groups per function.

• Examples: In use, Not in use, Not available

States

How to use: You can

Further reading:

Public exploit

Third-party vulnerabilities

Public exploit

One of the risk factors to be considered when assessing a vulnerability. If there is any public exploit published, it means that malicious code to exploit this vulnerability is available on the internet.

States

How to use: You can filter vulnerabilities by Davis Assessment > Public exploit published.

Assessment mode

Assessment mode

Determines whether detailed analysis is possible based on your monitoring mode.

States

How to use: You can filter vulnerabilities by Davis Assessment > Assessment mode.

How reduced accuracy affects the DSS calculation

The context of internet exposure or reachable data assets cannot be examined due to the lack of information, thus the DSS score can't be lowered.

Affected and related entities

Learn about the entities affected by and related to vulnerabilities in your environment.

Affected entities

Affected entities

Entities (process groups, processes, and Kubernetes nodes) for which a vulnerability was detected, and are therefore directly affected by the vulnerability.

Affected process

A process that contains a vulnerable library or runtime.

How to use: You can prioritize vulnerabilities by affected entities.

Related entities

Related entities

Entities that are connected to one of the affected entities and, thus, indirectly affected by the vulnerability.

Related application

An application associated with the affected processes.

Related service

A service that runs directly on a vulnerable process group instance.

Related host

A host on which the vulnerable process runs.

Related database

A database that is accessed by the vulnerable process or reachable from it. It can be reached via multiple hops.

Related Kubernetes workload/cluster

In Kubernetes environments, the workload or cluster to which the vulnerable process belongs.

Related container image

In Kubernetes environments, the container image used by the affected processes.

How to use: You can prioritize vulnerabilities by related entities.

Vulnerability source

Drill down into the source of vulnerabilities for the vulnerable component, entry point, and code location.

Vulnerable component

Third-party vulnerabilities

Vulnerable component

A software component (library) or runtime component (for example, a Kubernetes package) that has a vulnerable function causing a vulnerability:

• For Snyk-based vulnerabilities, the package name (example: org.apache.tomcat:tomcat-coyote)

• For NVD-based vulnerabilities, the runtime technology (examples: Java runtime, Node.js runtime)

How to use: You can drill down and explore vulnerable components.

Further reading: Why is a fixed vulnerability still showing as open?

Entry point

Code-level vulnerabilities

Entry point

A point in the code where an attacker could enter the application, for example, by passing user input fields to the application (such as a login form or search bar).

URL path

The path used in the HTTP request to reach and potentially exploit the vulnerability.

• Example: /user/1218/bio

Untrusted input

The input that is passed to the vulnerable function.

Payloads

The user-controlled inputs that could be used to exploit the vulnerability. If there's a key for the payload (for example, an HTTP parameter name or an HTTP header name), it's displayed after the colon.

• Example: HTTP parameter value: bioText

How to use: You can drill down and explore entry points.

Code location

Code-level vulnerabilities

Code location

Shows where the actual vulnerability is in the code (the location where the vulnerable function is called from).

• Example: SQL injection at DatabaseManager.updateBio():82

How to use: You can drill down and explore code location.

Vulnerability status

Learn about the resolution and mute status of a vulnerability or affected entity.

States for vulnerabilities

How to use: On the Prioritization page, you can filter

States for affected entities

How to use: On the overview page of affected process groups or Kubernetes nodes, you can

Further reference: Can a vulnerability be resolved while there are still affected entities?

Third-party library events

Third-party libraries

To help you monitor and analyze third-party libraries in your applications, Dynatrace provides detailed event data that captures how external libraries are assessed for security risks.

This data is represented through two types of security events:

Both types are stored in the security.events table and can be queried using DQL.

As Dynatrace analyzes the libraries used by your application, it continuously generates vulnerability findings. These raw events reflect the same underlying vulnerability data shown in the Vulnerabilities app, but in a more granular form.

The table below highlights the core differences between the granular finding events and the aggregated view in the app and entity events:

Both views reflect the same underlying data and are complementary—use DQL for deep dives and the Vulnerabilities app for concise overviews and comprehensive risk analysis.

Here's an example DQL query to retrieve vulnerability findings and scans:

fetch security.events
| filter event.provider == "Dynatrace"
| filter event.type == "VULNERABILITY_FINDING" OR event.type == "VULNERABILITY_SCAN"