What's Missing From Vulnerability Data

Vulnerability scan data is useful.
It tells you what devices are identifiable in your environment and the vulnerabilities associated with each of them. It tells you what might be wrong.

But it also points out something else.

It points out that you need data you don’t have.

A scan gives you CVEs, severity, and affected systems. What it doesn’t give you is what you actually need to act on it.

What patch addresses a given vulnerability is almost never clear.

In practice, it starts the same way. A system has findings. The administrator goes to the vendor site, applies the latest patch, and hopes it clears everything.

This is the first step in what we call “patch and pray.” Apply the patch, pray it addresses the vulnerabilities in the report so you can move on to the next set of issues.

Sometimes it does.
Sometimes it doesn’t.

When it doesn’t, you start digging through advisories, trying to match patches to findings. Was this patch cumulative? Did it address my vulnerability, or do I need another patch? If it’s cumulative and it did address the issue, will the auditors accept the vendor’s note?

Much of that information exists, but digging it out takes some sleuthing.

It’s not in the scan results.
And it’s almost never inside the environment.

It lives in vendor advisories and patch catalogs that aren’t directly connected to what you’re looking at.

So you’re left to piece it together.

That’s where most of the time and effort go. Not fixing the issue, but figuring out what the issue actually is and where the fix lies.

So the work gets done with what’s available.

At that point, findings are handled one at a time. Severity drives priority. And the same issues show up again next cycle.

It’s not because the teams don’t know what they’re doing.

It’s because the inputs aren’t complete.

The scan is still useful.

It just isn’t the whole picture.