A vulnerability report is not a work queue. Making it one requires four steps: deduplicate so one shared base image issue is one item rather than three hundred, rank by real exposure rather than CVSS, assign an owner from a live service catalogue, and verify closure by rescanning the rebuilt artifact. Most of the reduction comes from the first two.
What is vulnerability management?
Vulnerability management is the continuous process of identifying security weaknesses across software and infrastructure, prioritising them by the risk they present in your specific environment, assigning them to the teams that can resolve them, and verifying that remediation actually took effect. Scanning produces findings; vulnerability management is what turns them into completed work.
Why the report does not produce action
A first scan of a mid-sized estate typically returns thousands of findings. The list is unusable for three structural reasons, none of which is fixed by better scanning.
- It is mostly duplicates. One vulnerable package in a shared base image produces one finding per service using it.
- It is ordered by severity, which describes the vulnerability in the abstract rather than the risk in your environment.
- It has no owner, so nothing in it is anybody current work.
Deduplicate first: it removes most of the volume
Collapsing findings to one item per distinct vulnerability, with the affected services listed against it, routinely reduces a list by an order of magnitude. It also reveals the efficient fix: three hundred findings that collapse into one base image issue are resolved by one rebuild, not three hundred tickets.
| Before deduplication | After |
|---|---|
| 12,400 findings | ~900 distinct vulnerabilities |
| Sorted by CVSS | Sorted by environmental exposure |
| No owner | Owner from the service catalogue |
| Fix per service | Fix per shared cause |
Rank by exposure, not by severity
CVSS answers how bad this vulnerability could be for anyone. The question you need answered is how bad it is for you, and that depends on context the score cannot know.
- Is the affected workload reachable from the internet, or only from inside a private network?
- Is the vulnerable code path actually loaded at run time, or is it a library function nothing calls?
- Does the workload hold credentials, and what would they grant?
- What data can this workload reach?
- Is there a known exploit in the wild, and is it being used?
Applying these consistently usually reduces the genuinely urgent set to a size a team can clear in a sprint, which is the difference between a programme that works and a report that gets filed.
Ownership and verified closure
A finding without an owner does not get fixed; it gets counted. Ownership needs to come from a service catalogue that is derived from live infrastructure, because a manually maintained mapping is wrong precisely for the newest services.
Closure needs to be verified by rescanning the rebuilt artifact. Two common false closures are worth guarding against specifically: a finding marked resolved without any change, and a fix applied to a running container rather than to the image, which the next deployment silently reverts.
Measuring whether it is working
| Metric | What it tells you |
|---|---|
| Mean time to remediate, by exposure class | Whether the urgent work is actually treated as urgent |
| Backlog trend | Whether you are keeping pace with inflow, which total count does not show |
| SLA adherence per team | Where support or automation is needed |
| Reopen rate | Whether closures are real |
| Share of findings closed by shared-cause fixes | How efficiently the programme works |
Total open findings is the least useful of these, because it moves with scanner coverage as much as with your remediation. Trend and time-to-fix by exposure class are the numbers that describe the programme.
Key takeaways
- Deduplication typically removes an order of magnitude from a raw findings list.
- CVSS describes the vulnerability; exposure describes your risk. Rank on the second.
- Findings without owners get counted, not fixed.
- Verify closure by rescanning the rebuilt artifact, not by trusting a status change.
- Track trend and time-to-fix by exposure class rather than total open count.
Frequently asked questions
Prioritising vulnerabilities by the risk they present in your specific environment (reachability, runtime loading, credential access, data sensitivity and known exploitation), rather than by severity score alone.
Because services share base images and libraries, so one vulnerable package produces one finding per service. Collapsing them into one item with the affected services listed also makes the efficient fix obvious.
It depends on exposure rather than severity alone. A common arrangement is a few days for internet-reachable criticals with known exploitation, and weeks for internal ones. What matters more than the specific number is that the target is set by exposure class and actually tracked.
No, and pretending otherwise makes the programme unmanageable. Some findings are not exploitable in your context. Record those as explicit risk acceptances with a justification, an approver and an expiry date, rather than leaving them permanently open.
A scanner produces findings. Vulnerability management deduplicates them, prioritises by environmental risk, assigns ownership, tracks remediation against targets and verifies closure. The scanner is one input to the process.