Security policy

[andyleiserson]

Proposal for a security policy. Would fix #6874.

This would appear in the security tab on GitHub. For an example of what the page would look like, see https://github.com/tc39/ecma262/security/. (Signed-in repository collaborators looking at the page for wgpu will see something different.)

Since the vulnerability reports will appear on that page adjacent to the policy, I haven't explicitly stated in the document where reports are published.

[ErichDonGubler]

This seems like an excellent first iteration. I have some easy suggestions I thought of.

Not going to merge this immediately, since it's important we have consensus here. I'd like to at least see explicit approval from @teoxoy, @cwfitzgerald, and @jimblandy. Shouldn't be controversial, though, since you showed this to us in the 2025-07-23 maintainers meeting. 🙂

[ErichDonGubler]

suggestion: This is a good link, but per the guidance below, I think it'd be even better to bake the security-relevant groups (core-security, gfx-core-security) into the link, too, so they're ticked by default, i.e.:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A+WebGPU&groups=core-security&groups=gfx-core-security

One less potential paper cut big problem to run into. 🙂

[andyleiserson]

I don't know what we might do based on the URL behind the scenes, but the checkbox for the graphics security bug group only shows up if you're in the group. I assume the desire is to have a single ingress point for reports, or maybe that's just a default behavior of groups in bugzilla without any intention for the graphics security group in particular.

[ErichDonGubler]

Just tried running through my proposed link through a private window. Looks like it doesn't check the box like it does when using an employee account. Nuts! It doesn't seem to hurt anything (the end result was bug 1979455), but it also doesn't actually solve anything for the audience I was hoping for, either. 🤔

I guess I'd suggest using the URL anyway, since at least it'd save a step for folks who already have group membership? Not firmly set on that, though. 🤷🏻‍♂️

[ErichDonGubler]

suggestion: I think we should also include the gfx-core-security group checkbox, whose current text of which is Security-Sensitive Graphics Bug.

[ErichDonGubler]

Given discussion, if this note is added, it'd need to be acknowledged that somebody might not see it if they're not part of the Graphics security group.

[cwfitzgerald]

Looks good! I have a comment but none of this is blocking and feel free to push the comments

[cwfitzgerald]

It would be good to give a bit more what classifies as a security issue here as this is a decision point:

Suggested change

	about: Information about reporting possible vulnerabilities.
	about: Information about reporting possible vulnerabilities. For example: use after free, buffer overruns, etc; panics and null pointers dereferences however are not security sensitive.

[ErichDonGubler]

Links to some encyclopedic content to build intuition would also be neat! 😀

[kpreid]

Since these links are displayed in-line nearly identically to issue templates, I think it would be good if the description was more aligned with what the user is possibly trying to do. Something like:

If you have found a possible vulnerability in wgpu, please read this security policy to understand how to report it.

[cwfitzgerald]

SGTM

[kpreid]

Isn't the name of the project generally written “wgpu”, not “WGPU”? Not that that isn’t awkward sometimes, but this should be consistent with the rest of the project documentation.

(Arguably, though, the name wgpu should be interpreted as referring to the Rust crate wgpu, which I assume isn't used by Firefox for its WebGPU implementation?)

[andyleiserson]

It looks like we don't use either one consistently. The README uses "wgpu", but the GOVERNANCE and CONTRIBUTING documents use "WGPU".

I'm happy to change this document to whichever is preferred.

[kpreid]

I think this paragraph could benefit from spelling out its point more explicitly, because the following text could be taken as limiting the scope of what is a vulnerability (“we mostly care about JavaScript WebGPU”), rather than expanding it (“we care about protection from misuse, not just doing the wrong thing in response to valid-according-to-the-spec input”). So, how about saying something like:

Suggested change

	outside the intended scope for interaction with web content.
	outside the intended scope for interaction with web content.
	Therefore, `wgpu` seeks to prevent undefined behavior and data
	leaks even when its API is misused, and failures to do so may be
	considered vulnerabilities.
	(This is also in accordance with the Rust principle of safe vs. unsafe code,
	since the `wgpu` library exposes a safe API.)

[andyleiserson]

This seems reasonable to me, but I'll wait for some more input before changing it.

The scope as I wrote it was intentionally narrow, because I didn't want to sign the project up for more work than necessary. But that concern aside, I agree that UB or data leaks reachable from the API ought to be considered a vulnerability.

[teoxoy]

LGTM