• Home
  • How to use Dynatrace
  • Application Security
  • Application Protection
  • Manage code-level vulnerabilities

Manage code-level vulnerabilities

A code-level vulnerability is a security problem based on a flaw in your application code. It is created by Dynatrace when an attack is detected. For each code-level vulnerability, there can be one or more attacks, which groups attacks by the flaw that resides behind an attack.

List code-level vulnerabilities

After enabling Application Protection, you can see the list of code-level vulnerabilities in your environment by selecting Code-level vulnerabilities from the Dynatrace menu. A list of detected vulnerabilities is displayed.

Note: To sort the list by any item, select the corresponding column heading. To add or remove column headings, select Format table.

  • Vulnerability:

    • Vulnerability name:

      • The Dynatrace vulnerability ID (example: S-3694) +
      • The type of code-level vulnerability and the matching code location where it was detected (example: SQL injection at DatabaseManager.updateBio():82)

      Note: Select the vulnerability name to go to the vulnerability details page.

    • Vulnerable component: the affected process group name (example: launch.Main).

  • Risk level:

    • The vulnerability risk level (typically Critical), indicating the severity of the vulnerability, and the symbol associated with it.
    • The public exposure symbol, if the vulnerability affects a process that is exposed to the internet, based on the Dynatrace entity model (Smartscape).
    • The reachable data symbol, if the vulnerability affects a process that has database access, based on the Dynatrace entity model.

  • Status:

    • Detected: At least one attack on a code-level vulnerability has been detected.
    • Resolved: The code-level vulnerability was automatically resolved, as the root cause (the vulnerable code location) is no longer present.
    • Muted - Detected: The detected code-level vulnerability has been muted by request.
    • Muted - Resolved: The silenced detected vulnerability has been closed automatically because the root cause is no longer present.

  • Attacks: The number of attacks related to this code-level vulnerability – the same vulnerability can be exploited by multiple attacks.

  • Affected PGIs: The number of processes affected by the code-level vulnerability. Each affected process runs a code where this vulnerability was detected.

  • First detected: When Dynatrace first detected the code-level vulnerability.

  • Last update: The last time the code-level vulnerability was updated on account of changes in the underlying data detected by Dynatrace.

  • Details: Detailed information about the selected code-level vulnerability, with an option to Change status (mute or unmute the vulnerability) and navigate to the vulnerability details page.

Note: For optimized performance, a maximum of 500 vulnerabilities are displayed at a time. You can narrow down the results by applying filters.

Display code-level vulnerability details

To see details about a code-level vulnerability, select a link in the Vulnerability column of the Code-level vulnerabilities page.

Review a summary of the key features

The code-level vulnerability details page starts with an infographic of the key features of the selected vulnerability:

  • 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.
  • Reachable data assets: If there are any reachable data assets affected.
  • Attacks: The number of attacks detected on the code location from different source IP addresses.
  • Processes: The number of processes affected by the vulnerability.
  • Type: The type of exploit (SQL injection, command injection, or improper input validation).

Note: To mute the vulnerability, select the Mute button on the top-right of the page.

View detailed information

The summary is followed by details on the selected vulnerability:

  • Context and details:

    • A description of the vulnerability type.
    • The exact code location and vulnerable function name where the attack was detected in your environment.
    • 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 actual malicious input is highlighted.

  • Affected entities:

    • The process group where the vulnerability was detected.

    • The number of affected processes.

      Note: Select a process group name to navigate to the respective process group details page.

  • Attack paths: A visual representation of the attack path, with information about the attack source IPs, entry points, affected vulnerability, and target name.

  • N attacks on this vulnerability:

    • Identifies how many attacks from all sources happened on the same vulnerability, and evaluates them by type (how many have been exploited, blocked, and allowlisted, out of the total number of attacks).
    • Lists the last five attacks that happened during the selected timeframe, with details such as attack identifier (and link to the respective code-level vulnerability details page), entry point, status (exploited, blocked, allowlisted), source IP, and timestamp.

    Notes:

    • Select Attack detection settings to navigate to the Application protection settings page.
    • Select View all attacks to navigate to the Attacks page, filtered by the vulnerability ID.

  • N related entities: The number of applications, services, hosts, and databases that are related to the identified code-level vulnerability, with direct links to those entities.

  • Problem evolution: The last five vulnerability status changes (for example, when the vulnerability is first resolved and then detected again) over the last 30 days.

    Note: Possible status changes happen when

    • A vulnerability is detected or resolved
    • A vulnerability was muted or unmuted

  • Reachable data assets: Lists reachable data assets exposed via the attack on the code-level vulnerability (only applicable for SQL-injection types).

    Note: Select the database name to navigate to the respective database details page.

