If your service desk gets one ticket for every CVE a scanner finds, the service will fail. The scanner is not wrong. The list is simply too long for anyone to work. The fix is to rank findings by what matters, group them into jobs a person can finish and keep the queue short.

I'm Richard Daly, Partner Lead for the UK and Ireland at Nanitor. This is the second post in a series on what stalls MSP vulnerability management. The first post covers all five problems. Here I take the noisiest one.

Why does one ticket per CVE break a service desk?

A CVE is a public identifier for a known flaw. One flaw can affect many devices, and one device can carry many flaws. Raise a ticket for each pairing and the numbers climb fast.

Picture an MSP with forty clients and a few hundred devices each. One round of monthly updates, and the scanner reports thousands of findings. Your engineers cannot read them all, let alone fix them.

That is when tickets stop meaning anything. If everything is urgent, nothing is. Engineers learn to skim. Clients learn that your alerts are background noise.

Why is the severity score not enough to rank findings?

The CVSS score rates a flaw in general. It knows nothing about your client's estate. A critical flaw on a laptop that sits in a drawer is not the same as a medium flaw on the server that runs payroll.

Good ranking adds context: how likely the flaw is to be exploited, how exposed the system is and how much the asset matters to the business. Nanitor's vulnerability management combines CVSS and EPSS (a score that estimates how likely a flaw is to be exploited) with asset priority.

Nanitor Diamond puts that on one picture. It plots issues by how critical they are and how critical the affected asset is. Priorities run from 1 to 10 and update as conditions change, and unresolved issues rise over time, so nothing sits ignored forever.

Rank by what an attacker could use and what the client would miss.

How do you group findings into work people can finish?

Group by fix, not by flaw. Ten flaws that one update closes are one job.

In Nanitor, remediation management does this with projects. A project covers a set of issues on a set of assets, has one responsible owner and an optional due date. Nanitor detects when an issue is fixed and updates progress, so nobody ticks boxes by hand.

Patch intelligence feeds it. Each missing patch is logged as an issue, ranked by its importance and by how critical the affected assets are. The patch status report can be grouped by asset label, which gives you a per-client view.

A client no longer gets three hundred tickets. They get one project: update the file servers this month.

What should still get its own ticket?

Some things deserve to jump the queue. Set the rules before the scanner sets them for you:

• A severity threshold to start with. Advania, which manages hundreds of client servers, began with issues rated CVSS 7 and above and widened to configuration improvements later.
• A rule of your own for flaws known to be exploited in the wild. Those do not wait for the monthly cycle.
• A recorded exception for risks the client accepts. Give it a review date. Nanitor lets the security team mark an issue as handled through an exception, permanent or for a set period.

Start narrow. Widen the net once the queue is calm.

What does a quieter queue look like?

Fewer items, each with an owner. A short list at the top that matters. Projects that close themselves when the fix lands. A client who hears "we fixed these five things" instead of "we found four thousand".

One honest point about fit. Nanitor does not apply patches. Your RMM or patching tool does that. What Nanitor does is tell you what to fix first and show when it is done.

A short queue with owners beats a long one nobody reads.