Vulnerability Reporting Procedures

• Vulnerability Reporting Procedures are systematic frameworks that guide the identification, documentation, disclosure, and remediation of software and system flaws.
• They employ standardized reporting formats, quantitative metrics, and coordinated disclosure models to enhance risk reduction and regulatory compliance.
• Advanced methodologies, including automation and LLM-based enrichment, improve report accuracy and reduce response times across diverse environments.

Vulnerability reporting procedures refer to the structured processes, technical frameworks, and operational practices that guide the identification, documentation, disclosure, and resolution of software and system flaws. These procedures are foundational for effective risk reduction, secure software engineering, and compliance with regulatory mandates. The following article synthesizes empirical findings and protocol descriptions from rigorous studies of vulnerability reporting across open-source, proprietary, and AI-based environments.

1. Core Elements and Protocols in Vulnerability Reporting

Vulnerability reporting protocols are comprised of systematic mechanisms that govern the flow of information from discovery to remediation. For software systems, protocol formalization often begins with the adoption of standardized reporting files (e.g., SECURITY.md for OSS (Kancharoendee et al., 11 Feb 2025, Kanaji et al., 7 Oct 2025)), structured submission forms, or predefined organizational channels.

A typical reporting procedure follows these stages (Munaiah et al., 2019):

1. Planning: Definition of scope, formulation of research or reporting questions, and establishment of communication channels, frequently employing the PICOC framework (Population, Intervention, Comparison, Outcomes, Context).
2. Conducting: Execution of a search or notification strategy, data extraction using standardized forms, and the application of objective selection criteria—quality assurance often validated with metrics such as Cohen’s k or Quasi-Sensitivity ($$\text{Quasi-Sensitivity} = \frac{\# \text{Studies Retrieved}}{\# \text{Total Studies}} \times 100\%$$).
3. Reporting: Narrative synthesis of findings that reflect diversity in empirical evidence and support reproducibility and transparency.

In OSS contexts, key reporting mechanisms include emails (used in 41.06% of projects (Kancharoendee et al., 11 Feb 2025)), external webforms, dedicated security advisories, and bug bounty channels. The inclusion of SECURITY.md files is empirically associated with higher overall security scores (mean aggregate OpenSSF Scorecard of $5.93$ with policy vs $3.95$ without, $p < 0.001$ (Kancharoendee et al., 11 Feb 2025, Kanaji et al., 7 Oct 2025)).

2. Standardization and Metrics for Evaluation

Standardization is achieved through the imposition of minimum elements required for each report, such as affected product metadata, vulnerability classification (e.g., CVE, CWE, AI-CWE), exploitability, mitigation references, and impact metrics (Fazelnia et al., 18 Nov 2024).

Quantitative measures are utilized for both discovery and validation:

Metric	Definition/Use	Example Calculation
Quasi-Sensitivity	Effectiveness of review protocol in literature searches	$80\%$ sensitivity when 8/10 gold studies retrieved
OpenSSF Scorecard	Aggregate security assessment for OSS repositories	Branch protection: $3.53$ w/ policy, $1.69$ w/o
ROUGE-1 F1	Summary overlap in augmented reports	$$F1 = 2 \times \frac{\text{precision} \times \text{recall}}{\text{precision} + \text{recall}}$$
CVE/NVD Reference Rates	Presence in global vulnerability databases	$\approx 99.3\%$ of reviewed advisories reference NVD

Validation of both reporting procedures and the associated database accuracy is a recurring challenge, especially in automated tool contexts (e.g., SCA tools vary widely in reported unique vulnerabilities due to database discrepancies: from 36 to 313 CVEs for Maven projects (Imtiaz et al., 2021)).

3. Coordination Models and Regulatory Mandates

Coordinated Vulnerability Disclosure (CVD) has evolved as the industry standard, emphasizing pre-public remediation and synchronized communication between the discoverer and responsible entity (Ruohonen et al., 9 Dec 2024, Hove et al., 2023, Chen et al., 17 Jun 2025). The European Cyber Resilience Act (CRA) institutionalizes these models, mandating:

• Reporting through national CSIRTs and, optionally, to ENISA.
• Vertical (EU-level) and horizontal (cross-national) coordination.
• Expedited notification deadlines for actively exploited vulnerabilities (e.g., $t_1 = 24~\text{hours}$, $t_2 = 72~\text{hours}$, $t_3 = 14~\text{days}$).
• The requirement for vendors to maintain a documented CVD policy, with financial penalties for non-compliance (Ruohonen et al., 9 Dec 2024).

In the AI sector, the CFD (Coordinated Flaw Disclosure) framework proposes analogous structures, introducing extended model cards, dynamic scope expansion, automated verification, and independent adjudication panels (Cattell et al., 10 Feb 2024). These aim to address the probabilistic, non-deterministic nature of ML flaws not captured in traditional vulnerability paradigms.

4. Operational Practices, Tooling, and Challenges

Operationalizing reporting procedures is hindered by implementation bottlenecks such as database lag (e.g., delayed CVE assignment propagates notification gaps), incomplete initial reports (e.g., $35\%$ of CVEs missing CVSS, $52\%$ lacking CPE, $2\%$ missing mitigation (Khanmohammadi et al., 2023)), and inconsistent cross-tool vulnerability mapping (Imtiaz et al., 2021).

Practices shown to expedite successful reporting and resolution include:

• Rapid first responses, correlated with reduced mean resolution times (strong positive correlation $r \approx 0.637, p < 0.001$ (Bühlmann et al., 2021)).
• Inclusion of reproducibility and reference data (reports with CVE references resolved faster; only $4.5\%$ currently contain such references (Bühlmann et al., 2021)).
• Automated enrichment via third-party information scraping and natural language summarization (pipeline improves fluency, completeness, and correctness of vulnerability descriptions; see cosine similarity: $$\cos(v_p, v_d) = \frac{v_p \cdot v_d}{\|v_p\|\|v_d\|}$$ (Althebeiti et al., 2022)).

A notable challenge remains the concentration of reporting and triage activities among a limited set of developers and maintainers, with only $2.4\%$ of reporters handling security issues and some projects continuing to allow or ignore public reporting, often due to resource constraints or perceived risk (Ayala et al., 12 Sep 2024, Bühlmann et al., 2021).

5. Evolution, Vendor Postures, and Community Adoption

Vendor responses to vulnerability reporting diverge by posture (Piao et al., 7 Sep 2025):

• Proactive Clarification: Vendors with dedicated disclosure structures, tailored AI severity evaluation, and explicit support channels (e.g., Google, Microsoft, Meta).
• Silent: Vendors with generic or absent policy positions regarding AI or software vulnerabilities.
• Restrictive: Vendors excluding AI-related vulnerabilities from scope or declining all disclosure.

A significant lag is documented between academic incident characterization and the evolution of vendor policies (model extraction, adversarial examples, and prompt injection only belatedly addressed in policy after years of research and real-world incidents). Only $18\%$ of surveyed AI vendors explicitly mention AI risk in their disclosure documentation (Piao et al., 7 Sep 2025).

In open-source ecosystems, increased adoption of SECURITY.md files and related policies is ongoing but incomplete (diffusion stage with only $7\%$ adoption originally noted, and $79.5\%$ of related GitHub issues being creation requests (Kanaji et al., 7 Oct 2025)). The persistent use of email as a reporting channel and regular public disclosure by unaffiliated contributors reflect ongoing gaps in awareness and compliance with best practices.

6. Automation, Enrichment, and Future Directions

Recent advancements have focused on automating detection, triage, and enrichment in vulnerability reporting. Approaches such as VulRTex employ LLM-based reasoning graphs and retrieval-augmented generation to identify vulnerability-related issue reports, achieving substantial gains in $F1$ (+11%), $AUPRC$ (+20.2%), and classification macro-$F1$ (+10.5%) over baselines, with twofold reductions in manual processing time (Jiang et al., 4 Sep 2025). Emerging techniques include comprehensive scraping of third-party references and transformer-based summarization to enhance vulnerability report databases (Althebeiti et al., 2022).

Proposed directions for future development include:

• Automatic adjustment and verification of vulnerability scoring (CVSS and AI severity metrics).
• Continuous monitoring systems for dynamic asset inventories and evolving threats.
• Standardization of submission forms and reporting channels (including security.txt, SECURITY.md, and dashboard-driven tools).
• Integration of AI Bill of Materials (AIBOM) and tailored weak-ness enumeration (AI-CWE) frameworks (Fazelnia et al., 18 Nov 2024).

A plausible implication is that as reporting procedures become more automated and enriched, the speed and accuracy of vulnerability triage and resolution will improve, but attention will need to be paid to upstream dependency trust, false positive reduction, and standardized cross-ecosystem coordination.

7. Summary Table: Critical Dimensions of Vulnerability Reporting Procedures

Dimension	Representative Findings	Reference
Protocol Structure	PICOC, standardized forms, staged review	(Munaiah et al., 2019)
Reporting Mechanisms	SECURITY.md, email, bug bounty, advisories, automated pipelines	(Kancharoendee et al., 11 Feb 2025, Jiang et al., 4 Sep 2025)
Regulatory Mandates	CRA vertical/horizontal coordination, strict deadlines	(Ruohonen et al., 9 Dec 2024)
Metrics and Quality Assessment	OpenSSF Scorecard, Quasi-Sensitivity, ROUGE, CVE/NVD rates	(Kancharoendee et al., 11 Feb 2025, Althebeiti et al., 2022)
Vendor Policies (AI)	Proactive/Restrictive/Silent; coverage of technical/safety issues	(Piao et al., 7 Sep 2025)
Automation and Enrichment	LLM-reasoning, transformer summarization, NLP-based matching	(Althebeiti et al., 2022, Jiang et al., 4 Sep 2025)

Vulnerability reporting procedures are not static; they continue to evolve in response to regulatory changes, technological advances, maintainers’ operational realities, and the expanding complexity of software and AI systems. Persistent challenges include the lag between policy and practice, tool interoperability, and the need for comprehensive, standardized reporting protocols that serve the full spectrum of stakeholders from discoverers to vendors to end-users.