Filter vulnerabilities

There are several ways to filter the Code-level vulnerabilities page.

Filter by global timeframe

The table displays the code-level vulnerabilities which were detected at some point within the selected global timeframe. However, the data displayed about an entry reflects the current status of the entry, not the historical status.

Filtering by global timeframe is not available for the details page of a code-level vulnerability. The current status of the vulnerability and historical data are displayed (for example, detected attacks over the last 30 days). For entity-related views (reachable data, related entities), the timeframe is 24 hours, while for attacks, it's 30 days. Hover over the Info icon next to any section on the details page to view the timeframe that applies to the respective section.

Filter by management zone

You can also filter by management zone to view, for example, only code-level vulnerabilities from hosts that are in a certain management zone.

Notes:

  • The numeric values displayed on the overview page, such as the number of affected processes, are global, management-zone unaware.
  • You can't access management zones that aren't affected by code-level vulnerabilities.

For information on how to set up and apply management zones, and about the rules that define and limit the entities that can be accessed within a management zone, see Management zones.

Filter by code-level vulnerability details

The following filters are available:

  • Risk assessment: Public internet exposure, Reachable data assets, Reduced accuracy (infra-only).

    Note: Reduced accuracy (infra-only) filters for vulnerabilities that have related hosts running in Infrastructure Monitoring mode. For details, see Monitoring modes.

  • Status: Detected, Resolved, Muted

  • Vulnerability ID: Select a vulnerability based on the 'S' string that represents its ID

  • Affected or related entity: Select and enter any combination of the following: Process group name, Host name, Kubernetes workload name, Kubernetes cluster name, Tag

    Note: For Tag, you can use tags on a host, process, and process group, with the syntax key:value or key. For more information about tagging, see Define and apply tags.

Mute vulnerabilities

If you determine that a vulnerability isn't serious, you can mute (silence) it. Otherwise, it's closed automatically one year after the last occurrence of a related attack.

Note: Muted problems don't appear on the list of vulnerabilities unless you filter for them. Use the filter bar to filter for Status: muted.

There are two ways to mute a vulnerability:

Option 1: On the Code-level vulnerabilities page

  1. Select Details for the vulnerability that you want to mute, then select Change status.
  2. Under Select new status, select the status and reason for muting from the dropdown menu.
  3. Optionally, provide additional information.
  4. Select Save.

Option 2: On the details page of the code-level vulnerability

  1. Select Mute problem in the upper-right corner.

  2. Select a reason for muting the vulnerability and, optionally, provide additional information.

  3. Select Save.

  4. Go to the details page of the code-level vulnerability and select Mute problem in the upper-right corner.

  5. Select a reason for muting the vulnerability and, optionally, provide additional information.

  6. Select Save.

Note: You need to wait up to a minute for the change to take effect. Refresh the page to see your change.

To unmute a vulnerability

  1. On the Code-level vulnerabilities page, filter for muted vulnerabilities.
  2. Select Details for the vulnerability you want to unmute.
  3. You have two options:
    • Select Change status, then select Unmute
    • Select View vulnerability details, then select Unmute.
  4. Select Save.

Unmuting a vulnerability makes it active again—its status changes back to Detected.

Note: You won't be able to mute/unmute a vulnerability if

  • Muting/unmuting is already in progress
  • Required permissions are missing
  • The vulnerability status is Resolved
  • The vulnerability status is Muted - Resolved

To see why muting/unmuting isn't possible, hover over Mute problem/Unmute problem.

Limitations

Code-level vulnerabilities are based only on reported attacks. Therefore, Dynatrace can't currently list code-level vulnerabilities that aren't attacked.