// ARTICLE

    Prioritising vulnerabilities: why CVSS is not enough

    CVSS ranks severity. It does not rank your risk.

    Sort your findings by CVSS and the top of the list is a wall of 9.8s. That does not tell you what to fix first. Severity is not the same as risk.

    Prioritisation is about which of those criticals can actually hurt this client, now.

    CVSS is intrinsic, your risk is contextual

    A 9.8 on an internal test box behind three firewalls is not a 9.8 on an internet-facing API. The CVSS base score ignores where the asset lives and who can reach it. On its own it flattens findings that carry very different real risk.

    To prioritise, you have to put that context back.

    Exposure is the first filter

    Is the vulnerable service reachable from where the attacker actually is? An unauthenticated, internet-facing flaw jumps the queue over an equally scored one that needs local access. This single reordering is the most useful thing you can do to a findings list.

    It is also the easiest to defend to a client: this one is exposed, that one is not.

    Known exploitation beats theoretical severity

    CISA's Known Exploited Vulnerabilities catalogue lists what is being exploited in the wild right now. A 7.5 that is in KEV is more urgent than a 9.8 nobody has weaponised. EPSS adds a probability that a vulnerability will be exploited in the next thirty days.

    Together they turn a severity list into a threat-informed one, which is what a decision-maker actually needs.

    The output is a short, ordered list

    After exposure and exploitation, thirty criticals become these four, this week. That is something a client can act on, and it is exactly what a remediation roadmap should look like.

    Prioritisation is not extra work bolted onto the report. It is the point of the report.