diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..4ec9c26 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,217 @@ +# OpenPRoT Project Security Incident Response + +## Security communication + +Security information about each release is included in the release notes of each of the +[OpenPRoT releases](https://github.com/OpenPRoT/releases) on GitHub. + +Vulnerability notifications pre-release or during embargo periods are available to product creators that have registered for vulnerability alerts. Further +details can be found in [Embargo policy](#embargo-policy). + +## Report a vulnerability + +If you believe you have found a security vulnerability in any OpenPRoT repository, please report it to us through coordinated disclosure. If you believe you have found a vulnerability in a OpenPRoT dependency, please report it to us AND the upstream project. + +Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests. + +All reports are thoroughly investigated by the OpenPRoT Technical Committee (TC) members who form the OpenPRoT Project Security Incident Response Team (OpenPRoT +PSIRT) and may get assigned a Common Vulnerabilities and Exposures number (CVE) if appropriate. + +Vulnerabities can be reported by opening an issue on the [OpenPRoT Security](https://github.com/OpenPRoT/openprot/security) page. + +More details of how vulnerabilities are handled can be found in the section +[Security vulnerability response](#security-vulnerability-response). + +### When should I report a vulnerability? + +- You think you discovered a potential security vulnerability in OpenPRoT. +- You are unsure how a vulnerability affects OpenPRoT. +- You think you discovered a vulnerability in another project that OpenPRoT depends upon. + - For projects with their own vulnerability reporting and disclosure process, please report it directly there. + +### When should I *NOT* report a vulnerability? + +- You need help tuning OpenPRoT components for security. + - Instead, file an Issue labeled as "feature request". +- You need help with a previously announced OpenPRoT Security Advisory. + - Instead, file an Issue labeled as "question"". +- Your issue is not security related. Instead, file an issue as appropriate. + +Issues can be filed at the following locations: + +<Indicate where issues can be filed> + +## Security vulnerability response + +Each report is acknowledged by OpenPRoT Project Security Incident Response Team members within 2 working days. If the report is accepted, a CVE score is +entered, and the issue is assigned to <Relevant OpenPRoT Entity> to begin further debug and analysis within 7 calendar days. This will trigger the +[Security incident management process](#security-incident-management-process) outlined below. + +Any vulnerability information shared with the OpenPRoT Technical Committee stays within the OpenPRoT project and will not be disseminated to other projects +unless it is necessary to get the issue fixed. + +As the security issue moves from triage, to identified fix, to release planning, we will keep the reporter updated. + +## Embargo policy + +The information members receive during embargo periods may be received from the OpenPRoT Vulnerability Alerts mailing list: +[tbd](tbd). To sign up, visit +[tbd](tbd). Any +information regarding embargoed vulnerabilities must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within your specific team +except with the list’s explicit approval. This holds true until the public disclosure date/time that was agreed upon by the list. Members of the list and others +may not use the information for anything other than getting the issue fixed for your respective product’s users. + +Before any embargoed information from the list is shared with respective members of your team required to fix said issue, they must agree to the same terms and +only find out information on a need-to-know basis. + +In the unfortunate event that a member shares the information beyond what is allowed by this policy, that member ***must*** urgently inform the OpenPRoT +workgroup at the [tbd](tbd) mailing list of +exactly what information leaked and to whom. A retrospective will take place after the leak so we can assess how to not make the same mistake in the future. + +If the member continues to leak information and break this policy, the member is removed from the list. + +More details of how vulnerabilities are handled can be found in our [Security incident management process](#security-incident-management-process) +section. + +## Product integrator notification process + +Companies or individuals building products that integrate OpenPRoT and are trademark recipients may be eligible to participate in the +[tbd](tbd) mail list and receive +advanced notification of the vulnerabilities and mitigations before public disclosure by applying to participate. For more information, refer to the +[Vulnerability notification process](#vulnerability-notification-process) section of this document. + +Criteria for participation includes: + +1. Complete the *to be defined* OpenPRoT trademark license grant process to be recognized as a product integrator. +1. Register for [OpenPRoT vulnerability alerts](tbd). +1. Have a contact who will respond to emails within a week and understands how OpenPRoT is being used in the product. +1. Have a publicly listed product based on some release of OpenPRoT. +1. Have an actively monitored security email alias. +1. Accept the OpenPRoT Embargo Policy that is outlined above. + +Removal: + +1. If a member stops adhering to these criteria after joining the list, then the member is unsubscribed. + +## Security incident management process + +Issues within this bug tracking system will transition through a number of states according to this diagram: + +
+ +```mermaid +flowchart TB + Triage -->|2 business days| Draft_New + Triage --> Closed_Rejected + Draft_New -->|7 calendar days| Draft_Assigned + Draft_New <--> Closed_Rejected + Draft_Assigned <--> Draft_Review + Draft_Review ---> Closed_Rejected + Draft_Review --> Draft_Accepted + Draft_Accepted -->|90 calendar days
from initial report| Closed_Published +``` + +
+ +- **Triage:** This state represents new reports that have been entered directly by a reporter. The security team will triage these reports and move them to +either *Draft_New* or *Closed_Rejected*. When reports are entered by the security team in response to an email, the issue shall be transitioned directly to +*Draft_New*. + +- **Draft_New:** This issue is awaiting disposition by the security team. The security team will analyze the issue, determine a responsible entity, assign +it to that individual, and move the issue to the *Draft_Assigned* state. Part of triage is to set the issue’s priority. + +- **Draft_Assigned:** The issue was assigned, a CVE score was entered, and the issue is awaiting a fix by the assignee. At this time, collaborators are +designated, and a private fork of the affected repository is created. The original reporter of the vulnerability is included as a collaborator. Only +collaborators are able to view details of the vulnerability and participate in discussions and code reviews until the final security advisory is published +publicly. + +- **Draft_Review:** Once there is a GitHub pull request (PR) for the issue, the PR link is added to a comment in the issue, and the issue moved to the +*Draft_Review* state. + +- **Draft_Accepted:** Indicates that this issue was merged into the appropriate public branch within OpenPRoT. + +- **Closed_Published:** The embargo period has ended. The issue is made publicly visible, the associated CVE is updated, and the security advisories page in the +repository is updated to include the detailed information. + +- **Closed_Rejected:** The OpenPRoT PSIRT has rejected the reported security vulnerability. It may have been deemed a non-issue, or it may have been converted +into a standard GitHub Issue report. The PSIRT may also re-open the issue from here. + +The security advisories created are kept private, due to the sensitive nature of security reports. The issues are only visible to certain parties: + +- Members of the PSIRT mailing list +- The reporter +- Others, as proposed and ratified by the OpenPRoT PSIRT. In the general case, this will include: + - The code owner responsible for the fix. + - The OpenPRoT release owners for the relevant releases affected by this vulnerability. + +The OpenPRoT TC shall review the reported vulnerabilities during any meeting with more than three people in attendance. During this review, they +shall determine if new issues need to be embargoed. + +The guideline for embargo is based on: + +1. Severity of the issue, and +2. Exploitability of the issue. + +Issues that the OpenPRoT TC decides do not need an embargo are reproduced in the regular OpenPRoT project bug tracking system. + +Security sensitive vulnerabilities shall be made public after an embargo period of at most 90 days. The intent is to allow 30 days within the +OpenPRoT project to fix the issues, and 60 days for product creators building products using OpenPRoT to be able to apply and distribute these +fixes. + +Fixes to the code shall be made through PRs in the OpenPRoT project GitHub repositories. Developers must not reveal the sensitive nature of what is being fixed, +and shall not refer to CVE numbers that have been assigned to the issue. The developer instead should describe what was fixed, without revealing how the issue +was discovered or its possible impact. + +The OpenPRoT TC shall maintain information that maps embargoed CVEs to these PRs (this information is within the Github security advisories), and +produce regular reports of the state of security issues. + +Each issue that is considered a security vulnerability shall be assigned a CVE number. As fixes are created, it may be necessary to allocate +additional CVE numbers, or to retire numbers that were assigned. + +## Vulnerability notification process + +Each OpenPRoT release shall contain a report of CVEs that were fixed in that release. Because of the sensitive nature of these vulnerabilities, +the release shall merely include a list of CVEs that have been fixed. After the embargo period, the vulnerabilities page shall be updated to include +additional details of these vulnerabilities. The vulnerability page shall give credit to the reporter(s) unless a reporter specifically requests +anonymity. + +The OpenPRoT project shall maintain a vulnerability-alerts mailing list. This list is seeded initially with a contact from each project member. + +Additional parties can request to join this list by visiting +[tbd](tbd). These parties are vetted by +the OpenPRoT PSIRT to determine that they have a legitimate interest in knowing about security vulnerabilities during the embargo period. + +Periodically, the OpenPRoT PSIRT will send information to this mailing list describing known embargoed issues and their backport status within the +project. This information is intended to allow them to determine if they need to backport these changes to any internal trees. + +When issues have been triaged, this list is informed of: + +- The OpenPRoT Project security advisory link (GitHub). +- The CVE number assigned. +- The subsystem involved. +- The severity of the issue. + +After acceptance of a PR fixing the issue (merged), in addition to the above, the list is informed of: + +- The association between the CVE number and the PR fixing it. +- Backport plans within the OpenPRoT project. + +## Backporting of security vulnerabilities + +Each security issue fixed within OpenPRoT Firmware shall be backported to the following releases: + +- The current Long Term Stable (LTS) release. +- The most recent two releases. + +Backports are tracked in the security advisory and are completed during the 90 day embargo period. + +## Need to know + +Due to the sensitive nature of security vulnerabilities, it is important to share details and fixes only with those parties that have a need to +know. The following parties will need to know details about security vulnerabilities before the embargo period ends: + +- Maintainers will have access to all information within their domain area only. +- The current release manager, and the release manager for historical releases affected by the vulnerability (see backporting above). +- The Project Security Incident Response Team will have full access to information. +- The PSIRT is made up of representatives from OpenPRoT integrators and contributors. +- As needed, release managers and maintainers may be invited to attend additional security meetings to discuss vulnerabilities.