RFC notifications bot (Feb 17 2022 at 23:27): RFC notifications bot (Feb 17 2022 at 23:27):pchickey opened PR #20 from pch/vuln_runbook to main:
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:
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-88xq-w8cq-xfg7
https://github.com/bytecodealliance/lucet/security/advisories/GHSA-hf79-8hjp-rrvq
RFC notifications bot (Feb 18 2022 at 00:01):bjorn3 created PR review comment:
No individual or organization is entitled to advanced disclosure. Advanced disclosure is
RFC notifications bot (Feb 18 2022 at 00:01):bjorn3 submitted PR review.
RFC notifications bot (Feb 18 2022 at 00:02):bjorn3 created PR review comment:
not guaranteed to organizations by membership in the Bytecode Alliance, nor is it exclusive
RFC notifications bot (Feb 18 2022 at 00:02):bjorn3 submitted PR review.
RFC notifications bot (Feb 18 2022 at 00:05):bjorn3 submitted PR review.
RFC notifications bot (Feb 18 2022 at 00:05):bjorn3 created PR review comment:
If the individual who discovered the vulnerability doesn't have a github account what is the intended procedure? Provide their name and or website in the security advisory body? Or something else?
RFC notifications bot (Feb 18 2022 at 00:09):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Feb 18 2022 at 00:09):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Feb 18 2022 at 00:09):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Feb 21 2022 at 19:27):jfoote submitted PR review.
RFC notifications bot (Feb 21 2022 at 19:27):jfoote submitted PR review.
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
Pick an individual who will track that the entire process in this document is followed.
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
collaborate on a patch. GitHub will create a private fork of the repository on
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
disclosure date with stakeholders who have received advanced to understand their feasibility
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
to resolve the vulnerability. This patch is automatically merged into the
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
The highest severity issue fixed in this release is <severity>, based on the
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
Security Advisories may not assign blame to individuals or organizations
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
disclosure to trustworthy stakeholders. All stakeholders who receive advanced disclosure
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
What should the reader do then? Maybe email security@bytecodealliance.org or ping folks on Zulip?
RFC notifications bot (Feb 21 2022 at 19:27):jfoote created PR review comment:
This runbook is a great baseline for situations where a vulnerability has been reported or discovered privately. Should we add some brief guidance here on what a reader should do if an unpatched vulnerability is under active exploitation? Or if details of a private (or previously unknown) vulnerability were made public without coordination.
It could be something simple like this...
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.Or we could build out more process for these cases proactively.
RFC notifications bot (Feb 22 2022 at 14:48):bnjbvr submitted PR review.
RFC notifications bot (Feb 22 2022 at 14:48):bnjbvr submitted PR review.
RFC notifications bot (Feb 22 2022 at 14:48):bnjbvr created PR review comment:
The cautiousness in this section is very close to "security through obscurity", as it tries to limit shared knowledge by asserting that this augments trust within the Alliance. The counter argument is that not trusting by default (and only include arbitrarily trusted people within the Alliance) sounds more like the opposite of trust.
Additionally, basing the selection of contacts on socialization has limits: it doesn't look like it would scale well with an increasing number of organizations in the Bytecode Alliance, times an increasing number of projects hosted by the Bytecode Alliance. In fact, it's unclear what should be the topics of socialization, and with which depth one should share implementation details that might also require an individual organization's discretion (think NDA).
I think there's an opportunity to do better here. We could imagine sharing light details with technical contacts of each Bytecode Alliance organization, on an internal but private secured channel (e.g. Signal, or any other equally valid broadcasting secured mechanism), that would make it possible for members to know if they're effectively affected or not. That could include, for example: patterns to look for in error logs, in the case of Wasmtime examples of
Config()that would be affected by the security issue, metrics to watch and for which outliers could indicate potential exploitation in the wild. Other useful information could be shared according to the context around the security issue. After sharing that information, technical contacts could confirm whether they're impacted or not, and if impacted some extra actions could take place to ensure the issue might be mitigated for them (temporary patches for mitigations? getting early access to the CVE? request filters if Web/cloud providers? Each issue is likely to have its own set of temporary and useful countermeasures).Of course this process doesn't pretend to be perfect and could be adapted. I think that in general, this would spur trust within the Bytecode Alliance and across its different members, by trusting by default instead of assuming the worst (notably that insiders would leak the exploit). Some entities might and will run Bytecode Alliance projects in production and they could be badly impacted if they had to schedule updates at the last minute, would they never hear about a security issue, because it was incorrectly decided (due to ineffective/incomplete/poor "socialization") that they would not be impacted.
RFC notifications bot (Feb 28 2022 at 17:00):pchickey submitted PR review.
RFC notifications bot (Feb 28 2022 at 17:00):pchickey created PR review comment:
That sounds right to me! When I wrote this up I decided to not build out process for things we hadn't really encountered yet. I have faith our community will be able to navigate those problems when we get there, but I don't want to write up how I wish things will go, but rather how we have done things successfully in the past.
RFC notifications bot (Feb 28 2022 at 17:01):pchickey submitted PR review.
RFC notifications bot (Feb 28 2022 at 17:01):pchickey created PR review comment:
repositories, this guide may not work. In situations not covered by this guide, please email security@bytecodealliance.org to seek guidance.
RFC notifications bot (Feb 28 2022 at 17:03):pchickey submitted PR review.
RFC notifications bot (Feb 28 2022 at 17:03):pchickey created PR review comment:
Name in the body sounds fine to me, I don't have any strong opinion on this and I expect that the incident manager will use some judgement to accommodate the wishes of anyone who should be credited.
RFC notifications bot (Feb 28 2022 at 17:04):pchickey submitted PR review.
RFC notifications bot (Feb 28 2022 at 17:04):pchickey created PR review comment:
credited through their GitHub account. The incident manager can decide how to accommodate creditees who do not wish to use the GitHub mechanism.
RFC notifications bot (Feb 28 2022 at 17:04):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Feb 28 2022 at 17:11):pchickey submitted PR review.
RFC notifications bot (Feb 28 2022 at 17:11):pchickey created PR review comment:
I hear your concerns, but I don't think I am the right person to address them. When I wrote this up, I my goal was to document the principles we used to navigate this in the past, rather than come up with an improved system. I will have to defer to @tschneidereit and other Bytecode Alliance leaders on this topic.
RFC notifications bot (Feb 28 2022 at 17:19):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Aug 17 2022 at 18:21):fitzgen submitted PR review.
RFC notifications bot (Aug 17 2022 at 18:21):fitzgen created PR review comment:
This RFC has been open and stalled for a while now, and I think it has a lot of really good stuff in it that is helpful for the people dealing with these rare security bugs. No, this RFC does not have all the answers and there are improvements we can make. However, it is still a super helpful resource for when folks are caught up in the midst of a security bug. And there is no reason we can't further refine our processes with future RFCs.
With all that said, would you be okay if we moved to merge this RFC, @bnjbvr?
RFC notifications bot (Aug 18 2022 at 09:56):bnjbvr submitted PR review.
RFC notifications bot (Aug 18 2022 at 09:56):bnjbvr created PR review comment:
Agreed that there's lots of goodness in this runbook!
I would be fine with merging, if we removed those three paragraphs I commented about (since there's been no discussion about the core issue I'm flagging here, and it looks quite important to me to, at the very least, discuss). Approving the RFC as it is right now would mean turning this into the default, widely accepted measure, and since communication has stalled as you point, anybody opening a PR to change that would likely face a similar stall situation, adding way more friction to changing the wording here. Does that sound reasonable?
RFC notifications bot (Aug 18 2022 at 17:16):fitzgen submitted PR review.
RFC notifications bot (Aug 18 2022 at 17:16):fitzgen created PR review comment:
That seems like a reasonable path forward to me. @pchickey sound good to you?
RFC notifications bot (Aug 18 2022 at 18:25):pchickey updated PR #20 from pch/vuln_runbook to main.
RFC notifications bot (Aug 18 2022 at 18:26):pchickey created PR review comment:
Agreed, and done!
RFC notifications bot (Aug 18 2022 at 18:26):pchickey submitted PR review.
RFC notifications bot (Aug 18 2022 at 18:40):bnjbvr submitted PR review.
RFC notifications bot (Aug 18 2022 at 23:51):radu-matei submitted PR review.
RFC notifications bot (Aug 19 2022 at 09:46):bjorn3 submitted PR review.
RFC notifications bot (Aug 24 2022 at 18:07):uweigand submitted PR review.
RFC notifications bot (Aug 29 2022 at 20:25):fitzgen merged PR #20.
Last updated: Nov 22 2024 at 17:03 UTC