The CVE volume problem is well documented. NVD publishes hundreds of new CVEs per week. Most operators do not have a security team large enough to read them, let alone act on them. The traditional response is to filter by CVSS severity — show me critical and high — but that filter is famously bad at predicting which vulnerabilities will actually be exploited against the operator's environment. A high-CVSS bug in a niche product the operator does not run is a distraction; a medium-CVSS bug in a load balancer fronting production is the real fire.
Two scoring systems complement CVSS to fix this. EPSS, the Exploit Prediction Scoring System maintained by FIRST.org, returns a probability between 0 and 1 that a given CVE will be exploited in the wild within the next 30 days. KEV, CISA's Known Exploited Vulnerabilities catalogue, is the observed counterpart — a list of CVEs that are being exploited in the wild right now. Used together with CVSS, the three scores cover theoretical severity, predictive likelihood, and observed reality.
The arithmetic is straightforward but operationally consequential. A CVE with CVSS 9.8, EPSS 0.02, and not on KEV is a critical-rated bug that has no observed exploitation and is unlikely to acquire any in the next month. A CVE with CVSS 6.5, EPSS 0.92, and on KEV is a medium-rated bug that is being actively exploited and will continue to be. The second is the higher operational priority, almost always. Yet a CVSS-only triage filter would surface the first and miss the second.
The operator's footprint is the missing dimension. Even with EPSS and KEV layered on, the universe of high-priority CVEs is still larger than the universe of CVEs that affect the operator's specific stack. WYRM Cyber asks the operator to declare its technology footprint — the products, versions, and deployment patterns it actually runs — and then filters the EPSS + KEV stream against that footprint. The output is the CVE subset where (a) the operator runs the affected product, (b) the bug is being exploited or likely to be, and (c) no upstream mitigation has already landed in the operator's patch pipeline.
In practice this collapses the daily firehose to a weekly action list of single digits for a typical mid-market operator. A team that previously could not keep up with the noise can now keep up with the signal, and the difference is not about hiring more staff — it is about scoring the work correctly.
Triaging is one half of the job; remediation tracking is the other. WYRM Cyber maintains a state machine per CVE: surfaced, acknowledged, mitigated, patched, verified-closed. Each transition is logged with timestamps and acting user. The audit trail is reconstructable per CVE and per operator, which is what the cyber-insurance and SOC 2 auditors actually ask for.
A scenario from a recent week. CISA added a Citrix NetScaler vulnerability to KEV after observation of active exploitation against unpatched appliances. EPSS for the underlying CVE had already moved above 0.7 in the prior week. The operator's footprint included a NetScaler in front of a customer-facing application. Cyber surfaced the alert as same-day on Enterprise, linked to the vendor advisory and the published indicators of compromise, and proposed a remediation: patch within 24 hours, apply the temporary mitigation in the meantime, run an attack-surface scan against the appliance to confirm the patch took. The audit trail logged the surfacing time, the acknowledgement time, the patch window, and the verification scan. The whole sequence took under a day; without the triage, it might have taken a fortnight or might not have been spotted at all.
Pro at £19/month covers monthly agentic security sweeps with the EPSS + KEV triage layered against a declared footprint. Enterprise at £49/month moves to weekly sweeps with same-day alerts on KEV additions and dark-web credential findings, plus the team-seat structure for SecOps functions. Cyber is one of WYRM's focused add-on modules, sold alongside the flagship engineering products, WYRM MEP and WYRM Data. Where the cyber posture has to connect to supplier risk and contract obligations rather than living in isolation, Procure (supplier cyber attestation) and Legal (DPA and incident-response clause review) run on the same shared substrate.