ossf · taladrane · Oct 28, 2025
@@ -0,0 +1,114 @@
+# 2025 Q4 Vulnerability Disclosures WG Update
+
+## Overview
+
+The Vulnerability Disclosures Working Group is dedicated to enhancing the security of the OSS ecosystem by improving vulnerability reporting and communication. Since September 2nd ([our last update](https://github.com/ossf/tac/pull/515)), the group has actively engaged in discussions and initiatives aimed at standardizing vulnerability disclosure processes and addressing challenges in the CVE program. Key thematic developments include the ongoing effort to define a NIST Product Vulnerability Disclosure Report (VDR) format standard, discussions around handling vulnerabilities in unreleased code, and improvements to the OSV project. The group continues to see consistent participation from various organizations and individual contributors.
+
+### Participation & Engagement (Optional)
+
+| Meeting Cadence | Region/Timezone | Median Attendance | Range (Low–High) | Trend vs. Last Quarter | Notes / Opportunities         |
+| :-------------- | :-------------- | :---------------- | :--------------- | :--------------------- | :---------------------------- |
+| Biweekly        | AMER            | 10                | 7–18             | →                      | Consistent maintainer turnout |
+| Biweekly        | APAC            | 6                 | 4–7              | →                      |                               |
+
+## Activities Summary
+
+### Activity #1: Proposal to develop a NIST Product Vulnerability Disclosure Report (VDR) format standard ([Issue 172](https://github.com/ossf/wg-vulnerability-disclosures/issues/172))
+
+**Purpose:** To address the challenges users face in correlating CPE identifiers with familiar product names for vulnerability information and to standardize the VDR format for automated risk response and consistent information sharing across suppliers.
+
+**Current Status:**
+
+  - Extensive discussions have taken place regarding the necessity and alignment of a VDR standard with existing frameworks like FedRAMP.
+  - The working group has validated the belief that users struggle with CPE identifiers and need a product-centric view of vulnerabilities.
+  - Key requirements for a successful VDR standard have been established, including machine-readable format, API accessibility, familiar product naming, and compliance with various standards (NIST SP 800-161r1 RA-5, FedRAMP).
+  - Existing VDR solutions from vendors like Cisco have been reviewed, highlighting the need for a standardized, easily parsable format.
+  - Motivation for adoption has been discussed, with potential drivers identified in the energy industry and cyber insurance sector.
+  - The distinction between VEX (vulnerability-centric) and VDR (product-centric) has been clarified.
+
+**Up Next (Next 4–8 Weeks):**
+
+1.  TAC vote for this initiative is open: https://github.com/ossf/tac/issues/530
+2.  Further exploration of aligning VDR efforts with SBOM standards.
+3.  Continued discussion on how OSV.dev could support exporting data in a newly defined VDR format.
+4.  Investigate how CycloneDX can support "clean" VDRs (reports with zero known vulnerabilities).
+
+**Questions / Requests for Oversight Body (e.g., TAC):** https://github.com/ossf/tac/issues/530
+
+-----
+
+### Activity #2: Guidance for Maintainers Regarding Unreleased Code and Vulnerabilities ([Issue 171](https://github.com/ossf/wg-vulnerability-disclosures/issues/171))
+
+**Purpose:** To address the challenges and confusion surrounding the assignment of CVEs to unreleased code, particularly in open-source projects, and to provide clearer guidance for maintainers and the CVE program on how to accurately report such vulnerabilities without causing false positives.
+
+**Current Status:**
+
+  - Discussions were initiated by Chris de Almeida regarding a situation where a CVE was unexpectedly published for a vulnerability in unreleased GitHub code, leading to incorrect flagging of all package versions as vulnerable.
+  - The group has identified that current CVE rules lack clear guidance on vulnerabilities in unreleased code, distinct from end-of-life (EOL) software.
+  - Challenges include the inability to tag unreleased code accurately in CVEs, leading to scanning tools incorrectly flagging all versions as vulnerable.
+  - The use of Git commit hashes as versions in CVEs was discussed, but concerns remain about tools still flagging all versions.
+  - The distinction between "bundling" and "repackaging" unreleased software into released contexts was clarified as a contributing factor to the problem.
+
+**Up Next (Next 4–8 Weeks):**
+
+1.  @taladrae will set up a document to collaborate on this issue.
+2.  Continue discussions on potential rule additions or changes within the CVE framework to provide better guidance for unreleased code.
+3.  Explore best practices for providing versioning in CVEs to prevent false positives when dealing with unreleased or bundled code.
+4.  Develop concise, checklist-style guides for maintainers to assist with security triage related to unreleased code.
+
+**Questions / Requests for Oversight Body (e.g., TAC):** None at this time.
+
+-----
+
+### Activity #3: OSV Project Updates and Schema Graduation Application
+
+**Purpose:** To ensure the OSV schema graduates through the OpenSSF process and to continuously improve the OSV database and scanner for more accurate and automated vulnerability information.
+
+**Current Status:**
+
+  - The OSV schema graduation application is progressing, with a GitHub Project created for tracking and a PR with the necessary paperwork submitted.
+  - Work is ongoing on CVE conversion from OSV, particularly for kernel vulnerabilities, with a focus on automating the process and reflecting open-source CVEs with git commits in OSV.
+  - A policy decision was made to change how disputed CVEs are handled in OSV, moving away from automatically withdrawing them and instead carrying over the disputed tag or making it a database-specific field.
+  - Jess Lowe is leading efforts on enriching vulnerability feeds with direct CVE v5 metadata and has made significant progress in converting Linux and GitHub CVEs.
+  - OSV has decided to decouple Alpine and Debian vulnerabilities from OSV records due to divergence.
+
+**Up Next (Next 4–8 Weeks):**
+
+1.  Continue working on the OSV schema graduation application, resolving outstanding requirements.
+2.  Roll out updated CVE conversion processes on osv.dev and work with CNAs on git commit enumeration.
+3.  Implement changes in OSV's handling of disputed CVEs, potentially introducing a database-specific field.
+
+**Questions / Requests for Oversight Body (e.g., TAC):** None at this time.
+
+-----
+
+## Decisions Made This Quarter (Optional)
+
+| Date       | Decision                                                                     | Impact | Reference (Link)                                                                           | Follow-up                                   |
+| :--------- | :--------------------------------------------------------------------------- | :----- | :----------------------------------------------------------------------------------------- | :------------------------------------------ |
+| 2025-08-28 | OSV will change how disputed CVEs are handled (not automatically withdrawn). | High   | [GitHub Issue 2038](https://github.com/google/osv.dev/issues/2038#issuecomment-1996386489) | Implementation in OSV database and scanner. |
+
+-----
+
+## External Coordination & Ecosystem Alignment
+
+  - **CVE Program:** Discussions and feedback provided to the CVE Program regarding improved CVE descriptions and the lack of differentiating information in ticket responses. Andrew Pollock will invite Jonathan Leitschuh to the unofficial CVE Slack.
+  - **NIST:** Discussions around aligning VDR efforts with SBOM standards, with comments filed to NIST regarding SBOM alignment in NVD.
+  - **Energy Industry:** The energy industry recently approved a 2026 action item to focus on cybersecurity vulnerability disclosures, including software supply chain risks.
+  - **FIRST Conference Vuln4Cast:** Art Manion mentioned that the CFP for the Vuln4Cast conference on vulnerability data is still open.
+  - **OpenSSF Community Day EU:** The event recently took place, highlighting community engagement.
+
+-----
+
+## Support Needed (Roll-Up)
+
+No support requests this quarter.
+
+-----
+
+## Appendix
+
+  - Project board(s): [OpenSSF WG Vulnerability Disclosures GitHub](https://github.com/orgs/ossf/projects/29)
+  - Key repositories: [ossf/wg-vulnerability-disclosures](https://github.com/ossf/wg-vulnerability-disclosures), [google/osv.dev](https://github.com/google/osv.dev)
+  - Meeting notes index: [2025 Vuln Disclosure WG Notes OpenSSF](https://docs.google.com/document/d/1TdxiFofLOfpHUEQILlKq7qkjSsRXVab0uApSDJ8c5rI/edit)
+  - Contact / Slack / Mailing list: [#wg_vulnerablity\_disclosures](https://openssf.slack.com/archives/C019Y2A28Q6), [OpenSSF Mailing List](https://lists.openssf.org/g/openssf-wg-vul-disclosures)