Beyond severity: triaging CVEs by what they actually entail

On 10 June 2026, CISA issued Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk.” It tells federal civilian agencies to stop prioritising patches by severity score and start prioritising by risk. Chris Hughes called it the death of CVSS as federal policy, and we think he is right to welcome it.

Severity was never the whole story

A CVSS score describes how bad a vulnerability could be in the worst imaginable deployment. It says nothing about whether your deployment is that one. When every “critical” is treated as equally urgent, remediation effort gets spread evenly across vulnerabilities that will never be exploited and the few that genuinely matter.

This directive replaces that single number with questions about what a vulnerability actually entails:

• Asset exposure. Is the vulnerable asset publicly exposed?
• KEV status. Is it already known to be exploited in the wild?
• Exploit automation. Can an adversary automate every step needed to exploit it?
• Technical impact. Does exploitation give partial or total control of the asset?

These map to tiered remediation timelines, with the lowest-risk vulnerabilities deferred rather than chased. It is a better way to prioritise, because each question is about real-world risk rather than a theoretical score.

This mirrors how we already think about CVEs

We have long argued that a CVE needs to be understood across more dimensions than severity alone. Reach, exposure, exploitability, and impact all change how much a given vulnerability should worry you. BOD 26-04 formalises much of that thinking into federal policy, which is encouraging to see.

The volume problem is what makes it urgent. With AI now finding flaws across the open-source software that modern development depends on, the number of CVEs keeps climbing, and the directive itself notes that adversaries’ use of AI “may further narrow the time defenders have to react between patch release and possible exploitation.” Triaging by what a vulnerability entails, not just how it scores, is the only way to keep that list manageable.

Runtime context narrows the list further

The directive’s variables describe a vulnerability and its general environment, things that can be published centrally for every CVE. What no central source can tell you is whether the vulnerable code is actually reachable and exercised in your workload.

A container image routinely ships with hundreds of CVEs in libraries that never load and code paths that never run. bifrost learns how each workload normally behaves, then uses that understanding to ask whether an affected component is loaded, whether its code is exercised, and whether an attacker could reach it given how the workload actually runs. That is the dimension that separates a “critical” in dead code from a “medium” on a path that runs on every request.

Find the vulnerabilities you should actually care about

BOD 26-04 moves prioritisation from “how severe is it” to “how risky is it,” and that is the right direction. Adding runtime context takes it one step further, to “is it even reachable in my environment.” Together they let you spend remediation effort on the vulnerabilities that matter for your specific use, rather than on an external score alone.