Dr. CVE Love, or how I learned to stop worrying and love vuln management

Ben Webb opens with the argument that vulnerability scanner output is mostly noise. Scanners match installed software versions against CVE databases without accounting for configuration, so backup copies and irrelevant findings inflate the totals. He argues that ranking CVEs by severity and handing lists to system owners rarely works, because the queue never empties and new issues keep arriving. He also stresses that vulnerability management cannot replace basic patching and configuration discipline, and that weak results should not be read as a judgment on the team.

The core of the talk is a four-step process. First, build an inventory of technologies with their patch cadences and a full list of scanner findings. Second, rescore those findings using threat intelligence services, which he presents as a practical way to filter out low-value items. Third, rescore again using environmental context such as subnet and business function, since the same flaw matters very differently on a shared desktop and on an isolated server. Fourth, merge the datasets, tracking when each issue was first seen. Removing items already covered by a normal patch cycle, along with findings that will never be fixed, cuts most of the volume.

What remains points to real work: systems that fall outside the patch cycle, orphaned hosts missing from asset records, and misconfigurations repeated across many machines. For reporting, he recommends trend-based KPIs such as moving averages, SLA breaches, documented exceptions, systems without a patch process, and unidentified IP addresses, rather than raw CVE totals. The practical takeaway is to choose the highest-value fix available now and accept that the work never finishes.