Thanks Ned - I can definitely share the /security page and other details - I didn’t yet because I didn’t write them yet
I believe /security should be something similar to this: https://kubernetes.io/docs/reference/issues-security/security/ where the main point is “here’s how to contact us, and we will acknowledge receipt within N business days” (N = 2-3 probably). Acknowledging receipt would be done by Tidelift so that timeline wouldn’t apply to maintainers.
As far as how to proceed if someone sends us a report, I was thinking we’d contact the relevant maintainer, review the issue, and jointly develop a plan including a realistic timeline. Since part of the point of having us as contact would be to avoid hassle like GPG setup, we might email without details and then switch to voice or Signal, something like that.
I was thinking we would not have a guaranteed response time for the mitigation, since it varies quite a bit depending on what the problem is, and I don’t see any other projects or vendors guaranteeing this. They do establish a timeline (agree on the embargo date) once they know the particular vulnerability, though.
It looks like Apache does not use a private fork, they make a public commit that doesn’t say “security” in it: https://www.apache.org/security/committers.html#vulnerability-handling
Django sounds similar but they specify that they don’t push the commit until the disclosure day: https://docs.djangoproject.com/en/dev/internals/security/#who-receives-advance-notification so maybe this implies they have a private branch somewhere, if only on one developer’s laptop. I wonder if Apache does the don’t-push-until-day-of thing too and just didn’t spell it out on their page. I’m planning to run our process past a couple of people who have been on security teams and can double-check how they do this.
There are probably a couple different more-details documentation pages I need to write here, one is the “here’s how to report a vulnerability” page for bug-discoverers, and the other is like https://www.apache.org/security/committers.html#vulnerability-handling and describes the process Tidelift+lifters will use on receiving a vulnerability.
Still halfway through working out the details as you can see but figured it’d be good to get early feedback instead of dropping something fully-baked with no discussion.