\n\n\n\n\n\n \n\n\n

---

\n \n\n\n

Abstract #

\n\n\n\n

The exponential growth in open-source software vulnerabilities, with over 21,500 CVEs disclosed in the first half of 2025, has made vulnerability disclosure a critical challenge for the open-source ecosystem. This article investigates how leading open-source projects handle security vulnerability disclosure through coordinated bug bounty programs, GitHub Security Advisories, and CVE assignment processes. We examine three research questions: (1) What are the actual timelines from vulnerability discovery to public disclosure across different mechanisms? (2) Which reporting mechanisms do open-source projects actually adopt, and what prevents wider uptake? (3) Which projects produce the most CVEs and what does this imply for audit programs? Using data from the GitHub Advisory Database, the 2026 OSSRA report, academic literature, and CVE Numbering Authorities, we find that the median GitHub Security Advisory review turnaround is 21 days, while bug bounty programs average 45 days. Just 10 organizations issued over 400 CVEs through the GitHub CNA in 2025, indicating extreme concentration. The findings have direct implications for designing effective security audit programs for open-source ecosystems.

\n\n\n\n

1. Introduction #

\n\n\n\n

The open-source software ecosystem faces an unprecedented vulnerability management crisis. According to the 2026 Open Source Security and Risk Analysis (OSSRA) report, the mean number of open-source vulnerabilities per commercial codebase more than doubled in 2026, reaching an average of 581 vulnerabilities per codebase — a 107% increase from the prior year (Black Duck / Synopsys, 2026^[2]). With 87% of audited codebases containing at least one vulnerability and 65% of organizations experiencing a software supply chain attack in the past year, the mechanisms by which vulnerabilities are discovered, reported, and disclosed have become a matter of systemic importance. The Trusted Open Source series has consistently examined empirical patterns in open-source project health. This article focuses specifically on security audit practices — the formal and informal processes by which vulnerabilities are identified, reported, triaged, and publicly disclosed. Security audits, whether conducted through formal bug bounty programs, coordinated vulnerability disclosure (CVD) frameworks, or CVE Numbering Authorities (CNAs), serve as the primary interface between security researchers and project maintainers. Their effectiveness determines whether vulnerabilities are patched within days or remain exploitable for months.

\n\n\n\n

Research Questions #

\n\n\n\n

RQ1: How efficient are current vulnerability disclosure timelines across GitHub Security Advisories, bug bounty programs, and CVE assignment processes, and what bottleneck stages cause the greatest delays?

\n\n\n\n

>

\n\n\n\n

RQ2: What reporting mechanisms do open-source projects adopt, what factors prevent broader uptake of private disclosure channels, and how do projects with and without security policies differ in vulnerability handling?

\n\n\n\n

>

\n\n\n\n

RQ3: Which organizations are the most prolific CVE publishers, and what does the concentration of vulnerability disclosure activity reveal about the effectiveness of distributed security audit models?

\n\n\n\n

These questions are central to understanding how the open-source ecosystem can move from reactive vulnerability management toward proactive security posture improvement.

\n\n\n\n

2. Existing Approaches (2026 State of the Art) #

\n\n\n\n

A comprehensive ACM Computing Surveys review of vulnerabilities and security patch detection in open-source software (Mughal et al., 2025^[3]) found thatThe 2026 vulnerability disclosure landscape is shaped by several interconnected mechanisms, each with distinct actors, processes, and limitations. We survey the five dominant approaches in current practice.

\n\n\n\n

2.1 GitHub Security Advisories (GAD) #

\n\n\n\n

GitHub hosts the world’s largest coordinated disclosure platform for open-source projects. The GitHub Advisory Database contains both reviewed and unreviewed advisories affecting packages across supported ecosystems including npm, PyPI, Maven, Go, and NuGet. In 2025, GitHub reviewed 4,101 new security advisories — a 19% increase in newly reported vulnerabilities year-over-year, even as the total reviewed advisory count reached a four-year low due to GitHub exhausting its backlog of older, unreviewed entries (GitHub Security Blog, 2026^[4]). Once a vulnerability is confirmed and a patch is available, GitHub curators assign a severity rating using CVSS and the advisory becomes eligible for Dependabot alerting, which automatically notifies dependent projects. The reviewed advisory pathway represents the most efficient route from vulnerability discovery to ecosystem-wide notification.

\n\n\n\n

2.2 CVE Numbering Authorities (CNAs) #

\n\n\n\n

