Security policy #8006
Security policy #8006
Conversation
There was a problem hiding this comment.
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. 🙂
SECURITY.md
Outdated
| obtained from a trusted developer, WebGPU makes GPU APIs available to | ||
| arbitrary web applications. In the threat model of the web, malicious | ||
| content should not be able to use the GPU APIs to access data or interfaces | ||
| outside the intended scope for interaction with web content. |
There was a problem hiding this comment.
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:
| 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.) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I think kpreids suggestion is fine and we should adopt it.
There was a problem hiding this comment.
What about the experimental APIs? They explicitly call out they may have UB and should be used with caution. Would these still get vulnerability reports? If so what would happen?
There was a problem hiding this comment.
@Vecvec I don't think the intent is to make a firm rule that UB in an experimental API is a vulnerability. It's more a statement that the sentiment of the project is that UB is always bad, so it would always be a bug if you can get UB by misusing the API. (Arguably that should be a given for a safe API, but in this context it's worth stating a position on arguable points.)
It doesn't show up in this comment thread, but the paragraph immediately following this should help to provide some clarity that experimental APIs are not held to the same standard.
There was a problem hiding this comment.
Sorry, it's not the paragraph immediately following. It's the one a bit later starting "The WGPU Rust API offers some functionality, both supported and experimental...".
There was a problem hiding this comment.
To give some examples, I'd say that a simple RCE of the form "I give wgpu this carefully crafted buffer and it executes part of it with no sandbox" is a vulnerability, even in an experimental API. RCE of the form "if you have X and Y in memory for use as ROP gadgets and I can guess the stack canary and it's a particular phase of the moon" might not be a vulnerability in an experimental API. A DoS using a core API might be a vulnerability, a DoS using an experimental API is unlikely to be considered a vulnerability.
But fundamentally, it's often not possible to anticipate what will go wrong; the goal here is just to have some security policy in place to make it clear that we do care about security, and to explain how to report vulnerabilities. Severity (on a scale down to "not a vulnerability at all") has to be assessed on a case-by-case basis.
There was a problem hiding this comment.
It doesn't show up in this comment thread, but the paragraph immediately following this should help to provide some clarity that experimental APIs are not held to the same standard.
Ah yes, I see it now.
Co-authored-by: Kevin Reid <kpreid@switchb.org>
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.