Vulnerabilities
Latest Dynatrace
What you'll learn
- Filter, format, and sort to find relevant vulnerability information.
- Prioritize vulnerabilities based on Davis Security Score, Davis Assessment, affected and related entities, historical context.
- Apply fixes, track remediation, drill down to the source of vulnerabilities, change the mute status of affected entities.
- Interact with other apps and download results to share with others.
Target audience
Vulnerabilities 
is dedicated to devsecops engineers.
Permissions
An admin user needs to assign the following IAM policies to the group of users that will access the vulnerability-service:
Read EntitiesRead Security Events- One of the following user policies:
Admin User,Pro User,Standard User(for details, see Default policies.)
See below for instructions.
-
In Account Management, select Identity & access management > Group Management.
-
Select Group to create the group.
-
Enter a name (for example,
vulnerability-service) and a description (for example,vulnerability-service group), then select Create.
Once the group is created, you can view details and assign policies.
-
Select Permission.
-
In the drop-down menu of Permission name, select and save the three required policies, one at a time.
Once added, the three policies should be displayed in your list of permissions.
- In Account Management, select Identity & access management > People.
- Select Invite user to invite users to the newly created group.
Vulnerabilities detects if the applications in your Dynatrace environment use vulnerable libraries at runtime or vulnerable runtime to execute your code. It helps you prioritize based on context and impact, efficiently addressing remediation actions.
Try Vulnerabilities and share your feedback to help us improve.
Learning modules
- Filter, format, and sort to find relevant vulnerability information.
- Address remediation and optimize remediation activities.
- Prioritize third-party, code-level, and runtime vulnerabilities.
- Interact with other apps for further insights and share results with stakeholders.
Vulnerabilities app concepts
Understand essential concepts and key terms for the Vulnerabilities app.
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
Calculation starts from the base CVSS Score, and takes into consideration metrics pertaining to
- Public internet exposure: Attack vector (AV)
- Reachable data assets: Confidentiality (C) and Integrity (I)
CVSS v2 is deprecated. For vulnerabilities relying on this data, Davis Security Score can't be assessed.
To influence the security score of a third-party vulnerability based on the public internet exposure, Davis uses the Modified Attack Vector (MAV) metric. This metric reflects the context by which vulnerability exploitation is possible.
- If the original AV value shows exploitation is possible via network access, but, based on the topology information extracted from your environment, the service isn't actually exposed, Davis lowers the MAV value.
- In all other cases, the MAV value doesn't differ from the original AV value.
To influence the security score of a third-party vulnerability based on reachable data assets, Davis uses the Modified Confidentiality (MC) and Modified Integrity (MI) metrics. These metrics reflect the actual accessibility of a reachable data asset to an affected service.
- If the original C and I values show that data exposure or manipulation are possible, but, based on Davis' evaluation, there aren't any reachable data assets accessible by the affected service, Davis lowers the corresponding MC and MI values.
- In all other cases, the MC and MI values don't differ from the original C and I values.
- Davis modifies the scores on the service level. If a vulnerability has more than one affected service, the highest score is used.
- DSS is never higher than the base CVSS. The values for public internet exposure and reachable data assets can only lower the score or leave it unchanged.
The score of a code-level vulnerability is always 10 and the risk always Critical because it's considered to be exploitable at any time.
For example, on a login page where the password hasn't been sanitized before sending it to the database, thus allowing an SQL injection, it's only a matter of time until an attacker finds this vulnerability and exploits it.
Davis Risk Levels
The DSS scale ranges between 0.1 (lowest risk) and 10.0 (most critical risk):
Low Medium
High
CriticalCalculation differences
The Davis Security Score (DSS) calculation differs between the Vulnerabilities app and the Third-Party Vulnerabilities app.
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.
Process_1is exposed to the public internet but has no reachable data assets => DSS lowers the severity toHigh.Process_2isn't exposed to the public internet but has reachable data assets => DSS lowers the severity toHigh.
- In Third-Party Vulnerabilities, DSS aggregates the risk factors of the affected entities (the vulnerability is both exposed to the public internet and has reachable data assets), thus the severity remains
Critical. - In Vulnerabilities , the score is determined by the affected entity with the highest DSS score. So if both affected entities have
Highseverity, the severity is lowered from the initialCriticaltoHigh.
How to use: You can prioritize vulnerabilities based on DSS.
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.
Understand the risk factors and assessment modes considered when assessing a vulnerability.
- Public internet exposure
- Reachable data assets
- Vulnerable functions Third-party vulnerabilities
- Public exploit Third-party vulnerabilities
- Assessment mode
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
- Example:
- 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
- Examples:
States
How to use: You can
- Filter vulnerabilities by Davis Assessment >
Vulnerable functions in use - Prioritize vulnerabilities based on vulnerable functions
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.
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.
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)
- For Snyk-based vulnerabilities, the package name (example:
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
- Example:
- 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
- Example:
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
- Example:
How to use: You can drill down and explore code location.
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
-
By Status to see
OpenandResolvedvulnerabilities -
By Mute: Status to see
Muted (Open)vulnerabilitiesResolved vulnerabilities are displayed only once (at the resolution time). Extend the timeframe to include more results. For details, see Timeframe filter.
States for affected entities
A muted entity that was closed automatically doesn't change its status to Resolved, but to Muted (Resolved).
How to use: On the overview page of affected process groups or Kubernetes nodes, you can
-
- By Status to see the affected entities that are
AffectedorResolved - By Mute > Mute: Status to see affected entities that are
Muted (Affected)orMuted (Resolved)
- By Status to see the affected entities that are
-
Format affected entities table by Status
Further reference: Can a vulnerability be resolved while there are still affected entities?