Use github security advisories
This updates the OpenBMC security vulnerability reporting process
to use GitHub advisories. Each repository owner/maintainer is
responsible for their security problems, and the security response
team advises and creates CVEs.
Signed-off-by: Joseph Reynolds <joseph-reynolds@charter.net>
Change-Id: Ic9e169b4c94b625c9af838ef0c03c78fa0300031
diff --git a/security/how-to-report-a-security-vulnerability.md b/security/how-to-report-a-security-vulnerability.md
index 7680936..c242778 100644
--- a/security/how-to-report-a-security-vulnerability.md
+++ b/security/how-to-report-a-security-vulnerability.md
@@ -5,33 +5,49 @@
public disclosure.
The main ideas are:
- - You have information about a security problem which is not yet
- publicly available.
+ - You have information about a security problem or vulnerability which is not
+ yet publicly available.
- You want the problem fixed before public disclosure and
you are willing to help make that happen.
- You understand the problem will eventually be publicly disclosed.
-To begin the process:
- - Send an email to `openbmc-security at lists.ozlabs.org` with details
- about the security problem such as:
- - the version and configuration of OpenBMC the problem appears in
- - how to reproduce the problem
- - what are the symptoms
- - As the problem reporter, you will be included in the email thread
- for the problem.
+To begin the process: Privately contact the OpenBMC security response team and
+(if known) the project maintainer:
+ - Suggest sending an email. Use `openbmc-security at lists.ozlabs.org`.
+ - If you know which source code repository is affected, find the repository
+ owner or maintainer contact information in the OWNERS or MAINTAINERS file.
+ If not, the security response team will help route the problem.
+ - Include details about the security problem such as:
+ - The version and configuration of OpenBMC the problem appears in.
+ - How to reproduce the problem.
+ - What are the symptoms.
+ - As the problem reporter, you will be included in the problem response.
-The OpenBMC security response team (SRT) will respond to you and work to
-address the problem. Activities may include:
+Please note the OpenBMC project has multiple source code repositories. Each
+has separate owners. If you do not know which repository is affected, the
+owner or the security response team can help you route the problem.
+
+When the project owners get a new security problem, they will create a [GitHub
+security advisory][] in their repository and begin work. The advisory has
+draft status which means only the collaborators can see it. Collaborators
+should be added as follows:
+ - The problem reporter.
+ - The OpenBMC security response team.
+ - Developers responsible for fixing the problem.
+
+The collaborators work to resolve the problem. Activities may include:
+ - The OpenBMC [CVE Numbering Authority (CNA)][] (members of the OpenBMC
+ security response team) will help clarify the problem and assign CVEs.
- Privately engage community members to understand and address the
problem. Anyone brought onboard should be given a link to the
OpenBMC [security response team guidelines][].
- Work to determine the scope and severity of the problem,
such as [CVSS metrics][].
- - Work to create or identify an existing [CVE][].
- Coordinate workarounds and fixes with you and the community.
- Coordinate announcement details with you, such as timing or
how you want to be credited.
- - Create an OpenBMC security advisory.
+ - At the agreed time, publish the OpenBMC security advisory, reveal the fix,
+ and publish the CVE.
Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
@@ -50,3 +66,5 @@
[CVSS metrics]: https://www.first.org/cvss/calculator/3.0
[CVE]: http://cve.mitre.org/about/index.html
[CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
+[GitHub security advisory]: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
+[CVE Numbering Authority (CNA)]: https://www.cve.org/ProgramOrganization/CNAs
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index 21e3491..34e308d 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -1,25 +1,26 @@
# Security response team guidelines
-These are the guidelines for the security response team members
-including OpenBMC community members who are responding to problems
-reported by the [security vulnerability reporting process][].
+These are the guidelines for OpenBMC security responders, including the
+security response team, project owners, and community members who are
+responding to problems reported by the [security vulnerability reporting
+process][].
-The security response team (SRT) coordinates activity to address privately
-disclosed security vulnerabilities, engages resources to address them,
-and creates security advisories.
+Each project within OpenBMC works independently to resolve security
+vulnerabilities. The security response team helps the maintainers, provides
+consistency within the OpenBMC project, and helps to get CVEs assigned.
Here are the primary expectations:
- - Keep problems private until announce
- - Work with diligence
- - Keep stakeholders informed
+ - Keep problems private until announce.
+ - Work with diligence.
+ - Keep stakeholders informed.
Workflow highlights:
1. Handle new problem reports.
- Within a day, acknowledge you received the report.
Note that reports are archived in the mailing list.
- - Communicate within the security response team, typically by
- cc'ing the openbmc-security email list.
+ - Communicate by opening the GitHub draft security advistory as soon as
+ the problem is known.
2. Analyze the problem and engage collaborators as needed (upstream,
downstream, and OpenBMC).
@@ -30,15 +31,20 @@
- Note that the problem may be in a customized version of
OpenBMC but not in OpenBMC itself.
- Determine which OpenBMC areas should address the problem.
- - Draft a CVE-like report which includes only:
- * the vulnerability description: omit OpenBMC specifics
- * [CVSS metrics][] with explanations as needed
- * CVE identifiers, if known
- - Gather data for the security advisory (see template below).
- - Use private channels, e.g., email.
+ - [Create the draft security advisory][] and populate its fields.
+ - The Ecosystem would normally be "OpenBMC" and the package name
+ is normally the repository.
+ - Please describe when the problem was introduced to help users
+ learn if they are affected. Use Git tags and commit IDs if
+ known. It also may be helpful to say what OpenBMC version is
+ affected. For example, if the problem in the original code
+ through OpenBMC release 2.9, the affected version is "<= 2.9".
+ See [OpenBMC releases][].
+ - Use private channels, for example, email, GitHub draft security
+ advistory, or private direct messaging.
- Inform contacts this is private work as part of the OpenBMC
security response team. For example, link to these guidelines.
- - Coordinate with all stakeholders and keep them informed.
+ - Coordinate with all collaborators and keep them informed.
Considerations in the [CERT Guide to Coordinated Vulnerability
Disclosure][] (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
@@ -62,11 +68,9 @@
- Consider using [Patch set][] emails to make reviews accessible to
all stakeholders.
4. When agreed:
- - Publish a security advisory to
- https://github.com/openbmc/openbmc/issues and email list
- openbmc@lists.ozlabs.org.
+ - Publish a security advisory to the affected openBMC repository.
- Make the Gerrit review publicly viewable.
- - Email the Security Advisory to the OpenBMC community (see below).
+ - Publish the CVE in the CVE ddatabase.
5. Improve OpenBMC processes to avoid future problems.
[security vulnerability reporting process]: ./obmc-security-response-team.md
@@ -74,8 +78,10 @@
[UEFI Security Response Team (USRT)]: https://uefi.org/security
[CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
[contributing]: https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
+[OpenBMC releases]: https://github.com/openbmc/docs/blob/master/release/release-notes.md
[private change]: https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
[Patch set]: https://en.wikipedia.org/wiki/Patch_(Unix)
+[Create the draft security advisory]: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
## Template: Initial response to the problem submitter
The OpenBMC security response team has received the problem.
diff --git a/security/obmc-security-response-team.md b/security/obmc-security-response-team.md
index 7c42698..0093852 100644
--- a/security/obmc-security-response-team.md
+++ b/security/obmc-security-response-team.md
@@ -12,13 +12,17 @@
The basic workflow is:
1. A community member reports a problem privately to the security
- response team.
- 2. The response team works to understand the problem and privately
- engages community members to resolve it.
- 3. Workarounds and fixes are created, reviewed, and approved.
- 4. The security response team creates an OpenBMC security advisory
- which explains the problem, its severity, and how to protect
- your systems that were built on OpenBMC.
+ response team (and to the repository maintainers if known).
+ 2. The responders (including the security response team, the
+ repository maintainers, and the problem submitter) work to
+ understand the problem.
+ 3. The repository maintainer creates an OpenBMC security advisory
+ which explains the problem, its severity, and how to protect your
+ systems that were built on OpenBMC.
+ 4. The responders privately engage community members to create
+ workarounds and fixes and to negotiate disclosure dates.
+ 5. The OpenBMC security advisory is published along with any
+ accompanying CVEs.
Note that the OpenBMC security response team is distinct from the
OpenBMC security working group which remains completely open.
@@ -28,7 +32,7 @@
vulnerability and get a fix for it before public announcement of the
vulnerability.
-The `openbmc-security@lists.ozlabs.org` email address is the primary
+The `openbmc-security at lists.ozlabs.org` email address is the primary
communication vehicle between the person who reported the problem and
the security response team, and the initial communication between the
security response team members.