12.4 Vulnerability Databases and Their Gaps¶

Software composition analysis tools are only as good as the vulnerability data they reference. When you scan your dependencies for known vulnerabilities, you're querying databases that catalog security flaws—but these databases have significant limitations. Vulnerabilities may not have identifiers assigned for weeks or months. Severity scores may be incorrect or missing. Some flaws never receive formal identifiers at all. Understanding these gaps is essential for interpreting scan results and building effective vulnerability management programs.

This section surveys the vulnerability database landscape, examining how vulnerability information is collected, enriched, and distributed—and where the system falls short.

The CVE System¶

The Common Vulnerabilities and Exposures (CVE) system provides standardized identifiers for publicly known security vulnerabilities. Maintained by MITRE Corporation under funding from CISA, CVE has been the foundation of vulnerability management since 1999.

How CVE Works:

1. Discovery: Someone identifies a security vulnerability
2. Request: A CVE Numbering Authority (CNA) is contacted to assign an identifier
3. Assignment: CNA assigns a CVE ID (format: CVE-YYYY-NNNNN)
4. Publication: After coordinated disclosure, CVE details are published
5. Reference: Security tools, advisories, and patches reference the CVE ID

CVE Numbering Authorities (CNAs):

CNAs are organizations authorized to assign CVE IDs:

• Root CNAs: MITRE, CISA (coordinate CNA program)
• Vendor CNAs: Microsoft, Google, Red Hat, Apache (assign for their own products)
• Third-party CNAs: GitHub, Snyk, CERT/CC (assign for others' products)
• Scope: Each CNA has defined scope for what they can assign

As of early 2026, there are nearly 500 CNAs from over 40 countries across different sectors.¹

CVE Limitations:

Assignment Delays:

The time from vulnerability discovery to CVE assignment varies significantly:

• Well-resourced projects: Days to weeks
• Smaller projects: Weeks to months
• Disputed vulnerabilities: May never receive CVE

Research has found median assignment times of approximately 35-50 days for many vulnerability types.²

Coverage Gaps:

Not all vulnerabilities receive CVEs:

• Some maintainers fix vulnerabilities silently without requesting CVEs
• Vulnerabilities in abandoned projects may never be reported
• Malware and malicious packages typically don't receive CVEs (they're not "vulnerabilities")
• Quality issues and design flaws may not qualify

Process Bottlenecks:

• CNAs may have backlogs
• Disputes between reporters and vendors can delay assignment
• Coordinated disclosure timelines don't always align with CNA capacity
• Some products lack clear CNA coverage

Security researchers frequently report significant delays between vulnerability discovery and CVE assignment, with gaps of several months leaving organizations unable to systematically scan for known issues during critical windows.

The National Vulnerability Database (NVD)¶

The National Vulnerability Database (NVD), maintained by NIST, enriches CVE records with additional analysis and metadata.

NVD Enrichment:

When CVE publishes a vulnerability, it contains basic information. NVD adds:

• CVSS scores: Severity ratings using Common Vulnerability Scoring System
• CPE identifiers: Common Platform Enumeration for affected products
• CWE classification: Common Weakness Enumeration categories
• References: Additional links and technical details

The NVD Enrichment Crisis:

Industry Response:

The NVD crisis accelerated adoption of alternative vulnerability data sources and prompted structural changes:

• CISA Vulnrichment Program: CISA launched a community-driven initiative to supplement NVD enrichment, enabling organizations to contribute vulnerability metadata directly⁴
• OSV adoption surge: Organizations shifted to OSV.dev for ecosystem-native vulnerability data with faster enrichment (covered below)
• Vendor-maintained databases: GitHub Advisory Database, Snyk, and commercial sources became primary rather than supplementary
• CISA KEV catalog: The Known Exploited Vulnerabilities catalog provided prioritization independent of NVD scoring

The crisis demonstrated that resilient vulnerability management requires multiple data sources—no single database should be a single point of failure in your security posture.

