Notifications
Clear all
Topic starter
20/08/2026 6:10 pm
TL;DR: Known-exploit intelligence shifts AppSec from severity-led backlog management to exploit-led decisioning, with Xygeni arguing that reachability, KEV status, and EPSS together help teams separate theoretical risk from vulnerabilities attackers are actually using, while the Cyber Resilience Act turns that distinction into a compliance requirement. The practical implication is that vulnerability programmes now need governance around exploit context, not just scanner volume.
NHIMG editorial — based on content published by Xygeni: Known-exploit intelligence and risk based vulnerability management under the Cyber Resilience Act
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when exploit timelines are shrinking?
A: Prioritisation should combine exploitability, reachability, internet exposure, identity proximity, and business criticality.
Q: Why do known-exploited vulnerabilities change remediation decisions?
A: Because they replace guesswork with evidence of attacker behaviour.
Q: What do teams get wrong when they prioritise vulnerabilities only by score?
A: They assume a high score equals the right work.
Practitioner guidance
- Define exploit-led remediation tiers Classify vulnerabilities into blocked, expedited, monitored, and deferred based on KEV presence, EPSS, and application reachability so queues reflect attacker reality.
- Add release gates for reachable known exploits Stop merges or releases only when a known exploited vulnerability is both present and reachable in the affected code path, build step, or runtime service.
- Align exception handling to compliance evidence Require documented business justification, compensating controls, and expiry dates for any deferred known exploit so audit evidence is complete.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- The exact KEV, EPSS, and reachability decision flow used to rank findings in developer workflows
- How the platform blocks or permits merges when a reachable exploit is detected
- The remediation automation logic for suggesting safe upgrades and reducing manual triage
- The CRA-oriented handling model for release gating and exploit reporting
👉 Read Xygeni's analysis of known-exploit intelligence and CRA-driven prioritisation →
Known-exploit intelligence and CRA: what AppSec teams need now?
Explore further
20/08/2026 6:46 pm
Known-exploit intelligence is the missing control layer between scanner noise and real attacker exposure. Most vulnerability programmes still treat findings as a ranking exercise, which means they optimise for volume reduction instead of attacker relevance. That gap is why teams patch the loudest issues while exploitable paths remain open. For practitioners, the discipline shift is to treat exploit confirmation as a governing signal, not an enrichment field.
A question worth separating out:
Q: Who is accountable when a vulnerability report misses an exploitable issue?
A: Accountability sits with the programme owner who accepted the testing model and closure criteria, not only with the tester. If the organisation chose snapshots over continuous validation, the control gap is governance-led. Security leaders, application owners, and risk owners all need clear closure standards and evidence requirements.
👉 Read our full editorial: Known-exploit intelligence is reshaping AppSec prioritization
