Vulnerability Management Guide: CVSS, EPSS and KEV

Most vulnerability management programmes are good at producing findings and poor at reducing the risk those findings describe. Scanners report tens of thousands of issues, tickets are opened and closed, and yet the internet-facing appliance with a known exploited flaw stays vulnerable because nobody owned it, the scanner could not log in to it, or the fix was marked done without being checked. This guide covers the whole programme: asset scope, scanning types, prioritisation inputs, remediation SLAs, exceptions and risk acceptance, ownership, verification, reporting and metrics. It is written for vulnerability management leads, infrastructure and cloud teams, and the security managers who set their targets and report on them.

Key takeaways

• Scope comes before scanning. A vulnerability you cannot map to an asset and an owner is a finding that will never be fixed; reconcile inventory sources before tuning the scanner.
• Authenticated scanning is the baseline. CIS Safeguard 7.5 requires both authenticated and unauthenticated internal scans, and NIST SP 800-40 Rev. 4 notes that unauthenticated scans generally underreport.
• Prioritise on exploitation and exposure, not base score. Use KEV, EPSS, SSVC and CVSS v4.0 Threat and Environmental metrics together, and route by internet exposure and business impact.
• Close on verification, not on ticket status. A finding is remediated when a rescan or endpoint telemetry confirms the fix has taken effect, and temporary mitigations stay tracked until replaced.
• Scanner credentials are privileged non-human identities. An account that can log in to every server to look for weaknesses is a target in its own right; vault, scope and monitor it.

What the programme covers

Vulnerability management is the continuous cycle of finding weaknesses, deciding which matter, fixing or mitigating them, and proving the fix worked. The NCSC structures its guidance around six principles: update by default, respond to active exploitation, identify your assets, assess by triaging and prioritising, have the organisation own the risk of not updating, and verify and review the process. CIS Control 7 turns this into seven safeguards, from a documented process (7.1) to monthly remediation (7.7).

Three neighbouring disciplines have their own guides:

• Patch management is the main remediation route: deployment rings, platform settings, emergency patching and rollback. See the Patch Management Guide.
• Exploited and zero-day vulnerabilities need an accelerated path with compromise assessment. See the Zero-Day and Exploited Vulnerabilities Guide.
• Attack surface management finds the internet-facing assets your inventory does not know about. See the Attack Surface Management Guide.

Asset scope, CVE and CPE: why findings go missing

Every finding rests on two joins: a CVE record to a product, and a product to an asset you own. Both fail more often than teams expect.

• CVE records: Common Vulnerabilities and Exposures (CVE) IDs are assigned by CVE Numbering Authorities (CNAs), typically software vendors, coordinators and researchers acting within an agreed scope. Downstream databases add scores and product mappings.
• CPE and the NVD: the NIST National Vulnerability Database enriches CVE records with CVSS scores and applicability statements written in Common Platform Enumeration (CPE). CPE is "a standardized method of describing and identifying classes of applications, operating systems, and hardware devices", defined by four CPE 2.3 specifications: Naming, Name Matching, Dictionary and Applicability Language. A well-formed CPE name is bound to a formatted string such as cpe:2.3:a:vendor:product:version:..., and the Official CPE Dictionary in the NVD lists accepted names. Tools that match inventory to CVEs through CPE miss anything whose name does not match.
• The NVD backlog: NIST reports that CVE submissions "increased 263% between 2020 and 2025" and that a significant backlog of unenriched CVEs built up from early 2024. In April 2026 NIST moved to risk-based enrichment: KEV-listed CVEs are prioritised with a goal of enrichment within one business day, and backlogged CVEs published before 1 March 2026 were placed in a "Not Scheduled" category. Tools relying only on NVD data will miss newer CVEs; ask suppliers how they handle unenriched CVEs.
• Configuration weaknesses: not every exposure has a CVE. Misconfigurations (SMB signing off, weak TLS, default credentials) are scored with frameworks such as the Common Configuration Scoring System (CCSS, NIST IR 7502), which is derived from CVSS, or by benchmark checks written in the Open Vulnerability and Assessment Language (OVAL). Keep them in the same queue.

