Notifications
Clear all
Topic starter
21/08/2026 4:53 pm
TL;DR: The Cyber Resilience Act turns vulnerability prioritisation into a compliance obligation, with KEVs, EPSS and reachability used to prove what gets fixed first, according to Xygeni. The governance shift is from backlog management to evidence-backed remediation decisions, where exploitable flaws and release controls matter more than raw CVSS scores.
NHIMG editorial — based on content published by Xygeni: Risk Based Vulnerability Management Under the Cyber Resilience Act
Questions worth separating out
Q: What breaks when vulnerability prioritisation relies on exploitability scores alone?
A: Prioritisation breaks when scores are treated as confirmation rather than signals.
Q: Why do known exploited vulnerabilities change compliance obligations?
A: Because they prove real attacker activity, not just potential risk.
Q: How do security teams decide whether an identity CVE is urgent?
A: Security teams should prioritise identity CVEs by whether the affected component sits in authentication, provisioning, admin, or privileged access paths, and by whether it is internet-facing or broadly reachable.
Practitioner guidance
- Implement exploit-aware release gating Block merges or deployments when a reachable KEV is present in the code path, dependency tree, or build pipeline, and require an explicit exception record before release proceeds.
- Tie prioritisation to reachability evidence Use static analysis, dependency mapping, and runtime checks to prove whether a finding is actually reachable before assigning remediation priority or SLA timing.
- Record remediation decisions for auditability Keep logs that show why an issue was fixed, deferred, or accepted, including the KEV match, EPSS signal, exposure context, and approving role.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- Automatic correlation of findings with the CISA Known Exploited Vulnerabilities Catalog
- A practical checklist for blocking merges when reachable KEVs affect active code paths
- Step-by-step examples of EPSS and reachability scoring used together in developer workflows
- How audit logs support CRA evidence when remediation decisions are deferred or approved
👉 Read Xygeni's analysis of risk based vulnerability management under the Cyber Resilience Act →
Risk based vulnerability management under CRA: what teams must prove?
Explore further
21/08/2026 5:11 pm
Risk based vulnerability management is becoming a governance discipline, not just an AppSec workflow. The CRA forces teams to document why one issue is fixed before another, which means prioritisation logic itself becomes auditable evidence. That shifts the conversation from vulnerability counts to defensible decision-making, and security leaders should expect the burden of proof to move into engineering and compliance reviews.
A question worth separating out:
Q: Who is accountable when a transitive dependency vulnerability reaches production?
A: Accountability should be shared but explicit: engineering owns the component graph, security defines policy and monitoring thresholds, and product or platform teams approve remediation priority. Frameworks such as the NIST Secure Software Development Framework and EU Cyber Resilience Act expectations make it clear that supply chain knowledge cannot be an afterthought.
👉 Read our full editorial: Risk based vulnerability management under the Cyber Resilience Act
