29.3: Coordinated Vulnerability Disclosure Ecosystem¶

When a security researcher discovers a vulnerability in an open source library used by thousands of applications, a complex coordination challenge begins. The researcher must notify maintainers who may be volunteers with no security background. Maintainers must develop fixes without public disclosure alerting attackers. Downstream consumers need notification and time to update. The vulnerability must be documented in databases that security tools can query. At each step, miscommunication or delay can result in either premature exposure or unnecessarily prolonged risk.

The coordinated vulnerability disclosure ecosystem has evolved to manage this complexity, providing infrastructure for identifying vulnerabilities, coordinating fixes, and disseminating information to affected parties. This ecosystem includes centralized identifiers (CVE), distributed databases (OSV, GitHub Advisory Database), coordination platforms (VINCE), and the policies and practices that govern how participants interact. Understanding this ecosystem—its capabilities, limitations, and ongoing evolution—is essential for anyone discovering, fixing, or responding to vulnerabilities in the software supply chain.

CVE and the CVE Program¶

The Common Vulnerabilities and Exposures (CVE) program provides standardized identifiers for publicly known cybersecurity vulnerabilities. Launched in 1999 by MITRE Corporation with U.S. government sponsorship, CVE has become the foundation of vulnerability management, enabling consistent communication about specific vulnerabilities across tools, databases, and organizations.

How CVE works:

Each CVE identifier (e.g., CVE-2021-44228 for Log4Shell) uniquely identifies a vulnerability. A CVE record includes:

• CVE ID: Unique identifier
• Description: Brief vulnerability description
• References: Links to advisories, patches, and related information
• Affected products: Products and versions containing the vulnerability

CVE identifiers enable: - Consistent vulnerability references across organizations and tools - Correlation of information from multiple sources - Tracking of remediation status - Historical records of vulnerabilities

Program challenges:

The CVE program faces ongoing challenges that affect its utility:

Scale: The volume of vulnerabilities has grown dramatically. According to CVE Program metrics, over 40,000 CVEs were published in 2024—a 38% increase from 28,818 in 2023—averaging 108 CVEs daily. This marks the seventh consecutive year of record-high CVE publications. Processing this volume with quality and timeliness strains program resources.

Timeliness: CVE assignment and publication can lag vulnerability discovery, sometimes by weeks or months. During this gap, security tools cannot identify affected systems using CVE-based queries.

Coverage: Not all vulnerabilities receive CVEs. Some maintainers don't request them; some vulnerabilities fall into contested categories; some remain uncoordinated. The result is incomplete coverage of the vulnerability landscape.

Quality: CVE descriptions and affected product information vary in quality and completeness. Some entries lack sufficient detail for effective vulnerability management.

Funding uncertainty: The CVE program has faced periodic funding concerns, raising questions about long-term sustainability of this critical infrastructure.

Recent evolution:

The CVE program has evolved to address these challenges:

• Distributed assignment: CVE Numbering Authorities (CNAs) now assign most CVEs, reducing centralized bottlenecks
• JSON format: Structured CVE data in JSON format enables better machine processing
• Automation: Improved automation for submission and processing
• Community engagement: Increased engagement with open source communities

Despite challenges, CVE remains essential infrastructure—the closest thing to a universal vulnerability identifier the industry has.

CVE Numbering Authorities¶

CVE Numbering Authorities (CNAs) are organizations authorized to assign CVE identifiers within defined scopes. The CNA model distributes CVE assignment across hundreds of organizations, enabling faster, more scalable vulnerability identification.

CNA hierarchy:

• CVE Program Root: MITRE serves as the program root, overseeing the CNA ecosystem
• Root CNAs: Manage CNAs within their scope (e.g., CISA for U.S. government, JPCERT/CC for Japan)
• Top-Level Roots: Major CNAs that can recruit and manage sub-CNAs
• Regular CNAs: Organizations assigning CVEs within their defined scope

CNA scopes:

CNAs have defined scopes determining what vulnerabilities they can assign CVEs for:

