Security response team membership guidelines
This better articulates the guidelines for who should be on the
security response team and clarifies that membership is based on
participating organizations.
Signed-off-by: Joseph Reynolds <joseph-reynolds@charter.net>
Change-Id: Ia331bf1dec4e75b86d448561c82f4096c9a17c12
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index 76be9c0..21e3491 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -18,7 +18,7 @@
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 be
+ - Communicate within the security response team, typically by
cc'ing the openbmc-security email list.
2. Analyze the problem and engage collaborators as needed (upstream,
@@ -130,10 +130,27 @@
## Team composition and email maintenance
-The security response team is controlled by the OpenBMC Technical
-Steering Committee. Membership is restricted to a core group, with
-selection based upon their community role(s), experience, and
-expertise responding to security incidents.
+The security response team (SRT) is controlled by the OpenBMC Technical
+Steering Committee, including membership on the team. General
+considerations for SRT membership:
+- Although individuals join the SRT, it is really organizations which join as
+ represented by their SRT members. The SRT members are expected to:
+ - Participate in their organization's SRT.
+ - Designate backup OpenBMC SRT members.
+ - Share OpenBMC security vulnerability information within their organization
+ with the same care as stated in this document.
+- Membership is intended for organizations which have a vested interest in
+ OpenBMC security response. Here are some examples to consider:
+ - Organizations which have products or services built on OpenBMC which are
+ publicly available and disclose security bugs to their users. This
+ includes systems directly built on OpenBMC, and larger systems such as
+ data centers.
+ - Organizations which focus on BMC security research or security response.
+- Evaluation of an organization may be based on its members' OpenBMC community
+ roles, technical skills, and expertise responding to security incidents.
+- Membership should not be granted without compelling reason. The intention
+ is to avoid premature disclosure of security vulnerabilities by limiting
+ membership to those with vested interest.
The security response team uses the `openbmc-security at
lists.ozlabs.org` private email list as a channel for confidential