Add Q3 2026 report for Vulnerability Disclosures WG

[taladrane]

Quarterly update for the OpenSSF Vulnerability Disclosures Working Group covering Q3 2026 (July–September), synthesized from the WG meetings on July 8, July 22, July 23 (APAC), August 19, and August 27 (APAC).

Adds TI-reports/2026/2026-Q3-VD-WG.md.

Highlights

• AI-generated report quality — the workstream gained a formal academic research partner. The Georgia Tech SSLab team presented a user study on best practices for AI-generated vulnerability reports and is now moving into IRB-approved maintainer interviews, with the WG supplying report corpora and maintainer contacts.
• Ortelius sandbox sponsorship — the WG ran a structured scope / contribution / better-home / precedent evaluation and opened a vote on wg-vulnerability-disclosures#185.
• OSV schema — two releases shipped: v1.8.0 (CVSS severity attribution) and v1.9.0 (wildcard package support for EOL records, WordPress ecosystem).
• Vulnerability guides — oss-vulnerability-guide#59 merged, publishing the guides as GitHub Pages.
• WG sustainability — an early conversation started about strengthening the relationship between the WG and the Technical Initiatives it sponsors.

Ask for the TAC: scope boundaries between disclosure, supply chain integrity, and SBOM/VEX

The WG is asking the TAC for guidance on where the boundary of "vulnerability disclosure" sits relative to adjacent initiatives, and ideally for durable criteria rather than a per-project ruling.

What surfaced it. The Ortelius sandbox proposal (#185) asked the WG to sponsor a project focused on post-deployment vulnerability remediation — identifying newly published vulnerabilities running on live endpoints that pre-deployment SCA missed. Evaluating it, the WG could not answer a first-order question from its own charter: is our remit the act of disclosure (reporting, coordinating, publishing), or the outcome disclosure exists to serve (that affected software actually gets identified and fixed)?

Why it is genuinely ambiguous. A gap analysis on the proposal observed that the project is heavy on consuming disclosure outputs — CVEs, SBOMs, VEX, OSV.dev data — and lighter on contributing back to disclosure processes, with most of its value in remediation and operations. That is a fair reading. It is also true that the WG's existing portfolio is not purely about the act of disclosure: OSV is a database and schema, OpenVEX is an exploitability exchange, and SIREN is coordinated response. A consumption-heavy project is not obviously out of family.

Why it will recur. This is not a one-off. A proposal for a new SBOM/VEX-focused WG is anticipated, and the Supply Chain Integrity WG already holds adjacent ground. Without shared criteria, each new project in this space costs a WG a multi-meeting scoping debate, and similar projects may land in different homes depending on who evaluated them.

What would help. Guidance on the questions the TAC wants WGs to apply — for example, whether contribution back to a WG's core workflows should be a sponsorship requirement or merely a positive signal, and how much weight "no better home exists" should carry. The WG applied a four-part test (scope, contribution, better home, precedent) and would happily standardize on TAC-endorsed criteria instead.

Framing note. The WG treats project placement as a reversible decision — a project can start in one WG and move later — so this is a request for clarity that reduces recurring cost, not a blocker.

Previous update: #615