After you enable and configure Dynatrace Runtime Vulnerability Analytics, Dynatrace starts inspecting your libraries and first-party code to detect code-level vulnerabilities. A code-level vulnerability is a security problem based on a flaw in your application code. For more information on the mechanism to detect vulnerabilities and assess risk, see Vulnerability evaluation.
To see the list of detected code-level vulnerabilities in your environment, go to Code-Level Vulnerabilities. The following information is displayed.
A list of detected code-level vulnerabilities in your environment. For optimized performance, a maximum of 500 vulnerabilities are displayed at a time. You can narrow down the results by applying filters. To sort the list by any item, select the corresponding column heading. To add or remove column headings, select Format table.
S-3694
)SQL injection at DatabaseManager.updateBio():82
)launch.Main
).Critical
), indicating the severity of the vulnerability, and the symbol associated with it._X-Forwarded-For_
). If the symbol is grayed out and crossed out, no public internet exposure was found. If the symbol isn't present, no data is available.Open: The code-level vulnerability is currently present.
Resolved: The code-level vulnerability has been automatically resolved because the root cause (the vulnerable code location) is not present anymore.
Muted: The code-level vulnerability has been muted by request.
A muted vulnerability that has been automatically resolved doesn't change its status to Resolved
.
The number of attacks related to this code-level vulnerability, based on the last 365 days. The same vulnerability can be exploited by multiple attacks.
This column is displayed only if Dynatrace Runtime Application Protection is activated.
The number of processes affected by the code-level vulnerability. Each affected process runs a code where this vulnerability was detected.
When Dynatrace first detected the code-level vulnerability.
Timestamp of the last status change of the code-level vulnerability. A status change can be when:
For details, see FAQ: What does "last update" refer to?.
To display this column, select Format table and add Last update to the list.
Expand vulnerability rows for details, or to perform the following actions:
To see details about a code-level vulnerability, go to Code-Level Vulnerabilities and select a vulnerability. The following information is displayed.
Example title:
SQL injection at DatabaseManager.updateBio():82
)S-3694
)SpringBoot org.dynatrace.ssrfservice.Application unguard-proxy-service-*
)Risk level: A code-level vulnerability has a Critical
risk level. Once the vulnerability has been muted, the risk level symbol is grayed out.
Public internet exposure: If there's any public internet exposure. Possible states are:
Reachable data assets: If there are any reachable data assets affected. Possible states are:
Attacks: The number of attacks detected on the code location from different source IP addresses.
This feature is displayed only if Runtime Application Protection is activated.
Processes: The number of processes affected by the vulnerability.
Type: The type of exploit (SQL injection, command injection, or improper input validation).
Technology: The type of technology (Java or .NET) in which the vulnerability was discovered.
To change the status of the vulnerability, select Change status in the upper-right corner of the page.
A description of the vulnerability type.
The exact code location.
The vulnerable function.
The SQL statement (in the case of SQL injection), the command (in the case of command injection), or the JNDI lookup name (in the case of improper input validation). The user-controlled input is highlighted.
For data protection, asterisks (*****
) are displayed instead of user information.
Affected entities:
Select a process group name to navigate to the respective process group details page.
OneAgent version 1.267+
Use case: Go to the source of a code-level vulnerability to determine exactly what is needed to resolve it.
An entry point is a point in the code where an attacker could enter the application and exploit a vulnerability, for example, by passing user input fields to the application (such as a login form or search bar).
In the example below, the entry point information shows that the vulnerability could be exploited by using a malicious payload in the HTTP parameters name
and password
.
To evaluate a code-level vulnerability, the following entry point information is provided:
HTTP path: The path used in the HTTP request to reach and potentially exploit the vulnerability.
Untrusted inputs: The number of inputs that are passed to the usage.
Select Details for additional information:
If the same vulnerability is reachable by multiple HTTP paths, multiple entry point entries are listed. To save memory and network traffic, a limited number of entries is displayed.
If a code-level vulnerability is resolved or is about to be resolved in the next 30 minutes, the entry points are no longer open (vulnerable).
This section is displayed only if
A visual representation of the attack paths, with information about the attack source IPs, entry points, affected vulnerability, and target name.
This section is displayed only if Runtime Application Protection is activated.
The number of applications, services, hosts, and databases that are somehow connected to the identified code-level vulnerability, based on the last hour, with links to the details page of the related entities:
The Kubernetes workloads and Kubernetes clusters sections are displayed only if Kubernetes workloads or clusters are detected.
Use case: Have a better understanding of the evolution of a vulnerability over time.
The Vulnerability evolution section displays the following information.
The current status of the vulnerability.
For open vulnerabilities, the current risk level and the time when the vulnerability was open, the current risk assessment, the number of affected processes, and a count of attacks that happened on this vulnerability during the last 365 days.
Example:
Attacks are displayed only if Runtime Application Protection is activated.
For resolved vulnerabilities, the current status and the time when it was resolved.
The last 10 vulnerability status changes over the last 365 days.
If there are no status change events for over 365 days, this section is empty.
Possible status change events:
A vulnerability is open, resolved, or reopened. Displays the status change and the time when the change happened. For reopened vulnerabilities, select Details to see the risk assessment.
Example event:
A vulnerability is muted or unmuted. Displays the user who performed the change, the reason for the change, any comments, and the time when the change was performed.
Example event:
The vulnerability risk assessment has changed. Displays the time when the change happened and the risk change. Select Details to see the risk change. You can find out, for example, when a vulnerability that used to be exposed to the public internet is no longer exposed.
Example event:
A new attack is detected. Displays the time when this change happened.
Example event:
This event is displayed only if Runtime Application Protection is activated.
Lists reachable data assets exposed via the attack on the code-level vulnerability, based on the last hour (only applicable for SQL-injection types).
Select the database name to navigate to the respective database details page.