TL;DR: NIST’s move to end enrichment for most open source vulnerabilities leaves nearly 300,000 backlogged CVEs in “Not Scheduled,” weakening the severity and version data that many SCA tools use for prioritisation, according to Semgrep. The shift makes reachability, KEV, and independently validated metadata central to defensible vulnerability management.
At a glance
What this is: NIST’s NVD enrichment changes leave a large backlog of CVEs without the contextual data many SCA tools rely on for prioritisation.
Why it matters: Security teams now need to validate how vulnerability intelligence, dependency reachability, and downstream workflows are sourced because raw CVSS and incomplete CPE data no longer provide enough decision quality.
👉 Read Semgrep's analysis of the NVD enrichment changes and SCA prioritisation
Context
NVD enrichment has long acted as the translation layer between a vulnerability identifier and an operational decision. When that layer weakens, vulnerability management becomes less about the presence of a CVE and more about whether the organisation can still determine exposure, exploitability, and business impact from other sources.
For identity and access teams, the immediate issue is not just patch workflow. It is whether software composition analysis, asset inventory, and risk prioritisation still produce reliable action when the primary public reference source is incomplete, delayed, or self-reported by the software vendor itself.
Key questions
Q: What breaks when vulnerability enrichment becomes delayed or selective?
A: Prioritisation breaks first. Teams still receive CVEs, but incomplete product mappings, inconsistent severities, and missing references slow triage and stall automation. The result is not a lack of findings. It is a lack of confidence in what should be fixed first, which expands remediation queues and weakens SLA enforcement.
Q: Why should teams use reachability instead of raw CVSS alone?
A: Raw CVSS measures theoretical severity, not whether the vulnerable code can actually be invoked in your application. Reachability connects the finding to deployed behaviour, so teams can focus on exploitable paths rather than every dependency that merely contains a weakness. It reduces false positives and improves engineering trust.
Q: What do security teams get wrong about central vulnerability databases?
A: They often treat the database score as an objective fact rather than one input in a broader decision process. When enrichment is incomplete or backlog grows, that assumption fails. The right approach is to combine independent severity intelligence, exploit signals, and environment-specific reachability before setting remediation order.
Q: How should organisations decide what to patch first after disclosure backlogs grow?
A: Use a layered model that starts with known exploitation, then checks exposure and reachability, then applies business criticality. This avoids overreacting to every CVE while still elevating issues that are actually reachable in production. The goal is defensible prioritisation, not perfect completeness.
Technical breakdown
Why NVD enrichment mattered to SCA prioritisation
NVD enrichment added the metadata that made CVEs operational: CPE strings for version matching, CVSS for severity ranking, CWE for weakness classification, and reference URLs for triage. Software composition analysis tools often consumed those fields as a baseline signal, then layered inventory mapping or policy on top. When enrichment stops, the CVE remains a record, but much of the context needed to decide whether a package is actually relevant disappears. That shifts the burden to the downstream tool to infer impact from other sources, which is harder, noisier, and easier to dispute.
Practical implication: Practitioners need to test whether their SCA platform can still prioritise without NVD-provided context.
Why reachability beats raw severity scores
Reachability asks whether vulnerable code paths can actually be invoked in the deployed application, rather than whether a package merely contains a vulnerable component. That makes it a more useful prioritisation signal than a severity score alone because it ties the finding to application behaviour. In practice, reachability can be analysed at dependency, function, or dataflow level, each with different accuracy and noise trade-offs. The deeper the analysis, the more evidence a team has that a vulnerability is real in context, not just present in a manifest.
Practical implication: Teams should align reachability depth with application criticality and developer tolerance for false positives.
What happens when CVSS becomes self-reported
If the CVSS score is assigned by the CNA or software vendor rather than validated by a central enrichment process, the score may reflect the reporter’s incentives as much as the vulnerability’s practical risk. That does not make the score useless, but it does make it unsuitable as the sole prioritisation input. In a backlog-heavy environment, relying on self-reported severity can create systematic under-prioritisation, especially when the issue is complex, exploitable, or embarrassing for the publisher. Security teams need independent corroboration before they treat the score as authoritative.
Practical implication: Use self-reported severity as one input, not the deciding control for remediation order.
Threat narrative
Attacker objective: Exploit delayed or misprioritised remediation to increase the window in which vulnerable software remains exposed.
- Entry occurs when a newly disclosed vulnerability is published without enriched context, leaving tools to ingest an ID instead of a decision-ready record.
- Escalation happens when version matching or severity ranking fails, causing exploitable issues to blend into backlog noise or be deprioritised incorrectly.
- Impact is delayed remediation, weaker compliance evidence, and higher exposure to vulnerabilities that should have been fixed earlier.
NHI Mgmt Group analysis
Security programmes are moving from enrichment dependence to evidence dependence. When the public vulnerability pipeline stops providing complete severity and version data, teams can no longer assume that a CVE record is operationally meaningful on its own. The real control becomes whether the organisation can corroborate exploitability through reachability, asset context, and threat intelligence. That shifts vulnerability management from catalogue consumption to evidence synthesis.
NVD backlog pressure exposes a prioritisation trust gap. Many programmes built their remediation logic around an external score that looked objective but was only as stable as the enrichment service behind it. Once that service cannot keep pace, the score loses its authority as a universal triage anchor. Security leaders should treat this as a governance issue, not a tooling inconvenience, because remediation policy based on stale or incomplete signals is fragile.
Reachability-based prioritisation is becoming the defensible default. The strongest signal in modern application security is not whether a package has a CVE, but whether vulnerable code can be reached in the deployed path. That is especially true when backlog growth and vendor-assigned severity can distort the queue. Programmes that can prove reachable exposure will defend their decisions better to engineering, audit, and insurance stakeholders.
NVD dependency is now a supply chain risk in its own right. When downstream SCA platforms rely on a single enrichment source for core fields, any structural delay becomes a scaling problem for every customer in the chain. This is where identity and access programmes should pay attention too: the same governance pattern appears whenever a security control depends on a central service that cannot reliably validate what it distributes. Practitioners should verify where their authoritative risk data actually comes from.
Context collapse: this change shows what happens when a record remains but the operational meaning disappears. CVE volume can still rise, but if exploitability, version mapping, and reference quality are missing, teams are left with an identifier rather than a decision. Practitioners should measure whether their workflows can still separate signal from backlog noise without external enrichment.
What this signals
The next operational test is whether vulnerability programmes can still produce trustworthy decisions when upstream enrichment is partial. That pushes teams toward layered signals, stronger asset context, and explicit ownership for remediation criteria, especially where application teams consume SCA data through CI/CD gates.
Enrichment dependency: when a security workflow relies on a single upstream source to normalise risk, any delay becomes a governance problem, not just a data quality issue. Organisations should map where that dependency exists and pair it with independent checks, including exploit intelligence and environment-specific reachability.
For identity-heavy environments, the same lesson applies to machine identities and service accounts: if your inventory or control plane cannot see the asset clearly, it cannot prioritise it well. That is why programmes should connect vulnerability operations to the broader visibility and lifecycle discipline described in the NHI Lifecycle Management Guide.
For practitioners
- Audit vulnerability policy language Review FedRAMP, PCI DSS, cyber insurance, and customer questionnaire language that treats NVD CVSS as the sole source of truth. Update the wording so it reflects the actual prioritisation inputs your programme uses.
- Move to multi-signal prioritisation Adopt KEV, EPSS, and reachability together so remediation decisions do not depend on a single upstream score. This is especially important for large dependency graphs where backlog noise can obscure real exposure.
- Interrogate SCA data sources Ask vendors whether their scores are CNA-assigned or independently calculated, and whether their reachability analysis stops at dependency, function, or dataflow level. Those details determine how much false noise your developers will see.
- Validate backlog handling procedures Check how your team handles vulnerabilities that arrive without complete CPE, CVSS, or reference data. If the workflow cannot triage these records without manual escalation, it will break under a larger disclosure volume.
Key takeaways
- NVD enrichment gaps turn CVEs into incomplete records, which weakens severity-based prioritisation across SCA programmes.
- Reachability, KEV, and independently validated metadata now matter more than raw CVSS when teams need defensible remediation order.
- Security leaders should update policy language, verify data sources, and connect vulnerability response to stronger asset and identity visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007 , Discovery; TA0040 , Impact | The article focuses on reducing exposure to exploitable vulnerabilities before attackers can weaponise them. |
| NIST CSF 2.0 | ID.RA-1 | Risk assessment depends on trustworthy vulnerability intelligence and prioritisation signals. |
| NIST SP 800-53 Rev 5 | SI-2 | SI-2 covers flaw remediation, which is directly affected when enrichment data degrades. |
| CIS Controls v8 | CIS-7 , Continuous Vulnerability Management | Continuous vulnerability management requires reliable enrichment and prioritisation to be effective. |
Use ATT&CK to map which disclosed issues are discoverable and likely to become impact-bearing in your environment.
Key terms
- Vulnerability enrichment: The process of adding context to a disclosed vulnerability so teams can prioritise it correctly. Enrichment typically includes severity, affected products, exploitation status, reference intelligence and business context, but it is only useful if the organisation can act on it quickly enough.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- CNA-assigned CVSS: A CVSS score assigned by the CVE Numbering Authority, often close to the software publisher’s own assessment. It can be useful, but it should not be treated as the only authoritative signal because it may not reflect independent validation or environment-specific impact.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- How Semgrep Supply Chain uses reachability to reduce SCA noise across dependency, function, and dataflow analysis
- Why the team chose GitHub Security Advisories over NVD as a source of truth for prioritisation
- What to change in compliance language when NVD CVSS is no longer a dependable authority
- How practitioners should question vendor data provenance after the NVD enrichment shift
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It is designed for practitioners who need to connect identity governance with broader security operations.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