To find assets your scanners miss, reconcile four sources monthly: the CMDB, endpoint management and EDR agent lists, cloud inventories via API, and network discovery (DHCP leases, discovery sweeps, external ASM). An asset in any source but not in the vulnerability tool is a coverage gap. NIST SP 800-40 Rev. 4 says inventories built from periodic vulnerability scans "should no longer be used" and recommends near-continuous, automated inventory instead.

Scanning types and when to use each

Most estates need a mix: agents for endpoints and cloud instances, authenticated network scans for servers and appliances that cannot run agents, unauthenticated external scans for the attacker's view, and image scanning in pipelines. Open-source scanners such as OpenVAS, which supports "unauthenticated and authenticated testing" from a daily-updated feed, suit small estates; larger ones need a platform that merges several sources. For cloud-native estates, see the CNAPP Guide.

Track authentication success per host: a credentialed scan that fails to log in quietly degrades to an unauthenticated one, and the dashboard looks cleaner, not worse. Fix container findings by rebuilding from an updated base image and redeploying, never by patching a running container.

Prioritisation: turning findings into a queue

Risk-based vulnerability management (RBVM) starts from the fact that Common Vulnerability Scoring System (CVSS) base scores describe intrinsic severity only. FIRST's CVSS v4.0 specification is explicit that consumers "should enrich the Base metrics with Threat and Environmental metric values", and labels scores by what they include: CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE. A CVSS-B 9.8 on an isolated test server matters less than a KEV-listed 7.5 on a VPN gateway. CVSS v2 carried this context in Environmental metrics such as Collateral Damage Potential; v4.0 uses security requirements and modified base metrics.

A workable routing order:

1. Known exploited: CISA KEV listing, which requires a CVE ID, "reliable evidence" of exploitation in the wild and a clear remediation action, or a vendor or national CERT exploitation notice. These go to the emergency route.
2. Likely to be exploited: the Exploit Prediction Scoring System (EPSS) estimates "the probability that a published CVE will be exploited in the wild in the next 30 days" and is published daily. FIRST warns it should "never be treated as a risk score"; it is the threat input only. NIST's proposed Likely Exploited Vulnerabilities (LEV) metric (CSWP 41) aims to complement EPSS and measure how complete KEV-style lists are.
3. Exposure and impact: internet-facing, reachable by many users, or on systems that hold credentials or crown-jewel data. The NCSC tells organisations to prioritise vulnerabilities "in services or applications that are internet facing" and those with the largest negative impact.
4. Decision: SSVC (developed by the Carnegie Mellon SEI with CISA) converts exploitation status, technical impact, automatability, mission prevalence and public well-being impact into Track, Track*, Attend or Act.

Signal detail and thresholds are in the Zero-Day and Exploited Vulnerabilities Guide. For programme design, attach asset context (exposure, criticality, owner) before scoring, or every signal collapses back to "fix all criticals".

Remediation SLAs by priority and exposure

SLAs should depend on both priority and exposure. The table is an example to adapt; the 14-day figures align with CISA BOD 22-01 (two weeks for KEV entries) and UK Cyber Essentials (critical and high updates within 14 days of release). Platform-level patch timing is covered in the Patch Management Guide.

Start the clock at fix release or KEV listing, not first detection, or a slow scan cadence silently extends every SLA. Re-tier automatically when a vulnerability enters KEV or its EPSS rises sharply.

Exceptions and risk acceptance

The NCSC is direct: the decision not to fix "is, at root, a senior-level business risk decision, not an IT problem", and "the business owns the risk, not the security team". Its triage guidance uses three states: Fix (record a fix date; a vendor workaround must be "time-bounded and actively tracked"), Acknowledge (recorded with a planned review date and added to the risk register if high) and Investigate ("only be used as a temporary status"). NIST SP 800-40 Rev. 4 frames the options as accept, mitigate, transfer or avoid.

