Reporting security issues in specifications.

[mikewest]

While looking into a bug report, @annevk, @mozfreddyb, and I started thinking about better ways to coordinate discussion between browser vendors on issues that are grounded in the design/specification of a feature itself, not in any particular implementation.

Our current model starts and ends with ad hoc CCs on bugs filed against a particular vendor, which is good for bug reporters (and therefore bug intake) due to vendors' VRP programs, and quite appropriate for implementation-specific resolution. It's not, however, the best way to come to agreement on a spec level solution as the conversation ends up sharded across vendors.

I think it might be reasonable for the WHATWG to set up a "security" GitHub repository with private vulnerability reporting enabled, and to use ACLs on that repo to coordinate issue disclosure across browser vendors.

With such a repo in place, I think we'd still usually begin with bugs filed against individual vendors' implementations, but we could then guide bug reporters towards that new repository to refile the issue, or to gain permission to refile it on their behalf. Centralizing the intake would relive reporters/triagers of the burden of determining which spec(s) they should be pointing towards, and allow vendors to pull in the right folks from their organization to discuss the issue.

WDYT?

[hawaiigal]

Hi @mikewest! I’m an engineer working on GitHub’s Private Vulnerability Reporting feature and we’d love to learn more and support this use case. Please feel free to email me (hawaiigal@github.com) or our PM @katecatlin (katecatlin@github.com) if you need anything or want to talk through your use case! Thanks to friend and googler @ddworken (ddworken@google.com) for bringing this to my attention

[dveditz]

Sounds like a great idea. There are lots of implementation details that could make this better or worse, but I love the key points above

• coordinate spec-change discussion in the spec-owning org
• single "security coordination" space rather than scattered across individual spec repos

Does Github support creating private issues in a public repo? Or would we have to use the "vulnerability reporting" mechanism that seems to live outside the "issues" mechanism?

[mozfreddyb]

To all: For posterity, we at Mozilla agree that this is useful and are happy join the effort. In the interest of openness and transparency of web specifications, I think we should aim to only use this for moderage/high severity bugs (severity scoring TBD, but thinking along the lines of Mozilla's severity ratings) only. Further, we should hold ourselves accountable to ensure that every bug becomes public. I would prefer if we had an explicit disclosure deadline (90 days seems widely used?) before we start.

About the specifics that Dan raised: I believe the mechanisms at https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability would suffice for us, wouldn't they? So far, I think it's worked relatively well when we worked on the de-facto changes to the spec in public and kept the security aspects private in a hidden github advisory.

[mikewest]

@mozfreddyb: I think we could come to some kind of synthesis of Mozilla's severity ratings and Chromium's. They seem fairly compatible at a high level, and we can certainly tweak them to be a bit more web-platform focused. Regarding disclosures, I'm also in favor of openness. That said, both Chromium's security FAQ and Mozilla's similar document sketch some edge cases in which scheduled disclosure might not be desirable. Still, I think we'd be able to come to reasonable agreement on a general policy.

@dveditz: Yes, I'm suggesting we use the private vulnerability reporting mechanism rather than issues. This works pretty well for Google's Security Research repo, and Meta's External Disclosures. I think it could work for us as well.

@annevk: If this scheme can be acceptable to WebKit as well, I'm happy to take a first pass at a document sketching a process in more detail. I'm OOO next week, but could probably make some progress the week after.

[annevk]

Yeah, this generally sounds good.

Aside: vulnerability reporting has been used for Fetch, but making them public wasn't easy for a non-traditional-software project as CVEs and such are not really applicable. I could imagine us publishing the result separately somewhere though.