Vulnerability Management

Before · scan-first

Work backwards through scans

The old scan-first vulnerability list, filtered to one site, with a remediation status tag toggled by hand on each row

After · vulnerability-first

Act from the first screen

Security360 dashboard with the Remediate Vulnerabilities panel open over it

01 · The problem

Remediation was buried three levels behind the data that signaled the need for it.

Vulnerability Management was built around scans, so technicians worked backwards through scans, sites and devices before they could act.

Found by eye. Technicians scanned the list for an "Available" status to know what was fixable.

Hidden behind a row menu. Only the menu revealed whether the fix was a patch or an external link.

Tracked by hand. Status was a tag users toggled per vulnerability, 2,757 of them on one test site.

02 · Constraints

An IA shift inside a system I couldn't rebuild.

Scan-first data model

The back end stayed organized by scan, so this had to be an IA shift, not a rebuild.

Limited API at MVP

Patch deployment already lived elsewhere, so the new flow had to match it without duplicating it.

Top-down dashboard mandate

Security features had to live in categorized dashboard tabs, a structure that wasn't mine to change.

03 · Key decisions

Three questions reshaped the workflow.

What is the primary unit of work?

Vulnerabilities, not scans. Years of Pendo data showed technicians rarely opened scan details unless forced to, which made a structural change easy to defend.

The list starts with the riskiest item, not the latest scan.

Before · 3 levels

ScanSiteDeviceAct

After · act from the list

Vulnerabilities, ranked by severityAct

Build a new remediation flow, or mirror existing patch tooling?

I aligned with the OS patching tools instead of building something parallel. Limited API access ruled out a separate flow, and reusing the same components made the two feel like one product.

Same components, same words, nothing new to learn.

The Remediate Vulnerabilities panel opening over the Security360 dashboard, using the same tabs, table and Deploy button as the rest of the product — Remediation opens in place over the dashboard, built from the same parts as the rest of the product.

Keep per-vulnerability tracking, or collapse remediation into one decision?

One clear action per patch. Toggling a status on every vulnerability added a step that didn't match the real work, so status now follows the deployment and scans moved into setup.

2,757 manual toggles on one test site became zero.

Vulnerability scans card showing scan results by site and severity, with a Manage Scans button — Scans step back into setup. They still set the cadence, but they're no longer the way in.

04 · The solution

Fix it from where you found it.

1Start with the riskiest

Major risks by severity

CVE-2023-357083 critical
CVE-2024-46712 critical
CVE-2024-47616 high severity
CVE-2024-45583 high severity
CVE-2024-300512 high severity
CVE-2023-222292 high severity

CVE-2024-4671critical

Updated May 16, 2024

80devices at risk

2sites at risk

Windows

CVE-2023-35708critical

Updated June 20, 2023

423devices at risk

5sites at risk

Windows

CVE-2024-30051high severity

Updated May 16, 2024

49devices at risk

5sites at risk

Windows

The riskiest vulnerabilities surface first, with the devices and sites they touch, so the next fix is obvious.

2Pick a patch

Deploying from context: the technician picks a patch by how many critical CVEs it clears, without leaving the dashboard.

Patch Deployment scope step: deploy to all 58 eligible devices or select devices, with company, site and critical CVE columns — One patch, every affected device. Deploy everywhere it lives, or pick devices, with company and site on every row.

Patch Deployment confirm step: mass deployment warning, an acknowledgment checkbox, and options to deploy now, during the reboot window or on a schedule — A mass deployment asks for an explicit acknowledgment, then runs now, in the reboot window, or on a schedule.

Patch Failures tab listing failed patches, two selected for a retry

5Finish what you start

Failures and reboots stay in view

Failed patches and pending reboots sit in their own tabs beside new patches, ready to retry, so a fix gets finished, not just started.

05 · Outcome

What changed

Levels before acting

down from 3: scan, site, device

Technicians act straight from the severity-ranked list.

Manual status toggles

down from 2,757 on one test site

Status now follows deployment state instead of a hand-set tag.

Fixes per deploy

Many

was one at a time

One patch covered 3,058 CVEs in test data.

To finish a fix

1 panel

deploy, retry, reboot

Patches, failures and pending reboots live in one place.