NVD Enrichment Performance:

Analysis of NVD enrichment delays shows baseline performance was consistent until the 2024 crisis:⁵

The data shows NVD maintained approximately one-week median enrichment delays from 2021-2023. The 2024 crisis caused median delays to triple to three weeks, with the 90th percentile extending to 16+ months. By 2025, median delays recovered near baseline, though the 90th percentile remained elevated, indicating a persistent backlog for some CVEs.

CPE Mapping Challenges:

Common Platform Enumeration (CPE) identifiers specify which products are affected. CPE mapping is error-prone:

• Package names don't always match CPE naming conventions
• Multiple CPEs may apply to one vulnerability
• CPE may be too broad (false positives) or too narrow (false negatives)
• Open source packages often have inconsistent CPE assignment

Studies have found CPE mapping errors affect 15-25% of NVD records.⁶

OSV: Open Source Vulnerabilities¶

OSV (Open Source Vulnerabilities) emerged from Google as an ecosystem-focused alternative to the CVE/NVD system.

OSV Design Philosophy:

• Ecosystem-native: Uses package manager identifiers, not CPE
• Affected ranges: Specifies exactly which versions are vulnerable
• Distributed: Multiple databases feed into OSV
• Schema-based: Standardized JSON format for interoperability

OSV Schema:

{
  "id": "GHSA-xxxx-xxxx-xxxx",
  "summary": "SQL injection in example-package",
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "example-package"
      },
      "ranges": [
        {
          "type": "SEMVER",
          "events": [
            {"introduced": "1.0.0"},
            {"fixed": "1.5.3"}
          ]
        }
      ]
    }
  ],
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
    }
  ]
}

OSV Data Sources:

OSV aggregates from multiple ecosystem-specific databases:

OSV Advantages:

• Package identifiers match what developers actually use
• Version ranges are precise (not approximated from CPE)
• Faster than NVD for many open source vulnerabilities
• Machine-readable format designed for automation

OSV Limitations:

• Not comprehensive across all ecosystems
• May not include proprietary software
• Depends on ecosystem maintainers to submit data
• Less established than CVE for compliance purposes

GitHub Security Advisories¶

GitHub Security Advisories (GHSA) provides vulnerability information for GitHub-hosted projects.

How GHSA Works:

1. Maintainers create private security advisories
2. Advisory reviewed and CVE optionally requested (GitHub is a CNA)
3. Advisory published with fixes
4. Dependabot alerts users with affected dependencies

GHSA as Data Source:

GHSA has become a significant vulnerability data source:

• Over 25,000 advisories across multiple ecosystems⁷
• Directly integrated with over 420M repositories hosted on GitHub⁷
• Powers Dependabot vulnerability alerts
• Feeds into OSV database

GHSA vs. CVE Relationship:

• GHSA can include CVE ID when available
• GitHub can assign CVE IDs (as a CNA) for advisories that need them
• Some GHSA advisories exist without CVE IDs
• GHSA often has data before NVD enrichment completes

Dependabot Data:

Dependabot uses GHSA plus additional sources:

• GHSA reviewed advisories
• npm security advisories
• RubyGems advisories
• PyPA advisory database
• NVD (with limitations)

This multi-source approach provides better coverage than NVD alone.

CISA Known Exploited Vulnerabilities (KEV) Catalog¶

The CISA Known Exploited Vulnerabilities (KEV) Catalog⁸ is a curated list of vulnerabilities that are actively being exploited in the wild. Unlike comprehensive vulnerability databases that catalog all known vulnerabilities, KEV focuses specifically on those that have been observed in real attacks.

KEV Characteristics:

• Active exploitation required: Every entry has evidence of active exploitation
• Federal mandate: US federal agencies must remediate KEV vulnerabilities by CISA-assigned due dates
• Remediation-focused: Entries include due dates and expect action, not just awareness
• Curated, not comprehensive: Approximately 1,500 entries (as of early 2026), far fewer than NVD's 200,000+