Every exception record should hold:

• Scope: the CVE or finding, the exact assets, and why the standard fix cannot be applied.
• Compensating controls: segmentation, removed internet exposure, disabled feature, WAF rule or allowlisting, each with evidence that it is in place.
• Risk owner: a named business owner at the level your risk policy requires, not the engineer who raised it.
• Expiry: a hard end date (for example 90 days) after which the exception lapses and the finding re-enters SLA tracking.
• Triggers: automatic review if the CVE enters KEV or the asset becomes internet-facing. Never accept a known exploited vulnerability on an internet-facing system.

Remediation workflow and ownership

Tickets per finding are why programmes close tickets without reducing risk: one missing cumulative update can produce hundreds of CVE findings, and engineers close tickets that a later scan reopens. The NCSC recommends first grouping "all similar findings together, or findings that require the same mitigation". Group by fix (one update, one image rebuild, one configuration change) and by owning team, and you reduce the backlog without adding headcount.

Derive the owning team automatically from asset tags, cloud account, CMDB service or image repository. Unowned findings go to a triage queue reviewed weekly, because they are the ones that age past every SLA. Give false-positive disputes a fast path back to the scanner team.

Verification: when the asset is still vulnerable after patching

SP 800-40 defines verification as "confirming that the patch is installed and has taken effect", noting that "automated means are generally needed to achieve verification at scale". Close a finding only on evidence: an authenticated rescan, agent telemetry or a targeted check.

If an asset is still vulnerable after the patch was deployed, work through the causes in order:

1. Not active: the update installed but the host has not restarted, or the service still loads the old library.
2. Partial fix: the vendor fix requires an extra step, such as a registry key, configuration change or follow-on update, which the deployment did not apply.
3. Another copy: a second installation, bundled runtime or container image carries the vulnerable component.
4. Detection error: the scanner's check is wrong; raise it with the vendor with evidence.
5. Prior compromise: if the flaw was exploited before the fix, the patch does not remove the attacker. Hand to the SOC for a compromise assessment, revoke sessions and rotate any secrets the flaw exposed. See the Incident Response Guide.

Third-party penetration tests, which the NCSC suggests, and breach and attack simulation check periodically that fixes hold. See the Breach and Attack Simulation (BAS) Guide.

Where identity fits: scanner credentials are privileged NHIs

Authenticated scanning typically needs local administrator rights on Windows and root or sudo on Linux, on every host in scope. That makes the scanning account one of the most widely privileged non-human identities in the estate, and a scanner logging in to a compromised host can expose its credential. NIST SP 800-53 control RA-5(5) addresses privileged access for vulnerability scanning directly.

• Separate accounts by zone: one scanning account per security zone or tier (workstations, servers, domain controllers, DMZ), so one exposed credential does not unlock everything. Deny interactive and remote desktop logon. See the Service Account Security Guide.
• Vault and rotate: store scan credentials in a privileged access vault that the scanner retrieves from at scan time, and rotate them on a schedule and after any scanner compromise. See the Secrets Management Guide.
• Restrict where they work: limit Linux scan keys with the from= option in authorized_keys and a sudoers rule scoped to the commands the scanner needs; prefer Kerberos to NTLM on Windows.
• Cloud scanners: use read-only cross-account roles with short-lived credentials rather than long-lived access keys.
• Monitor use: alert when a scanning account logs on outside scan windows, from a host that is not a scanner, or interactively.
• Treat security tools as supply chain: scanners in CI pipelines hold tokens and run on every build. In the Trivy supply chain attack, a stolen PAT and an incomplete rotation turned a security scanner into a credential stealer. Pin scanner versions and scope pipeline tokens.

Implementing the programme

