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 change reduces the metadata many SCA tools use to rank vulnerabilities, forcing teams to rethink how CVE prioritisation works.
Why it matters: IAM, AppSec and platform teams need defensible prioritisation because compliance language, remediation queues and risk decisions can no longer rely on NVD-derived severity alone.
Context
The core governance problem is not that vulnerabilities stop existing, but that the common reference data used to prioritise them becomes thinner and less dependable. When severity, version range and reference metadata are missing or inconsistent, security programmes have to make remediation decisions with less confidence and more manual validation.
That creates a practical gap for software composition analysis, vulnerability management and adjacent identity-governance workflows that depend on trustworthy dependency intelligence. The article also matters to NHI governance because software supply chain exposure often turns into credential, token or build-system compromise once attackers reach the wrong dependency path.
Key questions
Q: What breaks when NVD enrichment is no longer available for most CVEs?
A: SCA tools lose the normalised metadata that helps them decide what is affected, how severe it is and whether it should move first. That pushes teams away from a single upstream score and toward contextual signals such as reachability, exploit intelligence and local asset relevance. Prioritisation becomes harder to defend if the tool cannot explain impact clearly.
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 vulnerability prioritisation?
A: Security teams often treat vulnerability scores as if they represent operational risk on their own. In practice, a score only matters when the asset can reach something important. Graph analysis corrects this by showing which weaknesses are connected to critical systems, where lateral movement is possible, and which routes attackers are most likely to use.
Q: How should teams respond when their vulnerability data source changes?
A: They should revalidate compliance language, reassess scoring assumptions and confirm how their tooling sources severity, version data and advisory metadata. The right response is to test whether the new dataset still supports the decisions the programme needs to make, not to assume the old prioritisation logic still holds.
Technical breakdown
Why NVD enrichment mattered to SCA prioritisation
NVD enrichment has acted as the normalising layer between raw CVEs and operational vulnerability programs. It adds severity, version ranges, common weakness context and reference links that downstream scanners use to decide what is affected and what should move first. When that enrichment slows or stops, a CVE becomes closer to an identifier than a decision-ready signal. That shifts the burden from centralised metadata to the consuming tool, which then has to infer impact from less complete inputs. For SCA, the practical effect is noisier triage and weaker comparability across products and teams.
Practical implication: Treat NVD metadata as one input, not the prioritisation engine, and validate whether your scanner can still explain why a finding is actionable.
Why reachability matters more than raw CVSS now
CVSS describes theoretical severity, not whether vulnerable code is actually exercised in a given application path. Reachability analysis narrows the problem by checking whether the vulnerable function, call path or dataflow is present in the deployed build. That makes it more operationally useful for SCA because it reduces false urgency and helps teams focus on exploitable exposure rather than catalogue noise. In the current environment, reachability becomes the context layer that NVD enrichment used to approximate, but with far better decision value when it is done at dependency, function or dataflow level.
Practical implication: Use reachability to separate exploitable dependencies from inventory-only findings before you escalate remediation work.
What dependency data quality now has to cover
A modern SCA data source has to do more than map package names to CVEs. It needs precise dependency resolution, patch metadata, non-CVE advisories and enough structural detail to support analysis beyond a version match. That is especially important when open source disclosure volumes rise faster than central enrichment can keep up. In identity-adjacent environments, weak dependency data can also hide the route from a vulnerable package to higher-value systems, including CI pipelines and secret-bearing workloads. The governance question is no longer whether a scanner can ingest CVEs, but whether it can support a defensible change-control decision.
Practical implication: Ask vendors to show how they resolve dependencies and whether their dataset still supports meaningful impact analysis without NVD enrichment.
NHI Mgmt Group analysis
CVE prioritisation is moving from catalogue-driven to context-driven. The article shows why a long-standing assumption in vulnerability management is breaking down: that centralised severity data is enough to rank remediation. Once enrichment lags, organisations have to rely on reachability, exploit intelligence and local asset context to make defensible decisions. That is a governance change, not just a tooling change. Security teams should stop treating severity as a stable proxy for risk.
Metadata debt: the backlog problem is now a control problem. Nearly 300,000 CVEs moving into Not Scheduled is not just a processing delay. It creates a structural gap between disclosure volume and the quality of the prioritisation signal, which in turn raises the cost of manual triage and exception handling. Programmes that depend on a single upstream source of truth will absorb that debt first. Practitioners should revalidate which data sources are authoritative in their vulnerability workflow.
Software supply chain governance now depends on stronger source-of-truth selection. Choosing between NVD-style catalogue enrichment and advisories or analysis-backed datasets is now a design decision with risk consequences. The field will increasingly split between teams that merely count vulnerabilities and teams that can explain exposure in context. That matters for CI/CD, package governance and any environment where open source intake is tied to production trust. Practitioners should align vulnerability data sources with the decisions those sources must support.
This change also has an identity-security knock-on effect. Vulnerable software often becomes the entry point for token theft, CI compromise and downstream abuse of service accounts and build identities. When prioritisation degrades, those identity-bearing pathways can stay exposed longer than they should. The implication for NHI governance is clear: dependency risk is now part of identity risk, especially in automated build and deployment chains. Practitioners should review where machine credentials sit behind vulnerable dependencies.
What this signals
Metadata debt: vulnerability management teams are now inheriting a growing gap between disclosure volume and the data quality needed to prioritise remediation. The practical answer is to move decisions closer to exploitable context, not to wait for a cleaner catalogue.
SCA programmes that cannot explain why a dependency is actionable will struggle to justify effort, especially as open source disclosure accelerates and central enrichment lags. That makes source-of-truth selection a governance decision, not a procurement detail.
For practitioners
- Update compliance wording and evidence sources Review FedRAMP packages, PCI DSS evidence, customer questionnaires and cyber insurance forms to remove any statement that NVD CVSS is the sole source of truth for prioritisation.
- Shift prioritisation to contextual signals Make KEV, EPSS and reachability the baseline decision stack, then document when a raw CVSS score is only a supporting input rather than the trigger for remediation.
- Challenge SCA vendors on data provenance Ask whether severity comes from CNA assignment, independent calculation or another source, and ask how deep their reachability analysis goes, from dependency level through function and dataflow.
- Re-baseline remediation queues Re-score existing backlogs against exploitable exposure so teams can retire findings that are inventory-only and concentrate on packages that are both reachable and business-relevant.
Key takeaways
- The article shows that prioritisation built on a single enriched vulnerability feed is becoming less reliable as backlog and disclosure volume grow.
- The practical measure of value now is whether a tool can explain exposure, not just whether it can ingest CVEs.
- Teams should re-centre remediation on contextual evidence such as reachability and exploit signals, then update governance language to match.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centres on broken vulnerability inventory and incomplete metadata used for prioritisation. |
| Recommendation — Track dependency inventory quality and validate that scanner inputs still reflect the software actually deployed. | ||
| NIST CSF 2.0 | ID.RA-05 — Threats, vulnerabilities and likelihoods are used to determine risk | The article is about how vulnerability data feeds risk decisions when catalogue enrichment degrades. |
| Recommendation — Rework vulnerability triage so risk decisions combine exploit likelihood, exposure and asset context. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Continuous vulnerability management is the core control area affected by changing NVD enrichment. |
| Recommendation — Base remediation queues on continuously updated exposure signals rather than static CVE scores. | ||
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | The article notes that vulnerable software can become a route to data and credential exposure. |
| Recommendation — Map high-risk vulnerable paths to collection and exfiltration scenarios in your threat modelling. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Vulnerable dependencies can expose secrets and machine credentials in build and runtime paths. |
| Recommendation — Prioritise vulnerable packages that could expose secrets or machine credentials in CI/CD and runtime. | ||
Key terms
- 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.
- Vulnerability Management Prioritization: Vulnerability management prioritization is the operational method for deciding which vulnerabilities enter the remediation queue first. It turns a large and changing set of findings into a ranked plan based on risk, exposure, and impact. Effective programmes use context about assets and systems, not just scan scores, to guide action.
- 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.
- Exploited vulnerability catalog: An exploited vulnerability catalog is a curated list of flaws known to be used in real attacks. It matters because active exploitation changes priority. In practice, it helps security teams separate theoretical risk from issues that require urgent remediation and tighter operational oversight.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity control decisions to broader software and cloud risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org