Once you enable code-level vulnerability detection and see the list of code-level vulnerabilities appear in Code-Level Vulnerabilities, there are several ways you can organize them for easy management and to prioritize issues:
You can filter vulnerabilities by vulnerability details, global timeframe, and management zone (you can combine any of these filters).
In the filter bar, the following filters are available.
You can combine any of the filters, but you cannot use the same filter more than once per search.
Risk assessment:
Public internet exposure: Displays vulnerabilities that affect at least one process that is exposed to the internet.Reachable data assets: Displays vulnerabilities that affect at least one process that has database access.Reduced accuracy: Displays vulnerabilities that have related hosts running in Infrastructure Monitoring mode or OneAgent Discovery mode. For details, see Monitoring modes.Status:
Open: Displays active vulnerabilities.Resolved: Displays vulnerabilities that have been closed automatically because the root cause (the vulnerable code location) is no longer present. For more information, see Vulnerability evaluation: Resolution.Muted: Displays the active and resolved vulnerabilities that have been silenced by request.Technology: Displays vulnerabilities in one of the supported technologies (for example, Java).
Vulnerability ID: Displays a particular vulnerability by selecting its Dynatrace ID (for example, S-4311).
Affected or related entity: Displays vulnerabilities that affect or relate to specific entities. Select and enter any combination of the following: Process group name, Host name, Kubernetes workload name, Kubernetes cluster name, Tag. 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.
If a vulnerability affects more than 5,000 processes, the Affected or related entity filter may not be able to find all vulnerabilities impacted by the entered entity.
The table displays the code-level vulnerabilities that 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 vulnerabilities over the last 365 days). For entity-related views (reachable data, related entities), the timeframe is one hour, while for attacks, it's 365 days. Hover over the Info icon next to any section on the details page of a vulnerability to view the timeframe that applies to the respective section.
You can use the management zones filter in Code-Level Vulnerabilities, on the Code-level vulnerabilities list and details pages.
For each case, the filter applies to different components:
On the Code-level vulnerabilities list page
On the code-level vulnerability details page
You can't access management zones that aren't affected by code-level vulnerabilities.
Management zone calculation is based on processes (or Kubernetes node, in the case of Kubernetes vulnerabilities). Management zones are calculated when a vulnerability is opened and every 15 minutes after that until the vulnerability is resolved. A process (or Kubernetes node) of a management zone is affected as soon as a vulnerable component is loaded.
A maximum of 1,000 management zones are stored for a vulnerability. If a vulnerability affects more than 1,000 management zones, you are only able to filter for the 1,000 management zones that are stored with the vulnerability.
You can:
Mute (silence) vulnerabilities that are
Unmute vulnerabilities that are muted, if you consider them important.
Change the vulnerability status by selecting a new reason for the current status or adding more information to the current status.
Status: muted.Open, and the vulnerability shows up again in the list of vulnerabilities when you filter for Open vulnerabilities.Resolved, and the vulnerability shows up again in the list of vulnerabilities when you filter for Resolved vulnerabilities.You can change the vulnerability status individually or in bulk:
Individually (one vulnerability at a time). You have two options:
In bulk (for multiple vulnerabilities at once, for example, based on specific filters). On the Code-level vulnerabilities page, you have two options:
The option to perform bulk changes isn't available to users with view-only access. The Manage security problems permission is required. For details on permission management, see Fine-tune permissions.
You need to wait up to a minute for the changes to take effect. Refresh the page to see your changes.
The last five status changes of the vulnerability within the last 30 days are logged in the Vulnerability evolution section of a vulnerability details page.