ppkarwasz opened a new issue, #1321:
URL: https://github.com/apache/tooling-trusted-releases/issues/1321

   ## Background
   
   The Security Team currently tracks a set of per-PMC links in 
[`project-coordinates.json`](https://github.com/apache/security-site/blob/main/scripts/project-coordinates.json),
 committed to a Security Team repository. Because this file lives outside the 
projects it describes, it drifts out of date and has to be maintained by hand.
   
   ## Proposal
   
   Move this data closer to the projects that own it:
   
   - Make some of it **per-project** rather than **per-committee**, since a 
single PMC can ship products with very different security postures.
   - Let PMCs maintain it themselves, as project metadata in ATR (or an 
equivalent `.asf.yaml` field), so it stays current without Security Team 
intervention.
   
   ## Proposed fields
   
   This is an initial list. See *Priorities* below for what matters most right 
now.
   
   ### Security contact
   
   Exactly one of:
   
   - `security@<pmc>.apache.org`, or
   - `[email protected]`
   
   The goal is to know, for a given project, whether mail to 
`security@<pmc>.apache.org` reaches the PMC or is redirected to 
`[email protected]`.
   
   Some projects today publish mixed instructions, e.g. "send to 
`[email protected]` and Cc `private@<pmc>.apache.org`". This combination 
should not be expressible: the contact is a single address, not a primary plus 
a Cc.
   
   ### Threat model
   
   Two links:
   
   1. The rendered threat model (human-readable web page).
   2. The threat model source, used both for editing and for LLM consumption 
(plain source, free of HTML markup and surrounding page content).
   
   This lets the Security Team filter reports against the documented threat 
model before they reach a PMC and consume its time.
   
   ### Vulnerability report contents
   
   A per-PMC description of what a useful vulnerability report should contain. 
We do **not** expect reporters to follow it. Instead, the Security Team can 
reuse it at triage time as an LLM prompt to enrich a forwarded report, for 
example with:
   
   - a one-sentence summary,
   - verification against the code, including the exact commit checked,
   - the list of threat-model security properties that the report claims to 
break.
   
   Expectations differ by project, so this is intentionally per-PMC: what we 
attach for Tomcat is not what we attach for an incubating project.
   
   ### Disclosed vulnerability reports
   
   The project's published advisories, ideally in two forms:
   
   - an HTML page, and
   - a VDR file.
   
   ## Priorities
   
   The two fields that matter most right now are:
   
   1. The **security contact**, to know whether `security@<pmc>.apache.org` 
reaches the PMC or is redirected.
   2. The **threat model**, to filter out reports before they reach a PMC and 
waste its time.
   
   The remaining fields can follow once the metadata mechanism exists.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to