What's Actually On the Customer Dashboard: A Walkthrough of the Version-Drift Remediation Roadmap

1. The dashboard problem most scanners solve badly

A scanner without a usable dashboard is a CSV emitter with extra steps. Most vendors ship dashboards that fail in one of two ways. The first failure mode is volume (every finding gets a tile, the screen becomes a 4000-row table sorted by CVSS, and the customer's eyes glaze over within thirty seconds. The second failure mode is over-abstraction) the dashboard reports a single "security score" between 0 and 100, the score drifts up and down based on opaque heuristics, and the customer has no actionable lever to move the score.

The version-drift remediation roadmap is our attempt to thread the needle. The screen is one of the most-used in the customer portal, and the user research informed every element. The remainder of this article walks through the screen, what each element shows, and the decision the customer is meant to take.

2. The hero panel, top three remediation actions

The top of the screen is a three-item panel. Each item is a single concrete remediation, "upgrade nginx to 1.27.4 across 47 assets", "rotate the AWS access key in build-pipeline-v2", "patch rsync to 3.4.3 across 1,842 assets". The three items are the customer's recommended actions for the next 48 hours.

The selection logic is the EPSS-weighted triage score we documented earlier, with a twist. The score is multiplied by an asset-count weight so a fix that closes 50 findings ranks higher than a fix that closes 5 findings of identical per-finding severity. The result is the customer's optimal next move, the action that buys the largest reduction in their open-finding surface per engineering-hour invested.

Each hero item carries three sub-fields: the affected asset count (with a drilldown link that lists the assets), the estimated remediation effort in engineering-hours (derived from the customer's historical patch cadence for the affected component), and a "what breaks if I patch this" risk summary (derived from the patch's changelog and any known breaking-change advisories).

The customer can mark a hero item as "acknowledged" (we know about it, working on it), "scheduled" (it is in our next maintenance window), or "patched" (we shipped the fix; please verify). A patched item disappears from the hero panel and gets verified on the next scan cycle.

3. The drift matrix, versions installed vs versions secure

Below the hero panel is the drift matrix. Each row is a component (nginx, openssl, postgres, jquery, log4j, ...). Each cell is a version. The cells are colour-coded: green for the latest-secure-version, yellow for an EOL or patched-but-stale version, red for a version with at least one unpatched high-severity CVE. The cell content is the count of assets running that version.

The matrix surfaces version sprawl visibly. A row for openssl that has three red cells, two yellow cells, and one green cell tells the customer immediately that they have six different openssl versions running across their fleet, and that one of those versions has a known unpatched CVE. The remediation work is not "patch openssl"; it is "consolidate the customer's openssl install base onto the secure version and prevent regression".

Each red cell links to the affected assets, the projected CVE list for that version, the Proof Capsule for any CVE we have weaponised, and the recommended upgrade target. The customer can launch a re-scan against the affected assets directly from the cell without leaving the dashboard.

The matrix is sortable by component name, by total asset count, by red-cell count, and by triage-score-weighted severity. The default sort is by triage-score-weighted severity, so the components in most urgent need of consolidation rise to the top.

4. The compliance & policy panel

The third panel addresses compliance posture. For each compliance regime the customer is contracted to maintain (PCI DSS, SOC 2, HIPAA, GDPR, industry-specific frameworks), the panel shows the current posture against the relevant controls.

The posture is computed from the findings store via a mapping between CWE classes and compliance controls. For example, CWE-311 (missing encryption of sensitive data) failures map onto PCI DSS Requirement 4 (encrypt cardholder data in transit). When the customer's environment has open CWE-311 findings against assets tagged as in-scope for PCI, the dashboard surfaces the compliance gap directly.

Each compliance gap links to the findings driving it, the affected assets, and the recommended remediation. The customer's compliance team can use the dashboard as their evidence trail during an audit; we generate signed extracts of the panel on demand, with timestamp and Test Capsule references for every finding.

5. The chain panel, composition findings

The fourth panel surfaces chain findings. Chains are findings whose severity exceeds the maximum severity of any constituent member; the panel lists them in a separate view so they do not get lost behind the single-finding queue.

Each chain entry shows the chain shape (e.g. "PII enumeration → credential stuffing → legacy authz bypass"), the constituent findings, the end-state severity, and a one-click "show me the Proof Capsule" link. The customer can break a chain by remediating any constituent finding; the panel highlights the cheapest break point per chain so the engineering team has a clear lever.

A chain that is partially remediated (one constituent fixed, two still open) shows as "broken" in the panel, with the broken status hovering until the next scan confirms the remediation. The customer can see, in real time, the effect of their last patch on the chain space.

6. The change log, what shifted since last scan

The fifth panel is the change log. Every scan emits a diff against the previous scan: new findings, resolved findings, regressions (findings that were previously resolved and have re-appeared), severity shifts (findings whose EPSS or KEV status changed), and coverage changes (tests that did not run on this cycle, with the skip reason).

The change log is the screen the customer's morning standup lives on. The team scans the log, picks the diffs that matter, and routes them into the engineering ticket flow. The log is concise on purpose, the average scan produces 5-15 actionable diffs, not hundreds; we have spent considerable engineering effort on the noise-filtering step so the log shows real changes rather than transient scan jitter.

Regression detection is the load-bearing case. A finding that was patched and is now back tells the customer either that the patch did not stick (deploy rollback, version pin reverted, container image still pulling from a stale cache) or that the affected version was deliberately re-introduced (downgrade, dependency rollback). Both cases warrant immediate attention; the regression row in the log is highlighted and ranked above new findings.

7. The asset-detail drilldown

Every panel above links to per-asset drilldowns. The drilldown is the screen the customer's individual engineer opens when they own the patch for a specific server. The drilldown shows:

• The asset's full layered version stack (server software, framework, library, runtime, base image, kernel).
• The full projected-CVE list with EPSS, CVSS, KEV, and chain-membership signals per finding.
• The Proof Capsule for every finding we have weaponised.
• The Test Capsule for every test that has run against the asset, with verdict, duration, and decision-rule trace.
• The remediation roadmap specific to this asset, with cost estimates and breaking-change risk.
• A "re-scan this asset now" button that triggers an out-of-band scan and refreshes the drilldown within minutes.

The drilldown is what makes the rest of the dashboard actionable. The engineer who owns the asset gets a single screen with every fact relevant to remediation, sourced from signed evidence, with a re-validate-now button to confirm the fix.

8. The decisions the dashboard has made for customers this quarter

The version-drift view shipped to production in late Q1. The first quarter of operation produced measurable outcomes across the active customer base. The aggregate numbers (anonymised per our engagement-handling policy) show:

• Median time-to-remediation for hero-panel findings dropped from 23 days (pre-dashboard) to 6 days (post-dashboard).
• Version sprawl across the install base, measured by the average number of distinct versions per component per customer, dropped by 31 percent.
• Compliance-gap findings closed within the contractually-required windows climbed from 71 percent to 94 percent.
• Customer self-service re-scans (initiated through the dashboard's re-scan button rather than through an account-team request) climbed from 0 (the button did not exist) to roughly 600 per week.

The dashboard is not magic. It is the engineering investment of translating the findings store into a screen that the customer can actually act on. Most vulnerability scanners stop at the findings store. The work to convert findings into a usable interface is what separates a scanner that ships reports from a scanner that ships outcomes.

We will keep iterating. The next major addition is the cross-customer comparison panel, anonymised benchmarks showing the customer's posture against the median of their industry peer group. The customer asked for it, we are building it, and the data discipline to make it work without leaking customer-identifying information is the engineering problem we are solving this quarter.

Verifiable security.