• Product-based: Assign CVEs for their own products (e.g., Microsoft for Windows vulnerabilities)
• Open source project-based: Assign CVEs for specific open source projects (e.g., Apache Software Foundation for Apache projects)
• Third-party coordination: Assign CVEs when coordinating disclosure for others (e.g., CERT/CC)
• Vulnerability disclosure platforms: Assign CVEs for vulnerabilities reported through their platforms (e.g., HackerOne)

Becoming a CNA:

Organizations can become CNAs by:

1. Identifying a scope not covered by existing CNAs
2. Demonstrating capability to handle vulnerability information
3. Applying through the CNA onboarding process
4. Agreeing to CNA operational rules

Open source projects and foundations should consider becoming CNAs if they regularly handle vulnerabilities in their projects. CNA status enables faster CVE assignment and greater control over vulnerability information.

Open source CNAs:

Major open source organizations serving as CNAs include:

GitHub's CNA role is particularly significant—when maintainers publish security advisories through GitHub, GitHub assigns CVEs automatically, dramatically simplifying the process for projects hosted on the platform.

The Linux kernel CNA experience:

The Linux kernel's achievement of CNA status in February 2024 demonstrates both the value and challenges of distributed CVE assignment. With CNA authority, the kernel security team adopted an aggressive transparency approach: nearly every bug fix that could conceivably have security implications receives a CVE identifier.

The impact has been dramatic. In 2023, the Linux kernel received 290 CVE assignments. In 2024—the first full year as a CNA—that number exploded to 3,529 CVEs, a more than 12-fold increase. By mid-2025, the kernel had already accumulated over 5,530 CVEs, maintaining a rate of approximately 8-9 new CVE assignments per day. To put this in perspective: the kernel now generates more CVEs in two weeks than it did in all of 2020.

This "every bug gets a CVE" philosophy creates significant challenges for the security community:

CVE flood impacts:

• Triage overload: Security teams must now process thousands of kernel CVEs annually, many of which affect only specific configurations or have minimal real-world impact
• Signal-to-noise degradation: Critical vulnerabilities get lost among routine bug fixes assigned CVE identifiers
• Tool overwhelm: Vulnerability scanners flag thousands of kernel CVEs, requiring extensive filtering and prioritization
• CVE fatigue: The sheer volume makes it difficult to maintain vigilance about genuinely critical issues

Organizations have adapted through risk-based prioritization, automated triage systems, and selective tracking of CVEs affecting their specific kernel configurations. But the kernel's CNA approach demonstrates that more transparency doesn't automatically translate to better security outcomes—and that vulnerability disclosure systems can become overwhelmed by well-intentioned comprehensiveness.

The kernel team's approach is technically defensible: any code change could have security implications, and comprehensive disclosure provides maximum information. But the operational reality is that security teams lack capacity to meaningfully process thousands of routine CVEs alongside critical vulnerabilities. The lesson for other projects considering CNA status: transparency is valuable, but sustainable processes and proportionate severity assessment matter more than maximum CVE assignment.

OSV Schema and Distributed Databases¶

While CVE provides identifiers, the Open Source Vulnerabilities (OSV) schema provides a modern, machine-readable format specifically designed for open source vulnerability information. Developed by Google and now an OpenSSF project, OSV addresses limitations in legacy vulnerability formats.

OSV design principles:

• Package-centric: Identifies affected software by package ecosystem and name, not vague product descriptions
• Precise version specification: Uses version ranges, commit ranges, or specific version lists
• Machine-readable: Designed for automated processing from the start
• Decentralized: Enables distributed databases with aggregation
• Developer-friendly: Structured for easy integration with development tools

OSV record structure:

{
  "id": "GHSA-jfh8-c2jp-5v3q",
  "modified": "2021-12-14T00:00:00Z",
  "published": "2021-12-10T00:00:00Z",
  "aliases": ["CVE-2021-44228"],
  "summary": "Remote code injection in Log4j",
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {"introduced": "2.0.0"},
            {"fixed": "2.15.0"}
          ]
        }
      ]
    }
  ],
  "references": [...]
}

This structure enables tools to programmatically determine whether a specific package version is affected—something difficult with unstructured CVE descriptions.

OSV databases:

Multiple databases publish vulnerabilities in OSV format:

