If you have a potential security vulnerability, disclosing it publicly without review could pose a potential risk to systems and people through compromised hardware or software. The OpenBMC security response process exists for private discussion of fixes for a time before public disclosure.

Issues that are discovered with AI-assistance, do not present a security issue on a real system, or cannot be reproduced, but otherwise might be an improvement to the code, MUST NOT be reported through the processes below. Instead, please submit fixes directly to the affected repository under the usual contribution processes.

Join the OpenBMC community on one of the existing OpenBMC communication channels.

openbmc-security@lists.ozlabs.org is no-longer the first point-of-contact for reporting security issues to the project. However, under circumstances outlined below, it may be used to contact the project security team directly.

Any discussion sent to the list must, unless explicitly requested otherwise:

1. Be plain-text email
2. Not contain binary attachments

Software vulnerability reports must identify:

1. The affected component and its source repository

2. The security issue in question, including a basic justification of why this is a security issue.

3. The specific platform the vulnerability is demonstrated on.

4. To your best effort, the earliest commits integrating the affected component into the OpenBMC distribution

5. A script or example of how to reproduce the bug. Please ensure that this example runs against a BMC.

6. Quotes from any relevant specifications governing this vulnerability.

7. A proposed patch to solve the issue.

8. Your legal name so if this is disclosed, we can credit the author.

Please ensure prior to submission that your issue reproduces on the target platform from a commit on the openbmc/master branch less than a week prior to submission. If you've found multiple vulnerabilities, please create one report per vulnerability.

The details of the vulnerability must be provided by opening a draft security advisory against the GitHub source repository of the affected component.

• "CVE identifier" must be set to "Request CVE ID later"

• "Description" must contain a complete discussion of the issue, covering details 2-7 above.

• "Weaknesses" should list CWEs considered relevant

• "Credits" should contain your legal name for credit

The details of the vulnerability must be disclosed in the "Description" field of the report, and pertain only to the issue found. Reports must not be provided in binary attachments, such as PDFs, compressed archives, etc. Such attachments will be disregarded.

If a repository has only one maintainer then they take the role of "issue lead". Otherwise, an issue "issue lead" may be selected by discussion among maintainers of the affected repository in the event that the repository has more than one maintainer.

The responsibilities of an issue lead are:

• Make a preliminary analysis of the security issue.

• Propose a patch to fix the issue.

• If appropriate, request a CVE number from the GHSA team

Please refer to the CERT Guide to Coordinated Vulnerability Disclosure, (SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.

The issue lead for a given vulnerability may choose to coordinate with other maintainers across the project through discussion on the OpenBMC security mailing list.

If you feel your report is not being actioned in a fair or reasonable manner, you may write to openbmc-security@lists.ozlabs.org to escalate your case. Your email must:

1. Contain the link to the draft security advisory in question
2. Discuss the circumstances that caused you to escalate the concern

Resolution will proceed in accordance with decisions made among the OpenBMC security team.

Concerns of hardware vulnerabilities should be reported directly to the OpenBMC security mailing list at openbmc-security@lists.ozlabs.org. The report should include:

1. The affected hardware component
2. Its relationship to OpenBMC
3. Discussion of reporting to relevant hardware vendors

Discussion among the OpenBMC security team may lead to software mitigations being applied on a case-by-case basis.