Lines Matching +full:openbmc +full:- +full:security
1 # Security response team guidelines
3 These are the guidelines for OpenBMC security responders, including the security
5 problems reported by the [security vulnerability reporting process][].
7 Each project within OpenBMC works independently to resolve security
8 vulnerabilities. The security response team helps the maintainers, provides
9 consistency within the OpenBMC project, and helps to get CVEs assigned.
13 - Keep problems private until announce.
14 - Work with diligence.
15 - Keep stakeholders informed.
21 - Within a day, acknowledge you received the report. Note that reports are
23 - Communicate by opening the GitHub draft security advistory as soon as the
27 and OpenBMC).
29 - Determine if the problem is new or known.
30 - Determine if the problem is in OpenBMC.
31 - If the problem is in a project that OpenBMC uses, re-route the problem to
33 - Note that the problem may be in a customized version of OpenBMC but not
34 in OpenBMC itself.
35 - Determine which OpenBMC areas should address the problem.
36 - [Create the draft security advisory][] and populate its fields.
37 - The Ecosystem would normally be "OpenBMC" and the package name is
39 - Please describe when the problem was introduced to help users learn if
41 helpful to say what OpenBMC version is affected. For example, if the
42 problem in the original code through OpenBMC release 2.9, the affected
43 version is "<= 2.9". See [OpenBMC releases][].
44 - Use private channels, for example, email, GitHub draft security advistory,
46 - Inform contacts this is private work as part of the OpenBMC security
48 - Coordinate with all collaborators and keep them informed.
51 (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
55 - Submit the problem to another security response team, for example, the
56 [UEFI Security Response Team (USRT)][].
57 - Privately engage an OpenBMC maintainer or subject matter expert.
59 3. For OpenBMC problems.
63 2. Avoid pre-announcing problems. Be especially careful with high severity
67 - Consider [contributing][] using a Gerrit [private change][] if everyone
69 - Consider using [Patch set][] emails to make reviews accessible to all
72 - Publish a security advisory to the affected OpenBMC repository.
73 - Make the Gerrit review publicly viewable.
74 - Publish the CVE in the CVE database.
75 5. Improve OpenBMC processes to avoid future problems.
79 github.com/openbmc/<REPO>/security/advisories. Please follow guidance in the
80 [OpenBMC Security Advisory Template][]. Add the openbmc security-response group
81 and other stakeholders to the advisory. 3. Review the security bulletin with
84 For example, independent bugs should have separate CVEs. A security advisory can
85 reference multiple CVEs. When the CVE is known, add it to the security advisory,
87 For example: This fixes CVE-yyyy-nnnnn. Doing so helps downstream security
90 coordinated disclosure, plan to release the fix and the security advisory on the
93 public) publish the security advisory, and email the security-response team.
95 [security vulnerability reporting process]: ./obmc-security-response-team.md
97 [uefi security response team (usrt)]: https://uefi.org/security
101 https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
102 [openbmc releases]:
103 https://github.com/openbmc/docs/blob/master/release/release-notes.md
105 https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
107 [create the draft security advisory]:
108 …https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-secu…
109 [openbmc security advisory template]: obmc-github-security-advisory-template.md
113 The OpenBMC security response team has received the problem.
115 - Thank you for reporting this.
116 - Share preliminary results of the analysis.
117 - Share preliminary OpenBMC plans or that we are analyzing the problem.
118 - Set expectations for follow-up communications.
120 ## Template: OpenBMC Security Advisory
123 OpenBMC Security Advisory
132 The fix is in the https://github.com/openbmc/... repository as git
135 For more information, see OpenBMC contact information at
136 https://github.com/openbmc/openbmc file README.md.
141 ## Template: Security Advisory notice
143 When the Security Advisory is created, inform the OpenBMC community by sending
147 TO: openbmc-security@lists.ozlabs.org, openbmc@lists.ozlabs.org
148 SUBJECT: [Security Advisory] ${subject}
150 The OpenBMC Security Response team has released an OpenBMC Security Advisory:
153 An OpenBMC Security Advisory explains a security vulnerability, its severity,
154 and how to protect systems that are built on OpenBMC. For more information
155 about OpenBMC Security Response, see:
156 https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md
163 - https://bestpractices.coreinfrastructure.org/en/projects/34
164 - https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html
165 - https://oss-security.openwall.org/wiki/mailing-lists/distros
166 - [ISO/IEC 29147:2018 vulnerability disclosure](https://www.iso.org/standard/72311.html)
170 The security response team (SRT) is controlled by the OpenBMC Technical Steering
174 - Although individuals join the SRT, it is really organizations which join as
176 - Participate in their organization's SRT.
177 - Designate backup OpenBMC SRT members.
178 - Share OpenBMC security vulnerability information within their organization
180 - Membership is intended for organizations which have a vested interest in
181 OpenBMC security response. Here are some examples to consider:
182 - Organizations which have products or services built on OpenBMC which are
183 publicly available and disclose security bugs to their users. This includes
184 systems directly built on OpenBMC, and larger systems such as data centers.
185 - Organizations which focus on BMC security research or security response.
186 - Evaluation of an organization may be based on its members' OpenBMC community
187 roles, technical skills, and expertise responding to security incidents.
188 - Membership should not be granted without compelling reason. The intention is
189 to avoid premature disclosure of security vulnerabilities by limiting
192 The security response team uses the `openbmc-security at lists.ozlabs.org`
194 membership reflects the composition of the security response team. The list
196 `https://lists.ozlabs.org/listinfo/openbmc-security`.
206 `for privately reporting OpenBMC security vulnerabilities` with description:
207 This email list is for privately reporting OpenBMC security vulnerabilities.
208 List membership is limited to the OpenBMC security response team. For more
210 https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
215 Thanks for your interest in OpenBMC security. Subscriptions to the
216 openbmc-security@lists.ozlabs.org email list are by invitation only
217 and are typically extended only to security response team members.
218 For more information, see https://github.com/openbmc/docs/security or
219 attend a security working group meeting:
220 https://github.com/openbmc/openbmc/wiki/Security-working-group.
223 OpenBMC security response team