• GitHub Advisory Database: Vulnerabilities from GitHub security advisories
• Go Vulnerability Database: Go-specific vulnerabilities
• Python Advisory Database: PyPI vulnerabilities
• RustSec Advisory Database: Rust ecosystem vulnerabilities
• FreeBSD OSV Database: FreeBSD vulnerabilities (migrated from VuXML in 2024-2025)
• OSV.dev: Aggregates vulnerabilities from multiple OSV-format sources

FreeBSD's OSV migration:

The FreeBSD Foundation's migration to OSV format in 2024-2025 demonstrates the practical benefits of standardization. FreeBSD historically maintained vulnerabilities in VuXML, a FreeBSD-specific XML format developed in the early 2000s. While functional, VuXML's proprietary structure meant FreeBSD vulnerabilities couldn't be easily consumed by tools designed for other ecosystems.

The OSV migration, supported by funding from Germany's Sovereign Tech Agency, included:

• Creating an OSV database for FreeBSD vulnerabilities
• Adding OSV parsing capability to the pkg package manager
• Developing conversion tools to transform legacy VuXML data to OSV
• Enabling pkg audit to consume OSV data directly

This migration allows FreeBSD vulnerabilities to be integrated into cross-ecosystem vulnerability scanning tools, security platforms, and SBOM analysis systems without custom parsers. Organizations running FreeBSD systems can now use the same vulnerability management tools they use for other platforms, and security vendors can support FreeBSD without implementing VuXML parsers.

The FreeBSD experience illustrates a broader trend: ecosystems migrating from legacy proprietary formats to OSV for better tool interoperability and ecosystem integration.

OSV.dev aggregation:

OSV.dev aggregates vulnerabilities from participating databases, providing a unified API for querying vulnerabilities across ecosystems:

# Query OSV.dev for vulnerabilities
curl -X POST "https://api.osv.dev/v1/query" \
  -d '{"package": {"name": "log4j-core", "ecosystem": "Maven"}}'

This aggregation enables tools to check for vulnerabilities across all major ecosystems through a single interface.

GitHub Advisory Database:

The GitHub Advisory Database has become a primary source for open source vulnerability information:

• Curated database of security vulnerabilities
• Covers npm, pip, Maven, NuGet, RubyGems, and other ecosystems
• Powers Dependabot alerts and security updates
• Accepts community contributions for new advisories
• Automatically assigns CVEs through GitHub's CNA role

When maintainers create security advisories in GitHub, the advisory automatically receives a GitHub Security Advisory ID (GHSA) and, upon publication, a CVE. This integration dramatically simplifies vulnerability documentation for GitHub-hosted projects.

Coordination Platforms¶

Coordinating vulnerability disclosure—especially when multiple parties are affected—requires infrastructure beyond email chains. Coordination platforms provide structured environments for managing multi-party disclosure.

VINCE:

VINCE (Vulnerability Information and Coordination Environment) is CERT/CC's coordination platform for managing multi-party vulnerability disclosure. VINCE provides:

• Secure communication between researchers, vendors, and coordinators
• Case tracking through disclosure lifecycle
• Coordinated disclosure scheduling
• Status tracking for affected vendors
• Publication automation

VINCE is particularly valuable for vulnerabilities affecting multiple vendors—such as protocol vulnerabilities or flaws in widely-forked software—where coordinating dozens of parties would otherwise be chaotic.

GitHub Security Advisories:

GitHub's private security advisories enable coordinated disclosure for GitHub-hosted projects:

1. Researcher reports vulnerability through repository's security policy
2. Maintainer creates private security advisory
3. Maintainer develops fix in private fork
4. Advisory is published simultaneously with fix
5. CVE is automatically assigned

This workflow keeps vulnerability details private during fix development while providing structured coordination between researcher and maintainer.

Platform comparison:

Coordination challenges:

Even with platforms, coordination faces challenges:

• Identifying affected parties: Determining all downstream consumers of vulnerable software
• Contact information: Finding security contacts for affected projects
• Response variability: Different parties respond at different speeds
• Embargo discipline: Preventing premature disclosure
• Timeline disagreements: Balancing researcher and vendor interests

