Vulnerability risk exposure: See exposure across monitored processes at runtime

Dynatrace's new Vulnerability Risk Exposure dashboard provides a consolidated view of vulnerability exposure across monitored hosts, processes, and Kubernetes environments. It identifies reported risks across these environments, helping teams prioritize remediation efforts where they matter most.

A vulnerability count alone doesn't show which processes are affected, how widely each vulnerability appears across the environment, or whether all expected processes are being scanned. The vulnerability risk exposure dashboard combines exposure, affected-entity, and scan-coverage data in one view.

What does the vulnerability risk exposure dashboard show?

The dashboard uses vulnerability findings from monitored processes and organizes the data into three views:

• Overview: Understand the overall scale of your exposure with key metrics and breakdowns by severity, technology, and package.
• Drilldown: Pinpoint where vulnerabilities exist with detailed visibility across hosts, processes, and Kubernetes environments.
• Scan coverage: Identify gaps in vulnerability scanning by assessing which hosts and processes are covered and where visibility may be incomplete.

How the dashboard helps teams prioritize remediation

Assess the scale of your exposure

The overview presents four headline metrics: total findings, unique vulnerabilities, affected processes, and affected packages. Bar charts alongside these metrics break down findings by severity and by technology.

Two of these metrics describe your exposure from complementary angles. Unique vulnerabilities are counted once regardless of how many processes they affect, so they show how many distinct vulnerabilities you need to remediate. Findings are counted per vulnerability-process pair, so they reflect how widely those vulnerabilities are spread, and therefore the reported scale of your exposure.

A large gap between findings and unique vulnerabilities indicates that a small number of vulnerabilities account for a disproportionate share of your exposure. The vulnerabilities table helps you act on this: it shows how many processes each vulnerability affects and whether a remediation is available, so you can prioritize the fixes that reduce the most exposure.

The package table groups findings by package name and technology, with per-severity counts and the highest reported severity for each package. This shows which packages have the most reported findings and their highest reported severity.

Locate vulnerability exposure

Understanding the scale of your vulnerability exposure is only the first step. Effective remediation requires knowing where vulnerabilities exist and who is responsible for addressing them. The drilldown identifies the hosts, processes, clusters, and namespaces associated with each finding.

The dashboard shows how findings are distributed across AWS, Google Cloud, Microsoft Azure, and non-cloud environments, down to the individual hosts and processes that require attention. From each table, you can open the corresponding Dynatrace entity view to investigate the affected host or process in context.

The Kubernetes view compares vulnerability exposure in Kubernetes workloads with the rest of the environment and provides breakdowns by cluster and namespace. Filtering by team-owned entities isolates the findings and coverage gaps within that team's scope.

Each table links to the corresponding Dynatrace entity view, so you can move from the dashboard straight into a deeper investigation of the host, process, or Kubernetes entity you are looking at.

Check scan coverage

A low vulnerability count can reflect limited scan coverage rather than limited exposure. The coverage view distinguishes reported findings from gaps in Runtime Vulnerability Analytics coverage.

The coverage section shows which monitored processes of a supported technology are reported as covered or not covered by Runtime Vulnerability Analytics, making gaps in reported coverage easier to identify.

Host coverage helps you identify which hosts with processes of supported technologies are not being scanned at all. A host counts as covered when at least one of its processes is scanned, so the donut chart isolates the hosts where RVA has no presence. To go a level deeper, the host detail table shows how many processes are covered on each host, so you can see where scanning is only partial.

Configured exclusions also appear as not covered, so compare the results with your intended scope.

Focus the view on your exposure

Remediation typically happens team by team. Filtering by team-owned entities isolates the findings and coverage gaps within that team's scope.

Five dashboard variables let you narrow the view to the hosts, clusters, namespaces, and technologies you are responsible for. Hostname, Kubernetes cluster, and Kubernetes namespace accept wildcard patterns, so you can match many entities at once, while Technology and Severity allow multiple selections.

By default, the dashboard shows the current state of your environment, based on the last 30 minutes. Adjust the timeframe to review a historical period and compare how your exposure and scan coverage looked at an earlier point in time.

Frequently asked questions

What is vulnerability risk exposure?

Vulnerability risk exposure describes where reported vulnerabilities affect monitored processes and how widely those vulnerabilities appear across an environment. In this dashboard, exposure is represented through findings, unique vulnerabilities, affected processes, affected packages, and reported severity.

How is scan coverage calculated?

Process coverage shows whether RVA reports a monitored process that uses a supported technology as covered or not covered. A host is counted as covered when at least one eligible process on that host is covered. The host detail table shows how many eligible processes are covered on each host, which helps identify partial coverage.

What is the difference between findings and unique vulnerabilities?

A unique vulnerability is counted once regardless of how many processes it affects. A finding is counted once for each vulnerability-process pair. One unique vulnerability can therefore produce multiple findings when it affects multiple processes.

Why can an intentionally excluded process appear as not covered?

RVA reports configured exclusions as not covered. Compare the coverage results with your intended scanning scope before treating a not-covered process as a coverage gap.

Get started

The Vulnerability risk exposure dashboard is available in the Dynatrace Dashboards app. Open it to review reported findings, affected processes, and RVA coverage across your monitored environment. Use the dashboard filters to isolate the entities your team owns and prioritize remediation based on reported severity, affected processes, and coverage gaps.