Filter or change status of code-level vulnerabilities
Once you enable code-level vulnerability detection and see the list of code-level vulnerabilities appear on the Code-level vulnerabilities page, there are several ways you can organize them for easy management and to prioritize issues:
Filter by code-level vulnerability details
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.
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 (infra-only): Displays vulnerabilities that have related hosts running in Infrastructure Monitoring mode. For details, see Monitoring modes.
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.
Vulnerability ID: Displays a particular vulnerability by selecting its Dynatrace ID (for example,
Affected or related entity: Displays vulnerabilities that affect or relate to specific entities. Select and enter any combination of the following:
Process group name,
Kubernetes workload name,
Kubernetes cluster name,
Tag, you can use tags on a host, process, and process group, with the syntax
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.
Filter by global timeframe
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.
Filter by management zone
You can use the management zones filter on the Code-level vulnerabilities list and details pages.
How the filter applies
For each case, the filter applies to different components:
On the Code-level vulnerabilities page
- Filtering by management zone applies only to the Vulnerability field.
Data in all the other vulnerability fields is based on the whole environment.
On the code-level vulnerability details page
- Filtering by management zone applies only to the process group instance and the Related entities section.
Data in all the other sections is based on the whole environment.
You can't access management zones that aren't affected by code-level vulnerabilities.
How management zones are calculated
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.
How resolved vulnerabilities behave
When a vulnerability stops affecting a management zone, it won't show up when you filter for that management zone.
When a vulnerability is resolved (when it has stopped affecting the whole environment), it shows up regardless of the selected management zone.
Management zone limitations
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.
Change vulnerability status
Options to change status
Mute (silence) vulnerabilities that are
Open, if you don't consider them important
Resolved, if you don't want to deal with them if they are reopened
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.
- Muted vulnerabilities don't appear on the list of vulnerabilities unless you filter for
- Unmuting an open vulnerability makes it active again—its status changes back to
Open, and the vulnerability shows up again in the list of vulnerabilities when you filter for
- Unmuting a resolved vulnerability changes its status back to
Resolved, and the vulnerability shows up again in the list of vulnerabilities when you filter for
Ways to change status
You can change the vulnerability status individually or in bulk:
Individually (one vulnerability at a time). You have two options:
- On the Code-level vulnerabilities page, under the Details for the selected vulnerability, select Change status, select the new status, enter any additional information, and then select Save.
- On the code-level vulnerability details page, in the upper-right corner of the page, select Change status, select the new status, enter any additional information, and then select Save.
In bulk (for multiple vulnerabilities at once, for example, based on specific filters). On the Code-level vulnerabilities page, you have two options:
- Select multiple vulnerabilities that are displayed on one page (select the vulnerabilities you want, then select Yes, change status, select the new status, enter any additional information, and then select Save).
- Select all vulnerabilities that are displayed on one page (select the Vulnerability column in the vulnerabilities list, select the new status, enter any additional information, and then select Save).
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.
Show status 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.
- Select Show more for the next five status changes.
- Select Details to see who changed the status of the vulnerability, the reason for changing the status, and any additional comments.