Vulnerability management: prioritising what actually matters

No team fixes every vulnerability its scanner reports, and pursuing that goal guarantees working on the wrong ones. The useful question is not how many there are, but which are reachable from outside and are being exploited today.

What follows: why the list always grows, how to prioritise properly, what requires judgement, and how the process is sustained.

An organisation’s first serious scan produces a number that paralyses: thousands of findings, many marked critical. The usual reaction is to ask for a plan to fix them all.

That plan is not met, and failing it has a side effect worse than the original problem: the team stops looking at the list because it knows the list is unmanageable.

Why the list always grows

New vulnerabilities are published every day, and every component the organisation uses contributes its own. The inventory grows with the business and the catalogue of flaws grows with time.

On top of that, the same vulnerability appears repeated on every affected machine, so the raw count describes the size of the estate more than the size of the risk.

And published severity is generic by design: it describes how serious the flaw would be in the worst possible scenario, knowing nothing about the context it is installed in.

How to prioritise properly

By exposure. A service reachable from the internet and one accessible only from a controlled internal segment do not represent the same risk even when they share the same flaw. Exposure changes the order more than severity does.

By observed exploitation. A known exploitation technique in active use changes urgency entirely. A severe vulnerability with no known exploit can wait for the maintenance window; a moderate one being exploited cannot.

By asset criticality. The same flaw on the system the operation lives from and on an occasionally used workstation do not deserve the same place in the queue.

By availability of mitigation. When patching is not immediately possible, exposure can sometimes be reduced: close a port, restrict access, disable a function. That option should be assessed alongside the patch, not after it.

What requires judgement

Accepting a risk is a business decision and it should be recorded with an owner and a review date. An accepted, documented risk is a defensible position; one accepted by omission is an outstanding finding with nobody accountable.

The remediation window per category also has to be decided. Committing to equal deadlines for everything produces universal non-compliance; deadlines differentiated by exposure and criticality are met, and can be audited.

And it is worth resisting the total-count metric. A number that falls because thousands of irrelevant workstation findings were fixed can coexist with external exposure entirely untouched.

What changes by asset

Traditional infrastructure allows planned maintenance windows and a relatively orderly patching cycle.

In-house applications depend on their third-party components, and there the work is not patching but updating dependencies, which requires testing and coordination with development.

And cloud services divide responsibility: part sits with the provider and part stays on the customer’s side, depending on the type of service. Assuming the provider covers everything is one of the most frequent and least visible omissions.

How the process is sustained

Start with the inventory, because what is not known to exist cannot be prioritised. A scanner run against an incomplete inventory delivers a reassuring and false list.

Define and publish deadlines by category, and measure compliance with those deadlines rather than the total count. That is the indicator that shows whether the process works.

And automate the repetitive: distributing known low-risk patches, verifying they were applied, and reporting. The team’s time should go to the difficult decisions, not to administering the list.

What has to exist first

An asset inventory with owners, a criticality classification agreed with the business, and an agreed maintenance window. Without the third, every fix is negotiated individually and the process stalls.

It is also worth being clear about who decides when patching means interrupting. That decision belongs neither to the security team nor to operations alone, and without an agreed mechanism it gets settled by whoever insists hardest.

The finding usually missing from the report

Scanners report what they know to query, so the report describes the known estate. What rarely appears is what nobody registered: a server stood up for a test, a service exposed by a temporary rule that stayed, an application an area contracted on its own.

Those assets do not appear on the list and are frequently the most exposed, precisely because nobody administers or updates them.

Which is why internal scanning is worth complementing with a view from outside: what can be seen of the organisation from the internet without credentials. That exercise usually finds fewer findings than the scanner, and more relevant ones.

Do all vulnerabilities have to be fixed?

It is neither achievable nor useful as a goal. Prioritise by exposure, observed exploitation and asset criticality, and record explicitly what is accepted.

Is published severity not enough to prioritise?

No. It describes seriousness in the worst possible scenario, without knowing the context. A severe flaw on an isolated system can matter less than a moderate one exposed to the internet.

Which indicator is worth following?

Compliance with the deadlines committed by category, not the total count. The total can fall by fixing irrelevant findings while external exposure remains intact.

Who is responsible for vulnerabilities in the cloud?

It depends on the type of service: part sits with the provider and part stays on the customer’s side. Assuming the provider covers everything is one of the most frequent omissions.