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.
Track down how many process groups are affected by a vulnerability:
The distribution of affected process groups between the different states (Affected, Resolved, and Muted) and the percentual distribution.
The number of affected process groups that have been resolved by fixing the vulnerable libraries and the percentage of resolved process groups out of the total number of related process groups.
The number of affected process groups that have been muted (silenced) and the percentage of muted process groups out of the total number of related process groups.
Evaluate process groups by their current status (Affected, then Resolved, and then Muted):
Risk assessment information (about public internet exposure, reachable data assets, and vulnerable functions).
Which are the top five affected process groups, sorted by status and amount of affected processes out of the total processes in the respective process group.
Check the number of affected processes out of the total number of processes (affected and unaffected) that belong to the process groups where at least one process is affected.
On the Prioritization page, select a vulnerability title.
On the details page of the vulnerability, look for Process group overview.
In the Vulnerability details section you can track down the affected process group and see the number of affected processes.
On the Prioritization page, select a vulnerability title.
On the details page of the vulnerability, look for Vulnerability details > Affected entities.
Select the affected process group to open results in any of the compatible apps listed.
Examine related and affected Kubernetes nodes
Third-party vulnerabilities
For Kubernetes environments, in the Kubernetes node overview section, you can
Track down how many Kubernetes nodes are affected by a vulnerability:
The number of Kubernetes nodes and the percentage of affected Kubernetes nodes out of the total number of Kubernetes nodes (Affected, Resolved, and Muted). The number of affected Kubernetes nodes matches the total count only if all functions in all used software component versions are vulnerable.
The number of affected Kubernetes nodes that have been resolved by fixing the vulnerable libraries and the percentage of resolved Kubernetes nodes out of the total number of related Kubernetes nodes.
The number of affected Kubernetes nodes that have been muted (silenced) and the percentage of muted Kubernetes nodes out of the total number of related Kubernetes nodes.
Evaluate Kubernetes nodes by their current status (Affected, then Resolved, and then Muted).
On the Prioritization page, select a vulnerability title.
On the details page of the vulnerability, look for Kubernetes node overview.
Examine other related entities
In the Related entities section, you can examine and track down entities (other than process groups and Kubernetes nodes) that are connected to one of the affected entities, thus indirectly affected by the vulnerability.
On the Prioritization page, select a vulnerability title.
On the details page of the vulnerability, look for Related entities.
Expand a row and select
A related entity, to open it in another compatible app for further insights.
View all related (…), to navigate to the overview page of the related entities.
Rows are expandable for the sections counting at least one related entity.
In the Vulnerability evolution section, you can better understand the historical context and evolution of a vulnerability over time based on current status and the latest events.
For example, in case a vulnerability increases in severity, it's good to know when and why the increase happened: Given that a vulnerability with Medium severity, which is not on your "immediately to fix" radar, suddenly becomes Critical, it's helpful to know that you didn't overlook a Critical vulnerability for a long time, but the vulnerability was Medium before and now has become a priority.
Without history, you only have the current criticality and know how long it has been open. That could lead to questions when a Critical vulnerability seems to have been open for one week.
On the Prioritization page, select a vulnerability title.
On the details page of the vulnerability, look for Vulnerability evolution.
Events are stored for one year and can only be queried up to the timestamp of when the vulnerability was first detected.