All guides
← All guides

Vulnerability prioritization

Cross-cuttingDraugr: available today

In plain terms#

Run every security control on a real system and you won't get a tidy report, you'll get thousands of findings, a large share labeled "high" or "critical." Vulnerability prioritization is the discipline of turning that flood into a short, ordered list of what deserves attention first. It's the hardest and most valuable problem in application security, because effort is finite and most findings will never be exploited.

Why it matters#

When everything is critical, nothing is. A backlog of 2,000 "criticals" isn't a security program, it's a way to guarantee the actually dangerous ones get lost in the noise. Teams either burn out chasing low-value findings or, more often, tune the whole thing out. Good prioritization is what makes security actionable.

The inputs#

Severity alone (CVSS) is not priority. A useful ranking folds in context the scanner can't see, and these inputs line up neatly with the three CVSS dimensions (base, environmental, temporal):

  • Severity. How bad the issue is in the abstract. (the CVSS base score)
  • Exposure. Is the affected component internet-facing, authenticated-only, internal, or fully restricted? A flaw nobody can reach is a very different risk from one on your login page. (environmental)
  • Criticality. How much the business would feel it if this component were compromised or went down. (environmental)
  • Exploitability. Is it being exploited? (temporal. See EPSS & KEV)

Multiply those together and the list reorders dramatically: a "medium" on a public, business-critical service jumps above a "critical" on an internal batch job.

Where it fits#

Prioritization sits after your controls run and before your team acts, it's the layer that consumes findings from SCA, SAST, image scanning, and the rest, and produces the ranked worklist. It's also where gating decisions live: fail a build only on what matters, not on every warning.

Common pitfalls#

  • Sorting by severity and calling it done. That's the default that creates the backlog problem in the first place.
  • Context that lives only in someone's head. Exposure and criticality have to be captured (ideally as data next to the code) to be usable automatically.
  • Gating too broadly. Blocking every finding trains people to bypass the gate; block on priority, surface the rest.
How Draugr fits. This is Draugr's core idea. You declare each component's exposure and criticality in your app descriptor (or let the draugr classify wizard help), and Draugr ranks every finding into priority bands P1–P4, --min-priority to focus the list, --fail-on-priority to gate CI on only what matters. Severity is just one input; context does the rest. See how Draugr ranks findings in the docs.

Keep learning#