1# How to report a security vulnerability
2
3This describes how you can report an OpenBMC security vulnerability
4privately to give the project time to address the problem before
5public disclosure.
6
7The main ideas are:
8 - You have information about a security problem or vulnerability which is not
9   yet publicly available.
10 - You want the problem fixed before public disclosure and
11   you are willing to help make that happen.
12 - You understand the problem will eventually be publicly disclosed.
13
14To begin the process: Privately contact the OpenBMC security response team and
15(if known) the project maintainer:
16 - Suggest sending an email.  Use `openbmc-security at lists.ozlabs.org`.
17 - If you know which source code repository is affected, find the repository
18   owner or maintainer contact information in the OWNERS or MAINTAINERS file.
19   If not, the security response team will help route the problem.
20 - Include details about the security problem such as:
21   - The version and configuration of OpenBMC the problem appears in.
22   - How to reproduce the problem.
23   - What are the symptoms.
24 - As the problem reporter, you will be included in the problem response.
25
26Please note the OpenBMC project has multiple source code repositories.  Each
27has separate owners.  If you do not know which repository is affected, the
28owner or the security response team can help you route the problem.
29
30When the project owners get a new security problem, they will create a [GitHub
31security advisory][] in their repository and begin work.  The advisory has
32draft status which means only the collaborators can see it.  Collaborators
33should be added as follows:
34 - The problem reporter.
35 - The OpenBMC security response team.
36 - Developers responsible for fixing the problem.
37
38The collaborators work to resolve the problem.  Activities may include:
39 - The OpenBMC [CVE Numbering Authority (CNA)][] (members of the OpenBMC
40   security response team) will help clarify the problem and assign CVEs.
41 - Privately engage community members to understand and address the
42   problem.  Anyone brought onboard should be given a link to the
43   OpenBMC [security response team guidelines][].
44 - Work to determine the scope and severity of the problem,
45   such as [CVSS metrics][].
46 - Coordinate workarounds and fixes with you and the community.
47 - Coordinate announcement details with you, such as timing or
48   how you want to be credited.
49 - At the agreed time, publish the OpenBMC security advisory, reveal the fix,
50   and publish the CVE.
51
52Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
53(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
54
55Alternatives to this process:
56 - If the problem is not severe, please write an issue to the affected
57   repository or email the list.
58 - Join the OpenBMC community and fix the problem yourself.
59 - If you are unsure if the error is in OpenBMC (contrasted with
60   upstream projects such as the Linux kernel or downstream projects
61   such as a customized version of OpenBMC), please report it and we
62   will help you route it to the correct area.
63 - Discuss your topic in other [OpenBMC communication channels](https://github.com/openbmc/openbmc).
64
65[security response team guidelines]: ./obmc-security-response-team-guidelines.md
66[CVSS metrics]: https://www.first.org/cvss/calculator/3.0
67[CVE]: http://cve.mitre.org/about/index.html
68[CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
69[GitHub security advisory]: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
70[CVE Numbering Authority (CNA)]: https://www.cve.org/ProgramOrganization/CNAs
71