RFC: Vulnerability response runbook

accepted/vulnerability-response-runbook.md

@@ -0,0 +1,203 @@
+# Bytecode Alliance Vulnerability Response Runbook
+
+## Select an Incident Manager
+
+Pick an individual who will track that the the entire process in this document isfollowed.
+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.
+
+## 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
+collaboate 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 vulnerabilty. 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 recieve advanced disclosure
+must maintain secrecy of the vulnerability until public disclosure is made.
+
+The incident manager determines who is a trustworthy stakeholder in a vulnerability,
+and what sort of advanced disclosure to make to each stakeholder. This could mean
+giving a stakeholder complete access to the advisory draft and patch, or providing only
+more limited information, such as a warning that a vulnerability exists and a public
+disclosure is expected on a given date.
+
+Bytecode Alliance members are encouraged to socialize which projects they rely on
+in production so that incident managers know to consider them for advanced disclosure.
+
+No individual or organization is entitled to advanced disclosure. Advanced disclosure is
+not guaranteed to organizations by membership in the Bytecode Alliance, nor is it exclusive
+to Bytecode Alliance members. Selecting stakeholders for advanced disclosure appropriately
+is critical for maintaining trust in the Bytecode Alliance and its projects.
+
+## 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 recieved 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
+[`[email protected]` 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 <project>.
+
+The release will be made available on <date> at approximately <time> UTC.
+Additionally, an advisory will be made available on <date> at approximately
+<time> at https://github.com/advisories.
+
+The highes severity issue fixed in this release is <severity>, based on the
+classification scheme defined in the OpenSSL Security Policy.
+
+<non-affected projects> Bytecode Alliance projects are unaffected.
+```
+
+
+## Finalize the security advisory
+
+Improve the draft description of the security advisory into a public facing
+document.
+
+Security Advisories may not assign blame to individuals or orginizations
+who introduced or contributed to the vulnerability.
+
+Security Advisories may credit individuals who contributed to discovering and
+remediating the vulnerability. Use the credit feature of the GitHub Security
+Advisory to do so. This feature requires individuals to consent to being
+credited through their GitHub account.
+
+### Template
+
+```pre
+
+# Impact
+
+Describe the impact of the vulnerability here.
+
+If the vulnerability is only accessible in some configurations, describe those
+here.
+
+# Patches
+
+Describe how to get the patches: which versions of which packages to upgrade
+to.
+
+# Workarounds
+
+If its possible to avoid the issue through configuration, describe how.
+
+# Description
+
+Detailed description of the vulnerability here. 
+
+```
+
+## Public Disclosure
+
+This is the final step! On the determined date and time for disclosure,
+perform the following tasks:
+
+* click publish on the GitHub security advisory. This also has the
+  side-effect of merging all PRs in the security advisory fork into the
+  public repository.
+* send an email to `sec-announce` with the contents of the advisory.
+* publish any packages to the appropriate package registries.
+