1. Start small and critical: the NCSC advises starting with critical systems only, then scaling up. Pick internet-facing assets and identity infrastructure first.
2. Fix scope and ownership: reconcile inventory sources, tag every asset with an owning team and exposure, and publish the coverage gap.
3. Pilot credentialed scanning: scan a pilot group in a maintenance window with safe checks only, and watch fragile systems (older appliances, OT and medical devices). Roll back by removing the group from the scan policy and using agent or passive methods for fragile assets.
4. Publish policy and SLAs: agree priority tiers, SLAs, exception rules and the risk acceptance authority with senior leadership before reporting compliance against them.
5. Automate routing: connect the scanner to ticketing so grouped findings route to owners, closing only on verified rescans.
6. Report and tune: report monthly, review false positives and exceptions, and tighten SLAs as performance improves, as the NCSC feedback loop suggests.

Small versus large organisations: a small organisation can rely on automatic updates, agent-based scanning from its endpoint or cloud platform and a monthly external scan. A large one needs a dedicated team, a platform merging multiple scanners and asset sources, automated ownership routing and a formal exception board.

Reporting and metrics

SP 800-40 warns that "metrics that are too simple are generally not actionable" and recommends measuring the percentage of assets remediated by each deadline, with mean and median time. Report these monthly, by priority tier and owning team:

• Coverage: percentage of inventoried assets scanned in the last cycle, and percentage of credentialed scans that authenticated successfully.
• SLA compliance: percentage of findings in each tier remediated and verified within SLA.
• Mean and median time to remediate (MTTR): from fix release or KEV listing to verified closure. Report the median alongside the mean, which a few old findings can distort.
• Exposure window: days each known exploited vulnerability stayed open on internet-facing assets; the target is zero past SLA.
• Reopen rate: findings reopened after closure, which shows closure without verification.
• Exception health: open exceptions, expired exceptions and exceptions on internet-facing assets.

Avoid headline counts of open vulnerabilities: they rise when coverage improves and fall when scans fail.

Framework mapping

Common failure patterns

• Silent credential failure: scans stop authenticating after a password change and the dashboard improves while coverage collapses.
• Edge devices outside scope: VPNs and appliances are scanned unauthenticated or not at all, yet they are the most exploited assets, as the Ivanti Connect Secure exploitation showed.
• Base-score prioritisation: teams chase every CVSS 9+ internal finding while a KEV-listed medium on an internet-facing server waits a month.
• Mitigation treated as remediation: a WAF rule or configuration workaround closes the ticket with no expiry. In the ShinyHunters FBI breach claim, an unpatched PeopleSoft server was allegedly the entry point; the breach itself has not been confirmed.
• Permanent exceptions: risk acceptances with no expiry or owner become the oldest vulnerabilities in the estate.
• Over-privileged, unmonitored scanner accounts: one domain-wide credential used by every scan, never rotated and never alerted on.

Practitioner checklist

• Reconcile CMDB, endpoint, cloud and network discovery sources monthly and give every asset an owning team and exposure tag.
• Run authenticated scans or agents on all servers and endpoints, and track authentication success per host.
• Scan external assets monthly or more, internal assets at least quarterly, and container images on every build.
• Prioritise using KEV, EPSS, SSVC and CVSS-BTE with asset exposure attached before scoring.
• Publish SLAs by priority and exposure, starting the clock at fix release or KEV listing.
• Require expiry dates, compensating-control evidence and a named business risk owner for every exception.
• Group findings by fix and owner, and auto-close only on verified rescans.
• Vault, zone and monitor scanner credentials; deny interactive logon.
• Report coverage, SLA compliance, median time to remediate and KEV exposure window monthly.

Standards and references

• NCSC: Vulnerability management guidance
• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CIS: Control 7, Continuous Vulnerability Management
• CISA: Known Exploited Vulnerabilities
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: CVSS v4.0 Specification Document
• FIRST: Exploit Prediction Scoring System (EPSS)
• NIST: National Vulnerability Database updates

Related NHI Mgmt Group resources: Patch Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Attack Surface Management Guide · Service Account Security Guide · Secrets Management Guide