RFC: Vulnerability response runbook #20
Conversation
|
On initial read, this looks really good and is quite complete! Only thing I would add is that, if the vulnerability is in a Rust crate used by others, adding an entry to the rustsec database is a good last step, after the CVE exists and is public. An example PR is here for last year's Cranelift CVE. |
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
|
(Forgot to say, sorry!) Great write-up, this definitely will streamline and structure the incident handling process! |
|
@cfallin Thanks, added a RustSec database step to the final section. We haven't been consistent in publishing to that database, but there is no reason not to be. |
Motion to finalize with a disposition to mergeThis RFC was forgotten for a little while with one piece of unresolved feedback, which has now been resolved. We have been using it de-facto during the time it was open. Stakeholders sign-offThis effects all Bytecode Alliance projects so I've copied the biggest stakeholder list I could find (#14) and added some new folks. I apologize if I missed anyone, I am happy to add folks. ArmDFINITYEmbark StudiosFastly
Google/EnvoyIntelMicrosoftFermyonMozillaIBMwasmCloudUnaffiliated |
|
As per the RFC process this RFC is entering its 10 day final comment period. If no objections have been raised by 2022-08-28, we will merge this RFC. |
|
The final comment period has elapsed without any objections, so I'm going to merge this! |
This RFC proposes the vulnerability response process used by the Bytecode Alliance. It is structured as a runbook: a set of steps to be followed by the team responding to a discovered vulnerability.
It documents the process we followed for several different security advisories in Wasmtime and Lucet, for example:
GHSA-88xq-w8cq-xfg7
GHSA-hf79-8hjp-rrvq