Scope boundaries between disclosure, supply chain integrity, and SBOM/VEX WGs

Aperta
  • Qualcosa non va?
#660 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Ambito
documentation

Direzione di ricerca

Start by reading the Vulnerability Disclosure, Supply Chain Integrity, and SBOM & VEX charters referenced in the issue, then review the four-part test already applied: scope, contribution, better home, and precedent. Done means producing TAC guidance with durable criteria for evaluating project placement and clarifying how those criteria should be applied.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

From @taladrane in https://github.com/ossf/tac/pull/650:

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.

References:

Lingua principale
Nessun dato sulla lingua
Stelle
155
Fork
89
Merge medio
1g 23h
PR unite (30g)
10

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ossf/tac

Tutte le issue di ossf/tac

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.