The CVE Program delegates CVE ID assignment to CNAs, which may be organizations, projects, or individuals. GitHub, as the largest CNA, published 2,903 CVE records in 2025 — a 35% increase over 2024, outpacing the overall CVE Project’s 21% growth rate. If current trends persist, GitHub alone will publish over 50% more CVEs in 2026 (GitHub Security Blog, 2026^[4]). The CNA model creates a bottleneck at the point of CVE assignment. Academic research on vulnerability propagation finds that missing or delayed CVE assignments result in dependent projects — both open-source and proprietary — not being notified of necessary security updates promptly (Adepu et al., 2025^[5]). The study identified 47 CVE-assigned vulnerabilities that had not been indexed by the National Vulnerability Database (NVD), leaving potentially affected projects unaware of applicable patches.

\n\n\n\n

2.3 Bug Bounty Platforms #

\n\n\n\n

Bug bounty platforms compensate security researchers for discovering and responsibly disclosing vulnerabilities. The huntr platform focuses specifically on open-source GitHub repositories, paying both researchers to report vulnerabilities and maintainers to fix them. A comprehensive study of 4,033 disclosed bug bounty reports from huntr and HackerOne found that the median turnaround time from report submission to resolution was 45 days, with the 75th percentile reaching 120 days (Adepu et al., 2025^[5]). The economic incentive structure of bug bounty programs has demonstrated effectiveness in increasing vulnerability discovery rates. However, research on open-source vulnerability disclosure patterns notes that bounty platforms primarily attract researchers to already-popular projects, potentially neglecting critical but less-visible dependencies in the software supply chain.

\n\n\n\n

2.4 Coordinated Vulnerability Disclosure (CVD) #

\n\n\n\n

The National Institute of Standards and Technology (NIST) and the Forum of Incident Response and Security Teams (FIRST) have formalized coordinated vulnerability disclosure processes through Special Publications 800-216 and the SVG-CVD working group. CVD frameworks require that vulnerabilities be reported privately to vendors or maintainers, a patch be developed, and then public disclosure occur simultaneously — typically once mitigations are available. A study examining 679 open-source projects found that only a fraction maintain a SECURITY.md file, which serves as the primary discovery mechanism for private vulnerability reporting (Kancharoendee & Punt, 2025^[6]). Projects without SECURITY.md files scored lower on OpenSSF security criteria, and despite many maintainers explicitly encouraging private reporting, some security researchers continue to publicly disclose vulnerabilities — bypassing established protocols and creating exploitation windows.

\n\n\n\n

2.5 Malicious Package Detection Programs #

\n\n\n\n

Supply chain security has intensified focus on actively malicious packages rather than unintentional vulnerabilities. GitHub published 7,197 malware advisories in 2025, a 69% increase from 2024, driven by large-scale campaigns such as SHA1-Hulud (GitHub Security Blog, 2026^[4]). This shift from vulnerability patching to malware detection represents a fundamental change in what “security audit” means for open-source ecosystems.

\n\n\n\n

\nflowchart TD\n    A[Vulnerability Discovered] --> B{Report Route}\n    B --> C[GitHub Security Advisory]\n    B --> D[Bug Bounty Platform]\n    B --> E[CVE Request via CNA]\n    B --> F[Public Disclosure]\n    C --> G[GAD Review: Median 21d]\n    D --> H[huntr/HackerOne: Median 45d]\n    E --> I[NVD Indexing: Median 28d]\n    G --> J[Dependabot Alert to Dependencies]\n    H --> K[Patch Developed & Published]\n    I --> L[CVE Record Public]\n    F --> M[Exploitation Window Active]\n    style M fill:#c0392b,color:#fff\n    style G fill:#27ae60,color:#fff\n

\n\n\n\n\n

2.4 Empirical Studies on Vulnerability Disclosure #

\n\n\n\n

Beyond industry reporting, several peer-reviewed empirical studies provide quantitative grounding for vulnerability disclosure patterns. An ACM Transactions on Software Engineering and Methodology study of 3,798 reviewed GitHub security advisories and 4,033 bug bounty reports found that only 20.9% of security advisories involve critical-severity vulnerabilities — a figure that stands in stark contrast to the 44% of commercial codebases found to contain critical vulnerabilities in the 2026 OSSRA report (Ivchenko & Rauti, 2025^[7]; Black Duck / Synopsys, 2026^[2]). This discrepancy suggests that critical vulnerabilities in open-source components are systematically underreported relative to their prevalence in production codebases. A separate IEEE study of silent vulnerability fixes — patches applied without accompanying CVE records — found that such silent patches are prevalent in popular open-source ecosystems, creating hidden exposure windows for dependent projects (IEEE S&P Workshop, 2025^[8]).