Disclosure Policy Debates¶

Vulnerability disclosure policies remain actively debated, with legitimate perspectives on multiple sides.

Disclosure timeline debates:

The core tension: How long should maintainers have to fix vulnerabilities before public disclosure?

Arguments for shorter timelines (30-60 days): - Pressure motivates faster fixes - Users deserve timely information about risks they face - Attackers may independently discover the same vulnerability - Extended embargoes protect vendors at user expense

Arguments for longer timelines (90+ days): - Complex fixes require time for proper development and testing - Volunteer maintainers cannot always respond quickly - Rushed fixes may introduce new vulnerabilities - Coordinating across multiple vendors takes time

Industry norms:

• Google Project Zero: 90 days, with extensions for active remediation
• CERT/CC: 45 days default, extensions available
• Many researchers: 90 days has become common expectation
• Some vendors: Request 6+ months for complex issues

Researcher rights:

Researchers face their own considerations:

• Recognition: Desire for credit and professional reputation
• Safety: Protection from legal threats for good-faith research
• Autonomy: Right to publish findings after reasonable period
• Compensation: Bug bounties or other recognition for work

The security community generally supports researcher rights to publish after a reasonable disclosure period, though "reasonable" remains contested.

Best practices emerging:

Despite ongoing debates, some practices have broad support:

• 90 days as reasonable default for most vulnerabilities
• Extensions for active remediation when vendor is making progress
• Shorter timelines for actively exploited vulnerabilities
• Researcher credit in advisories and CVE records
• Legal safe harbors for good-faith security research

Improving Coordination¶

Effective vulnerability coordination requires effort from all participants.

For security researchers:

1. Follow project security policies: Use SECURITY.md-specified channels
2. Provide complete information: Include reproduction steps, affected versions, and impact assessment
3. Be patient but set expectations: Communicate your disclosure timeline clearly
4. Coordinate on timing: Work with maintainers on publication date
5. Request CVE assignment: Ensure vulnerabilities are properly tracked

For maintainers:

1. Publish security policies: Create SECURITY.md with contact information
2. Respond promptly: Acknowledge reports within 48 hours
3. Communicate status: Keep researchers informed of progress
4. Request CVEs: Ensure vulnerabilities are properly identified
5. Credit researchers: Acknowledge their contribution publicly

For organizations:

1. Monitor vulnerability databases: Subscribe to advisories for your dependencies
2. Establish response processes: Define how you'll handle vulnerability notifications
3. Consider CNA status: If you regularly handle vulnerabilities, become a CNA
4. Contribute to databases: Submit vulnerabilities you discover to appropriate databases
5. Support coordination infrastructure: Fund platforms and programs that enable coordination

For the ecosystem:

Improving coordination requires continued investment in:

• Automation: Tools that reduce manual coordination burden
• Standardization: Common formats and processes across ecosystems
• Training: Education for maintainers on vulnerability handling
• Funding: Sustainable resources for coordination infrastructure
• Legal protection: Safe harbors for good-faith security research

Recommendations¶

We recommend the following practices for participants in the vulnerability disclosure ecosystem:

1. Use OSV-format databases for programmatic vulnerability checking, leveraging the precision of package-centric vulnerability information

2. Become a CNA if your organization regularly handles vulnerabilities, enabling faster CVE assignment and greater control

3. Publish SECURITY.md files in all repositories, providing clear vulnerability reporting instructions

4. Adopt GitHub Security Advisories for projects hosted on GitHub, taking advantage of private forks, CVE assignment, and Dependabot integration

5. Default to 90-day disclosure timelines as a reasonable balance between vendor needs and user protection

6. Credit researchers in advisories and CVE records, supporting the recognition that motivates security research

7. Monitor multiple databases given that no single source has complete coverage—OSV.dev aggregation helps but isn't exhaustive

8. Contribute to coordination infrastructure through funding, participation, and feedback on platforms and processes

The vulnerability disclosure ecosystem, despite its imperfections, enables coordinated response to security issues at scale. Organizations that understand and engage effectively with this ecosystem—as researchers, maintainers, or consumers—contribute to the security of the entire software supply chain.