Vulnerability management

Vulnerability management is the systematic evaluation of systems, networks, applications and devices to identify the weaknesses an attacker could get in through, understand their reach and rank them by severity. It is done with automated tools and by hand as well, because the two find different things.

Vulnerabilities come from very different places: programming errors, incorrect configurations, missing security updates, or a design that never anticipated that use. Identifying them is only the first half of the work; the second is getting the fix applied and confirmed.

The cycle has five stages. Inventory establishes what exists, and it is the stage that caps the value of every later one, since a host that is not in the inventory is never scanned. Assessment finds weaknesses through authenticated and unauthenticated scanning, configuration review and testing. Prioritisation orders the results. Remediation applies fixes or compensating controls through the teams that own the systems. Verification confirms the fix, on the host, by re-testing rather than by trusting a ticket.

Prioritisation is where a modern programme differs from one built a decade ago. Severity from CVSS is one input. Exploitation probability from EPSS, confirmed exploitation in the KEV catalogue, reachability and asset value are the others, and together they usually produce a very different order of work.

The backlog is the symptom everyone recognises: tens of thousands of open findings, growing faster than they close, so nobody works from the list at all. The cause is almost always prioritisation by severity alone, which produces a queue that is technically defensible and operationally useless.

The second failure is unauthenticated scanning treated as coverage. A scan without credentials sees banners and infers versions, so it misses local flaws entirely and reports things that are not there. Then there is the verification gap, where a finding is closed on the ticket and remains present on the host, which is why a retest is a separate activity with its own evidence.

Finally, the process only covers what has an identifier. Nothing in it will find an authorisation flaw in your own application, which is the difference between this discipline and a penetration test: one manages known defects at scale, the other finds unknown ones in depth.

We are frequently asked to validate a client’s queue, and the useful output is not more findings but fewer: which items are genuinely exploitable here, which are not reachable, and which are false. We also compare their scan results against what we found, since the delta measures whether the tooling is configured correctly. Every engagement ends with a retest so that the closure is evidenced rather than asserted. This is part of how a validated finding differs from a scanner result.