diff --git a/accepted/vulnerability-response-runbook.md b/accepted/vulnerability-response-runbook.md new file mode 100644 index 0000000..3d87691 --- /dev/null +++ b/accepted/vulnerability-response-runbook.md @@ -0,0 +1,200 @@ +# Bytecode Alliance Vulnerability Response Runbook +This document describes a series of steps to be followed by the Bytecode Alliance team when responding to a vulnerability that is discovered or reported privately. + +This document does not cover cases where vulnerabilities are publicly disclosed without coordination. Or cases where unpatched vulnerabilities are under active exploitation. In those cases, contact security@bytecodealliance.org. +## Select an Incident Manager + +Pick an individual who will track that the entire process in this document is followed. +By default, the person inside Bytecode Alliance who discovers or learns of the +vulnerability first has this duty, until they explicitly hand if off to +someone else. + +## Identifying the Vulnerability + +Figure out what bytecode alliance repository it lives in. + +The vulnerability probably lives in one single repository in the Bytecode +Alliance ecosystem. If fixing it requires coordinated work across two +repositories, this guide may not work. In situations not covered by this guide, please +email security@bytecodealliance.org to seek guidance. + +## Create a GitHub Security Advisory Draft + +Under the "Security" tab for each repo, you can [create a new draft security +advisory.](https://github.com/bytecodealliance/wasmtime/security/advisories/) + +### Affected product + +Identify the package the vulnerability primarily exists in. This, and all +packages in the Bytecode Alliance org which depend on that package, should +be identified as an Affected Product. + +You can leave the Patched versions blank in the draft to start. + +### Determine Severity + +We follow the Severity levels defined in the [OpenSSL Security +Policy](https://www.openssl.org/policies/secpolicy.html). + +### Draft a Description + +The initial description doesn't have to be polished for public disclosure - it +can be edited throughout the draft process. The initial purpose of this +description is to communicate to collaborators what the vulnerability is. +It needs to be sufficient for GitHub Staff to spot-check the draft when +requesting a CVE. + +### Request a CVE + +Once you have a draft description, you should have GitHub request a CVE on +your behalf. During US west coast business hours, this typically takes under 2 +hours to process. If it takes more than a day, ping Bytecode Alliance partners +who may have contacts at GitHub, where they can inquire on why the process is +stuck. You can keep working on everything while this request is pending. + +## Invite collaborators to the Security Advisory Draft + +The incident manager is responsible for selecting trustworthy individuals to collaborate +on authoring the security advisory and its patch. The set of collaborators should be +kept as small as possible. It should include an individual who is a code reviewer on +each Bytecode Alliance project affected by the vulnerability. + +GitHub Security Advisories let you invite individuals to collaborate on the draft. +Collaborators will be able to view and edit the advisory, and push and pull commits +to the private repository where the patch is under development. + +## Collaborate on a patch + +Use the security release PR features in the GitHub Security Advisory to +collaborate on a patch. GitHub will create a private fork of the repository on +your behalf and invite the advisory collaboators to it. + +In the private fork repository, create a single PR which will track the patch +to resolve the vulnerability. This patch is automatically merged into the +public repository's default branch when the disclosure is made public. + +Cloud-based CI (github actions or otherwise) will not run on the security +advisory fork. Collaborators are responsible for running CI locally before +pushing to the PR branch. + +Use the PR review features to indicate approval for the patch. + +### Releases as part of the patch + +Wasmtime has committed that security issues will be applied to the current +version of Wasmtime, and released as patch releases: see [Wasmtime 1.0 +RFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-one-dot-oh.md#backports---security-fixes) + +Other projects without an existing policy should do the same, unless they have +a very good reason for issuing backports. + +The patch PR should increment any version numbers required to make the patch +release. The merged PR should be immediately publishable to package registries +when the disclosure is made public. Create a merge commit and run your package +publishing tools in dry-run mode to verify this ahead-of-time as much as +possible. + +## Advanced disclosure to stakeholders + +The incident manager is responsible for identifying the downstream making advanced +disclosure to trustworthy stakeholders. All stakeholders who receive advanced disclosure +must maintain secrecy of the vulnerability until public disclosure is made. + +## Commit to a public disclosure date + +Once you have confidence in a patch, and stakeholders have been pre-notified, it is +time to determine a date for public disclosure. Incident managers may discuss the public +disclosure date with stakeholders who have received advanced to understand their feasibility +and timelines for mitigation. + +By default, public disclosure should be no more than 30 days after initial discovery +of the vulnerability. Incident managers are encouraged to select the shortest timeline +possible. + +However, the incident manager may make an exception to the 30 day limit if the +nature of the vulnerability requires it. Reasons for exceptions may include the +technical feasibility of mitigating the vulnerability, or coordination with other +security disclosure processes. Do not make exceptions lightly: inappropriate exceptions +may undermine trust in the Bytecode Alliance and its projects. + +## Notify sec-announce + +Once you have committed to a disclosure date, send an email to the +[`sec-announce@bytecodealliance.org` Google +Group](https://groups.google.com/a/bytecodealliance.org/g/sec-announce). + +This email should use this template: + +```pre +The Bytecode Alliance would like to announce the forthcoming security release +of the . + +The release will be made available on at approximately