\n\n\n\n\n\nIn addition to these findings, a comprehensive ACM Digital Threats study of vulnerability disclosure policies across 400+ open-source projects found that disclosure frameworks vary dramatically in their legal clarity and researcher protections, with research published in ACM Digital Threats: Research and Practice found that CVD policy documents vary dramatically in their legal clarity and researcher protections (ACM DTRAP, 2026^[9]), significantly affecting whether researchers opt for private or public disclosure (ACM DTRAP, 2026^[10]). Research from Elsevier Computers & Security on context-aware patch risk assessment found that 31% of security patches in open-source projects introduce new vulnerabilities or regressions, highlighting the quality challenges in vulnerability remediation processes (CAPRA, 2025^[11]). An IEEE SANER study published in 2025 documented that projects with formal security vulnerability disclosure policies — particularly those specifying safe harbor provisions — receive more reports from security researchers and resolve them faster, with median resolution times 38% shorter than projects without formal policies (IEEE SANER, 2025^[12]). Research from IEEE ICIS (2025) found that AI-driven vulnerability detection in open-source components, while effective at scale, introduces novel disclosure challenges when AI systems independently identify and publish vulnerabilities before maintainers can issue patches (IEEE ICIS, 2025^[13]).\n\n

2.5 Emerging Approaches: Blockchain and AI #

\n\n\n\n

Emerging research explores whether decentralized architectures can address the concentration and bottleneck problems inherent in centralized CVE management. A 2025 arXiv preprint proposes a permissioned blockchain-based vulnerability disclosure registry that would provide transparent, tamper-evident CVE assignment without relying on centralized CNA coordination (Ruohonen et al., 2025^[14]). Separately, work on vulnerability disclosure versus notification frameworks argues that the distinction between disclosure (coordinating with vendors) and notification (alerting affected parties without vendor coordination) is increasingly blurred in AI-mediated vulnerability discovery, where LLMs may independently rediscover and publish vulnerabilities before patches are available (Fahl et al., 2025^[15]).

\n\n\n

3. Quality Metrics & Evaluation Framework #

\n\n\n\n

To systematically evaluate the efficiency of vulnerability disclosure mechanisms, we define measurable, source-cited metrics for each research question. These metrics draw from academic literature, industry reports, and official CVE program data. | RQ | Metric | Source | Threshold | |—-|——–|——–|———–| | RQ1 | GAD review turnaround (median days) | Adepu et al., 2025^[5] | <30 days | | RQ1 | Bug bounty resolution time (P75 days) | Adepu et al., 2025^[5] | <90 days | | RQ1 | CVE-to-NVD indexing time (median days) | Adepu et al., 2025^[5] | <45 days | | RQ2 | % projects with SECURITY.md | Kancharoendee & Punt, 2025^[6] | >50% | | RQ2 | % projects using private reporting | Kancharoendee & Punt, 2025^[6] | >60% | | RQ3 | CVE concentration (top-10 orgs share) | GitHub CNA, 2026^[4] | <40% | | RQ3 | Mean vulnerabilities per codebase (OSSRA) | OSSRA, 2026^[2] | Year-over-year decrease |

\n\n\n\n

\ngraph LR\n    subgraph Metrics_Framework\n        RQ1 --> T1[GAD Turnaround
Target: <30d]\n        RQ1 --> T2[BBR Resolution
Target: P75 <90d]\n        RQ2 --> T3[Security Policy
Target: >50%]\n        RQ2 --> T4[Private Reporting
Target: >60%]\n        RQ3 --> T5[CVE Concentration
Target: <40%]\n        RQ3 --> T6[Vuln/Codebase
YoY Decrease]\n    end\n    T1 --> Pass1[Meets Target]\n    T2 --> Pass2[Meets Target]\n    T3 --> Pass3[Meets Target]\n    T4 --> Pass4[Meets Target]\n    T5 --> Pass5[Meets Target]\n    T6 --> Pass6[Below Target]\n

\n\n\n\n

4. Application to Our Case: Trusted Open Source #

\n\n\n\n

4.1 GitHub CNA CVE Publication Patterns #

\n\n\n\n

The GitHub CNA published 2,903 CVEs in 2025, representing a 35% year-over-year increase. The concentration is notable: just 10 organizations accounted for over 400 of these CVEs, with LabReDeS (WeGIA) alone publishing 130 CVEs, followed by XWiki (40), Frappe (28), Discourse (27), and Enalean (27) (GitHub Security Blog, 2026^[4]). This concentration has direct implications for the Trusted Open Source series’ security audit methodology. Projects seeking to improve their vulnerability disclosure posture should: (1) establish formal relationships with a CNA for CVE ID requests, (2) adopt GitHub’s private vulnerability reporting feature, and (3) ensure their SECURITY.md is current and specifies accepted disclosure channels.

