Vulnerability Management: How to Prioritise What to Fix When You Cannot Fix Everything

Every engineering team that runs security assessments regularly faces the same structural challenge: the number of vulnerabilities identified across penetration tests, automated scanning, and dependency analysis is larger than the team's capacity to remediate. Prioritisation is not optional. The question is whether it is done deliberately with a defensible rationale, or implicitly through whichever findings land in front of someone's attention first.

The Common Vulnerability Scoring System (CVSS) is the most widely used starting point for prioritisation. It provides a numerical severity score for known vulnerabilities based on characteristics of the vulnerability itself: how it is exploited, what privileges it requires, what the impact of successful exploitation is. CVSS scores are useful for initial triage and for communicating severity in standardised terms. They are not a complete prioritisation framework because they do not account for context specific to the organisation's environment, the application's deployment configuration, or the actual threat actors likely to target the system.

Why CVSS Is Insufficient as the Sole Prioritisation Criterion

A CVSS critical score indicates that a vulnerability has severe potential impact if exploited under the conditions described in the vulnerability record. It does not indicate whether those conditions exist in the specific environment where the vulnerability is present. A critical-rated dependency vulnerability that is only reachable through an internal administrative function behind multi-factor authentication represents a different real-world risk than the same score on a vulnerability in a public-facing authentication endpoint. The score is the same; the actual priority should not be.

CVSS also does not account for the presence of mitigating controls. A network-based vulnerability with a high CVSS score may be effectively non-exploitable from the perspective of an external attacker if it is behind a firewall that blocks the relevant traffic. That does not mean the vulnerability should be ignored: firewall rules change, internal network access may be broader than intended, and defence-in-depth recommends not relying on a single control. But it does affect the urgency of remediation relative to a vulnerability with the same score that is directly exploitable from the internet with no intermediate controls.

A Practical Prioritisation Framework

A more useful prioritisation framework combines vulnerability severity with three additional dimensions: exploitability in context, asset criticality, and threat relevance. Exploitability in context asks whether the conditions for exploitation exist in the specific deployment: is the vulnerable component internet-facing, is the attack complexity realistic, are there compensating controls in place? Asset criticality asks what the impact of compromise of this specific system would be to the business: a vulnerability in a production payment processing service has a different business impact than the same vulnerability in a development environment.

Threat relevance asks whether the vulnerability class and exploitation method match the threats that are actually active against this type of organisation and application. Organisations that have experienced specific incident types, or that operate in sectors where specific attack patterns are common, should weight vulnerabilities relevant to those patterns more heavily. A financial services application should prioritise credential stuffing and account takeover vectors. An application that handles sensitive personal information should prioritise data exfiltration vectors. The generic severity score does not make those distinctions.

Managing the Backlog

Vulnerability management is an ongoing practice, not a point-in-time exercise. New vulnerabilities are disclosed continuously against software in use, and the backlog grows between assessment cycles if the remediation rate is lower than the discovery rate. Managing that backlog requires a tracking system that provides visibility into the full population of open findings, their age, their status, and who owns them. Findings that live only in penetration test reports are not managed vulnerabilities; they are historical records.

Each finding in the backlog should have an assigned owner, a target remediation date based on its priority tier, and a current status. The priority tier should be reviewed periodically: a medium-priority finding that has been in the backlog for twelve months without remediation may warrant escalation, particularly if the threat landscape has changed or if related vulnerabilities have been exploited in the wild since the finding was first recorded. Ageing should be a factor in prioritisation, not just severity at time of discovery.

The Role of Retest and Verification

Prioritisation determines what to fix first. Verification determines whether the fix was effective. A vulnerability management programme without a retest process produces remediation records that may or may not reflect the actual security state of the application. Developers who believe they have fixed a finding sometimes fix it in one location while leaving it present in another, or apply a fix that addresses the specific instance reported without addressing the underlying pattern that produced it.

Retesting should be scoped to the specific findings that were remediated and conducted against the same environment where the original finding was identified. The retest result is not just a binary pass or fail on the specific finding: it is an opportunity to check whether the fix pattern was applied consistently across similar code paths. When developer training is built from the specific findings that failed retest, the recurrence rate in subsequent assessment cycles drops significantly. We typically see recurrence rates below 15% in retests where that training is in place.

If you want to build a vulnerability management programme that gives you systematic control over your remediation backlog, contact us at info@cyberlinx.com.au.