77 lines
3.6 KiB
Markdown
77 lines
3.6 KiB
Markdown
# 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
|