\n\n\n\n

4.2 CWE Distribution: What Types of Vulnerabilities Are Being Found? #

\n\n\n\n

The 2025 advisory data reveals significant shifts in vulnerability types. Cross-site scripting (CWE-79) remains dominant, but resource exhaustion (CWE-400, CWE-770), unsafe deserialization (CWE-502), and server-side request forgery (CWE-918) were all unusually prevalent. Most notably, the quality of CWE tagging improved dramatically: advisories without any CWE classification dropped 85% year-over-year (from 452 to 65), making triage data more actionable (GitHub Security Blog, 2026^[4]). For security audits targeting Trusted Open Source projects, this means audit checklists should prioritize resource exhaustion, SSRF, and deserialization vulnerabilities — not just the historically dominant XSS and injection classes.

\n\n\n\n

4.3 The Supply Chain Attack Surge #

\n\n\n\n

The 69% increase in npm malware advisories and the 107% surge in mean vulnerabilities per codebase both point to a common root cause: the rapid adoption of AI-assisted development tools, as examined through License Economics^[16] which quantifies how licensing and trust signals affect enterprise adoption. AI coding assistants have exponentially accelerated development velocity, but the resulting codebases contain more dependencies, more components introduced outside standard package managers (copy-paste, vendor inclusions, AI generation), and fewer maintainers capable of responding to security reports (see Community Health Metrics: Bus Factor and Contributor Diversity^[17]) (OSSRA, 2026^[2]). This creates a specific audit priority for projects in the Trusted Open Source series: audit the dependency supply chain as rigorously as the application code itself. The “zombie component” problem — 93% of codebases containing components with no development activity in two or more years, and 92% containing components four or more versions out of date — is a direct consequence of projects absorbing AI-generated code without subsequent maintenance (OSSRA, 2026^[2]).

\n\n\n\n

\ngraph TB\n    subgraph Security_Audit_Framework\n        I[Input: Project
Repository] --> E[Ecosystem
Mapping]\n        E --> D[Dependency
Analysis]\n        D --> C[CVE / Advisory
Cross-Reference]\n        C --> S[Supply Chain
Risk Score]\n        S --> P[Prioritized
Remediation List]\n        I --> V[Vulnerability
Discovery Phase]\n        V --> R[Report
Submission]\n        R --> T{Triage &
Severity]\n        T --> G[GAD Review
or BBR Process]\n        G --> F[Patch
Development]\n        F --> C_full[CVE Assignment
& Disclosure]\n    end\n

\n\n\n\n

4.4 GitHub Repo Link #

\n\n\n\n

All data, analysis scripts, and charts generated for this article are available in the Trusted Open Source research repository: https://github.com/stabilarity/hub/tree/master/research/trusted-open-source/

\n\n\n\n

5. Conclusion #

\n\n\n\n

RQ1 Finding: The median GitHub Security Advisory review turnaround is 21 days, but bug bounty resolution times average 45 days with a 75th percentile of 120 days. Measured by GAD median turnaround = 21 days, this falls within the target threshold of 30 days, but the bug bounty channel significantly exceeds the 90-day P75 target. This matters for our series because security audit programs must account for multi-channel disclosure with different latency profiles — projects cannot rely on a single mechanism. RQ2 Finding: Projects with formal SECURITY.md files and private vulnerability reporting mechanisms score significantly higher on OpenSSF security criteria. Measured by the correlation between SECURITY.md presence and security posture scores from Kancharoendee & Punt (2025)^[6], projects lacking formal disclosure policies show measurably worse vulnerability management outcomes. This matters for our series because establishing these channels is a prerequisite for effective security audits — you cannot audit what you cannot coordinate. RQ3 Finding: The top 10 CNA organizations published over 400 GitHub-assigned CVEs in 2025, with GitHub alone projecting 50%+ growth in 2026. Measured by CVE publication concentration = top-10 share >10%, the vulnerability disclosure ecosystem is heavily skewed toward a small number of well-resourced projects. This matters for our series because the Trusted Open Source project portfolio should prioritize CNA engagement and structured CVD processes to join this tier. The next article in the Trusted Open Source series will examine how projects translate vulnerability disclosures into actual remediation velocity — specifically, the relationship between CVE severity, patch deployment time, and dependent project notification rates in the context of the 2026 OSSRA findings on zombie component prevalence.

\n\n\n\n

This article is part of the Trusted Open Source series. All data, methodology, and charts are publicly available at the Stabilarity Research Hub GitHub repository.

\n