Notifications
Clear all
Topic starter
18/08/2026 2:17 pm
TL;DR: CISA’s new directive replaces severity-first vulnerability triage with exposure, reachability, exploitability, and business context, according to LEGIT Security, reflecting a broader shift from counting findings to deciding which ones actually change risk. That matters because finite remediation capacity is now the constraint, not discovery volume.
NHIMG editorial — based on content published by LEGIT Security: CISA made risk-based prioritization federal policy
Questions worth separating out
A: Prioritise by combining exploitability, asset criticality, compensating controls, and process ownership.
Q: Why do high-severity findings often fail to reduce actual risk?
A: High severity often describes theoretical damage rather than reachable damage.
Q: What do security teams get wrong about high CVSS scores?
A: They often treat CVSS as a complete ranking signal.
Practitioner guidance
- Require exposure evidence before remediation assignment Gate high-priority tickets on proof of internet exposure, trusted-path reachability, deployed status, or known exploitation.
- Tie vulnerability queues to identity-bearing assets Map findings to the accounts, tokens, service principals, and administrative workflows they could affect.
- Use KEV and automation as escalation triggers Promote any vulnerability with known exploitation or easy automation into an accelerated workflow, especially when it sits on a customer-facing or privileged path.
What's in the full article
LEGIT Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Its risk-ranking method for combining exposure, reachability, exploitability, and business context into one remediation decision.
- Examples of how the same vulnerability class is prioritised differently in internal tools versus customer-facing services.
- The article's explanation of how AI-generated code and faster exploit development are compressing the remediation window.
- The whitepaper download path for teams that need implementation guidance on AppSec for AI-generated code.
👉 Read LEGIT Security's analysis of CISA risk-based vulnerability prioritization →
Risk-based vulnerability triage: what CISA's new policy means?
Explore further
18/08/2026 3:10 pm
Risk-based prioritisation is now an identity governance problem, not just an AppSec one. Vulnerability triage increasingly intersects with credential exposure, privileged access, and service reachability. If a flaw sits on a path to tokens, accounts, or administrative functions, the business impact is mediated through identity controls as much as code quality. Practitioners should treat prioritisation models as part of the access governance layer, not as an isolated scanner output.
A question worth separating out:
Q: How do organisations decide which vulnerabilities to fix first under risk-based policy?
A: They should fix first the vulnerabilities that are both exposed and exploitable, especially those listed in KEV or attached to privileged workflows. In practice that means pairing scanner results with asset inventory, internet exposure data, and identity context so teams can prioritise the issues most likely to lead to compromise.
👉 Read our full editorial: CISA risk-based vulnerability prioritization changes AppSec triage
