Does wgpu need a security policy?

[jimblandy]

We should think through how we would like to handle security-sensitive bugs in wgpu. From @dveditz:

The first thing is for the wgpu folks to agree on where they would like security bugs to be reported. Having them reported as public issues isn't great. For many Mozilla projects on github (for example, mobile Firefox) we told people to report security bugs in BMO (bugzilla.mozilla.org).

That's probably not going to fly for an independent project, so the repo (or maybe at the top-level "gfx-rs" org level) needs to enable GitHub "security advisories".

You can see the TC39 policy here: https://github.com/tc39/ecma262/security/

They put the same security.md in every repo, but they all refer to 3 specific security/advisory reporting locations: in the ecma262 and ecma402 repos, and a catchall for everything else

... and some group of maintainers will need permissions to see any submitted issues, and have regularly checking for new ones on their ToDo list.

I would have preferred a direct link to BMO, but email is OK: https://github.com/mozilla-mobile/firefox-android/security

[jimblandy]

There's stuff in wgpu that is not in the WebGPU standard that Firefox doesn't use:

• Fancy features like raytracing, that might be standardized someday
• window system integration ("presentation") that Firefox doesn't use, because we have our own compositor
• system integration, like tie-ins to the underlying platform APIs ("Here's a Vulkan texture"), that Firefox will never use

I'm concerned that Mozilla and the gamedev community (say) may have different expectations about security vs. development velocity, and they use different subsets of the code, so it may be difficult to find a simple policy that works for everyone.

[jimblandy]

One thing a security policy could do is designate a "CVE numbering authority" (CNA), which would assign CVEs and publish CVE records. Right now, since we don't have one, MITRE or GitHub handles this for us. For example, CVE-2024-36761 was filed by MITRE based on #5757.

If wgpu designated Mozilla as our CNA, then the decision of whether to issue a CVE for a given issue would be up to Mozilla. Mozilla would probably usually defer to the wgpu maintainers' judgment, although the final decision would always be theirs. In the case of #5757, we probably wouldn't have gotten a CVE in the first place.

[dveditz]

I mentioned TC39 because their policy page is well-done, and it has downstream projects that depend on it like wgpu does. Those might have independent vulnerabilities in how they use wgpu that aren't in wpgu itself, or might not be affected by a vulnerability because they don't use wgpu that way.

I'm concerned that Mozilla and the gamedev community (say) may have different expectations about security vs. development velocity, and they use different subsets of the code, so it may be difficult to find a simple policy that works for everyone.

I would change the summary to "Does wgpu need a security-reporting policy?", and the answer is emphatically YES, it does. If #5757 had been an exploitable stack BUFFER overflow reported in public that could have potentially put millions of Servo and Firefox users at risk and caused a lot of unplanned emergency development work. You need to tell people how they can responsibly report security vulnerabilities. The SECURITY.md doesn't need to do more than that.

Internally your team should have a security "process" (policy, if you like) for handling and coordinating these, but if there aren't many reports it can be relatively informal and ad hoc. The main thing is deciding which members can see the private reports, and who specifically is responsible for monitoring them at any given time (a "triage owner" rotation)

When you get any reports you can take it case-by-case on how severe it is, or if it affects different downstreams differently. You could punt some of that work to the downstreams by adding a representative to the private report and asking them. If it's severe and easily exploited you should coordinate disclosure with the downstreams. If it's minor maybe you just fix it and release an advisory. If you decide it's not even a security bug you can open a public issue and close the reported security advisory without publishing it.

I don't think GitHub will issue CVEs unless you use the github security advisory process -- it's something they offer to projects by request, not forced. If you use the github security advisory mechanism you could instead supply your own CVE when you publish (which you requested from your CNA). Mitre is supposed to be the "last resort" CNA and probably wouldn't have issued it if your repo had enabled the github process. Even if you don't publicly announce your CNA (which I've never seen anyone do) Mitre would know that your project was capable of getting a CVE from GitHub if not someone else. Mitre will still sometimes issue CVEs if a reporter appeals to them and claims the project is unresponsive or wrong to deny them a CVE. Can't really help that, but clear communication and processes can reduce the chances.

[dveditz]

In practice I would expect a large share of vulnerabilities in wgpu to be reported from Mozilla. We do a lot of our own fuzz testing, and external researchers will report things to us because they were interested in Firefox or (often) our bug bounty program. A policy will help us coordinate with you so that those CVEs can be published on your repo as well and not just in Firefox advisories.