xref: /openbmc/docs/security/how-to-report-a-security-vulnerability.md (revision 85706020)

# How to report a security vulnerability

This describes how you can report an OpenBMC security vulnerability privately to
give the project time to address the problem before public disclosure.

The main ideas are:

- 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: 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.

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][].
- Coordinate workarounds and fixes with you and the community.
- Coordinate announcement details with you, such as timing or how you want to be
  credited.
- 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.

Alternatives to this process:

- If the problem is not severe, please write an issue to the affected repository
  or email the list.
- Join the OpenBMC community and fix the problem yourself.
- If you are unsure if the error is in OpenBMC (contrasted with upstream
  projects such as the Linux kernel or downstream projects such as a customized
  version of OpenBMC), please report it and we will help you route it to the
  correct area.
- Discuss your topic in other
  [OpenBMC communication channels](https://github.com/openbmc/openbmc).

[security response team guidelines]: ./obmc-security-response-team-guidelines.md
[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