Triaging and Prioritising Findings With Real Risk Context

Turn on enough scanners and you will drown. A large estate produces more findings than any team can fix, which means the real work of application security is not finding vulnerabilities — it is deciding which of the thousands you already know about actually matter this week. Get that ordering wrong and you spend your scarce remediation capacity on theoretical bugs while a genuinely exploitable one waits its turn in the queue.

The instinct is to sort by severity and work top-down. But a scanner's severity is an intrinsic property of the flaw — how bad it would be if exploited — divorced from your environment. A critical vulnerability in an unreachable code path on an internal tool with no sensitive data may be a lower real risk than a medium in an internet-facing service holding customer records. Severity is an input to prioritisation, not the answer.

The context that turns severity into risk

• Reachability. Does your code actually invoke the vulnerable path? An unreachable flaw is real but not exploitable, and should rank accordingly.
• Exposure. Is the affected component internet-facing or buried behind internal networks and auth? Attack surface changes everything.
• Exploitation in the wild. Is there a known exploit? CISA's Known Exploited Vulnerabilities catalogue and EPSS scores tell you what attackers are actually using versus what merely could be used.
• Data and asset criticality. A flaw touching payment data or a system of record outranks the same flaw in a throwaway service.
• Compensating controls. A WAF rule, network segmentation, or feature flag can already blunt a finding — real, but less urgent.

CVSS is a base, not a verdict

CVSS base scores are widely used and widely misused. The base score deliberately excludes your environment; that is what the environmental and temporal metrics are for, and most teams never populate them. Two newer signals sharpen the picture: EPSS estimates the probability a vulnerability will be exploited in the near term, and the KEV catalogue lists what is being exploited right now. A high CVSS with a near-zero EPSS and no KEV entry is rarely where your first hour should go.

Deduplicate and correlate

Multiple tools will report the same underlying issue in different words, and a raw union of their outputs inflates the backlog with phantom work. Correlate findings across SAST, DAST, and SCA so one root cause is one ticket — and use agreement as signal: a flaw that SAST flags and DAST confirms is not a maybe. Frameworks such as SSVC (Stakeholder-Specific Vulnerability Categorization) give a repeatable decision path from these inputs to a clear action, so triage is consistent rather than dependent on whoever is on rota.

Make the ranking legible

Whatever model you adopt, developers must be able to see why a finding is ranked where it is. “Fix this because it is reachable, internet-facing, and actively exploited” gets acted on; “fix this because the tool said critical” gets argued with. Transparency in the prioritisation is what converts a ranked list into fixed vulnerabilities.

Prioritisation is discovery's second act: once you know what exists, risk context tells you what to do about it first. The estate you can rank by real exploitability is the one you can actually defend — and the finding no one contextualised is the one that sits untouched until an attacker contextualises it for you.