KEV Integration Value:

KEV Limitations:

• Conservative inclusion: Exploits may occur before CISA confirms and adds them
• US-centric: Focus on threats to US federal systems; may miss attacks targeting other regions
• No severity gradation: All KEV entries require action—no differentiation between widespread and targeted exploitation
• Package mapping challenges: CVE-centric, requires mapping to specific packages

Integrating KEV into vulnerability management:

# Example: Flag KEV vulnerabilities in CI/CD
kev_check:
  runs-on: ubuntu-latest
  steps:
    - name: Download KEV catalog
      run: |
        curl -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

    - name: Check for KEV matches
      run: |
        # Compare SCA findings against KEV catalog
        ./check-kev-matches.sh vulnerabilities.json kev.json

Organizations should treat KEV matches as automatic escalations: these are not theoretical risks but vulnerabilities confirmed to be under active attack.

Commercial Vulnerability Databases¶

Commercial vendors maintain proprietary vulnerability databases that supplement public sources.

Snyk Vulnerability Database:

• Coverage: 25+ ecosystems, including containers and IaC
• Research: Dedicated security research team finds vulnerabilities
• Speed: Often has data before CVE assignment
• Enrichment: Custom severity scores, exploit maturity, fix availability
• Malware: Includes malicious package detection

Sonatype OSS Index:

• Coverage: Maven, npm, PyPI, NuGet, and others
• Quality scores: Component quality metrics beyond vulnerabilities
• Policy: License and security policy combined
• Integration: Nexus repository integration

Mend (formerly WhiteSource) Database:

• Coverage: 200+ languages and package managers
• Prioritization: Effective severity based on reachability
• Remediation: Automated fix recommendations

Commercial Database Advantages:

The Business Model:

Commercial vendors invest in:

• Security researchers who find vulnerabilities proactively
• Analysts who enrich and verify data
• Automation that processes disclosures quickly
• Relationships with project maintainers

This investment enables faster, more complete data—at a cost.

Coverage Gaps¶

Significant categories of security issues lack coverage in vulnerability databases.

Vulnerabilities Without CVEs:

Research suggests many security fixes never receive CVEs:

• Studies of project commit histories frequently find security-relevant fixes without CVE references
• Small projects are less likely to request CVEs
• "Silent fixes" are common in projects without security processes

Malicious Packages:

Traditional vulnerability databases focus on flaws in legitimate software, not intentional malware:

• Typosquatting packages typically don't receive CVEs
• Compromised maintainer accounts aren't "vulnerabilities"
• Backdoors inserted by attackers aren't in NVD

Malicious package detection requires different data sources (see Book 1, Chapter 6 for detailed coverage of malicious package attacks).

Quality and Design Issues:

Some security-relevant issues don't fit vulnerability definitions:

• Insecure defaults
• Missing security features
• Deprecated cryptographic algorithms
• Unmaintained dependencies

These affect security but may not appear in vulnerability databases.

Ecosystem Coverage Disparities:

Some ecosystems have better vulnerability coverage than others:

Less popular ecosystems and native code have significant gaps.

Data Quality Challenges¶

Even when vulnerabilities are in databases, data quality issues affect utility.

Reachability Matters:

Not all vulnerabilities in your dependencies are actually exploitable. Endor Labs' research⁹ found that fewer than 9.5% of vulnerabilities in open source dependencies have a reachable call path from the application to the vulnerable function. This finding, based on analysis across Java, Python, Rust, Go, C#, .NET, Kotlin, and Scala, suggests that organizations without reachability analysis are likely drowning in false positives—spending time on vulnerabilities that cannot actually be triggered in their applications. Tools that incorporate function-level reachability analysis can dramatically reduce remediation noise while focusing attention on genuinely exploitable issues.

Severity Discrepancies:

Different sources often assign different severity scores:

CVE-2026-XXXXX:
  NVD CVSS:    9.8 (Critical)
  Snyk:        7.5 (High)
  GHSA:        8.1 (High)

These discrepancies arise from:

• Different interpretation of CVSS criteria
• Vendor-specific scoring adjustments
• Incomplete information at scoring time
• Legitimate disagreement about exploitability

Affected Version Inaccuracies:

Version range information is frequently wrong:

• CPE versions may not match actual package versions
• Backported fixes create complex affected ranges
• Fixed versions may introduce regressions
• Version ranges may be over-inclusive (causing false positives)

Duplicate and Conflicting Entries:

The same vulnerability may appear multiple times:

• CVE-XXXX-1234 and GHSA-yyyy-yyyy-yyyy for same issue
• Different databases may not reconcile duplicates
• Conflicting severity or affected version information

Staleness:

Some database entries become outdated:

• New affected versions discovered after initial publication
• Fix status changes
• Additional context emerges

Not all databases update entries consistently.

Multi-Source Strategies¶

Given database limitations, effective vulnerability management requires multiple data sources.

Recommended Approach:

┌──────────────────────────────────────────────────────────┐
│                     Vulnerability Data                   │
├──────────────┬──────────────┬──────────────┬─────────────┤
│     NVD      │     OSV      │     GHSA     │ Commercial  │
│  (baseline)  │ (ecosystem)  │  (GitHub)    │ (research)  │
└──────┬───────┴──────┬───────┴──────┬───────┴──────┬──────┘
       │              │              │              │
       └──────────────┴──────────────┴──────────────┘
                              │
                    ┌─────────▼─────────┐
                    │   Aggregation &   │
                    │   Deduplication   │
                    └─────────┬─────────┘
                              │
                    ┌─────────▼─────────┐
                    │   Prioritization  │
                    │   & Validation    │
                    └───────────────────┘

Source Selection Criteria:

Handling Conflicts:

When sources disagree:

1. Severity: Use most severe or context-appropriate score
2. Affected versions: Use most specific (usually ecosystem-native)
3. Fix availability: Verify against actual package releases
4. Existence: If any reputable source reports it, investigate

Tooling Considerations:

Evaluate SCA tools on their data sources:

• What databases does the tool query?
• How quickly does data appear after disclosure?
• Does it include malicious package detection?
• How are conflicts resolved?
• What's the false positive/negative rate?

Recommendations¶

For Security Practitioners:

1. Don't rely on single sources. NVD alone is insufficient. Use tools that aggregate multiple databases.

2. Understand tool data sources. Know where your SCA tool gets vulnerability data. Evaluate coverage for your ecosystem.

3. Account for delays. Vulnerabilities exist before they're in databases. Monitor security mailing lists and project advisories directly for critical dependencies.

4. Validate findings. Database errors are common. Verify affected versions against actual project releases before remediation.

For Tool Evaluators:

1. Test with recent vulnerabilities. Check if tools detected recent high-profile vulnerabilities promptly.

2. Evaluate ecosystem coverage. Ensure the tool covers your primary ecosystems well.

3. Assess malware detection. If malicious package detection matters, verify the tool addresses it.

4. Compare severity approaches. Understand how tools score vulnerabilities and whether they align with your risk tolerance.

For Organizations:

1. Budget for commercial data. Public sources alone leave gaps. Commercial databases provide meaningful additional coverage.

2. Monitor NVD status. The 2024 crisis showed risks of depending on a single government resource. Track NVD health and have alternatives.

3. Contribute to ecosystem databases. If you find vulnerabilities, report them properly. Contribute to the data quality you depend on.

4. Build context into prioritization. Raw database severity isn't enough. Add exploitability, exposure, and business context.

Vulnerability databases are essential infrastructure for supply chain security, but they're incomplete and imperfect. Understanding their limitations helps you build vulnerability management programs that account for gaps rather than assuming comprehensive coverage that doesn't exist. The goal isn't perfect data—it's informed decisions despite imperfect data.