diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..384f55b5 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,122 @@ +# TAC Security Policy + +## About this Document +This document document defines how security vulnerability reporting is handled +in this project. The approach aligns with the [OpenWallet Foundation's security +vulnerability disclosure policy]. Please review that document to understand +the basis of the security reporting for this project + +This policy borrows heavily from the recommendations of the OpenSSF +Vulnerability Disclosure working group. For up-to-date information on the latest +recommendations related to vulnerability disclosures, please visit the [GitHub +of that working group](https://github.com/ossf/wg-vulnerability-disclosures). + +If you are already familiar with what a security vulnerability disclosure policy +is and are ready to report a vulnerability, please jump to [Report +Intakes](#report-intakes). + +[OpenWallet Foundation's security vulnerability disclosure policy]: https://tac.openwallet.foundation/governance/security/ + +## What Is a Vulnerability Disclosure Policy? + +No piece of software is perfect. All software (at least, all software of a +certain size and complexity) has bugs. In open source development, members of +the community or the public find bugs and report them to the project. A +vulnerability disclosure policy explains how this process functions from the +perspective of the project. + +This vulnerability disclosure policy explains the rules and guidelines for +this project. It is intended to act as both a reference for +outsiders–including both bug reporters and those looking for information on the +project’s security practices–as well as a set of rules that maintainers and +contributors have agreed to follow. + +## Report Intakes + +This project uses the following mechanism to submit security +vulnerabilities. While the security team members will do their best to +respond to bugs disclosed in all possible ways, it is encouraged for bug +finders to report through the following approved channel: + +- Open a [GitHub security vulnerability report]: Open a draft security advisory +on the "Security" tab of this GitHub repository. See [GitHub Security Advisories](#github-security-advisories) to learn more about the security infrastructure in GitHub. + +[GitHub security vulnerability report]: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability + +## Security Team + +The current security team is: + +| Name | Email ID | Chat ID | Area/Specialty | +| ---------------- | ------------------ | -------------- | --------------- | +| <> | <> | <> | <> | +| <> | <> | <> | <> | +| <> | <> | <> | <> | + +The security team for this project must include at least three project +Maintainers that agree to carry out the following duties and responsibilities. +Members are added and removed from the team via approved Pull Requests to this +repository. For additional background into the role of the security team, see +the [People Infrastructure] section of the [OpenWallet Foundation's security vulnerability disclosure policy]. + +[People Infrastructure]: https://tac.openwallet.foundation/governance/security#people-infrastructure + +**Responsibilities**: + +1. Acknowledge receipt of the issue (see [Report Intakes](#report-intakes)) to the reporter within 2 business days. + +2. Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs. + +3. Some issues may require more time and resources to correct. If a +particular report is more complex, discuss an embargo period with the reporter. +The embargo period should be negotiated with the reporter and must not be +longer than 90 days. + +4. Create a patch for the issue (see [Private Patch Deployment +Infrastructure](#private-patch-deployment-infrastructure)). + +5. Request a CVE for the issue (see [CNA/CVE Reporting](#cnacve-reporting)). + +6. Decide the date of public release. + +7. If applicable, notify members of the embargo list of the upcoming patch +and release, as described above. + +8. Cut a new (software) release in which the bug is fixed. + +9. Publicly disclose the issue within 48 hours after the release (see [GitHub Security Advisories](#github-security-advisories)). + +## Discussion Forum + +Discussions about each reported vulnerability are carried out in the +private GitHub security advisory about the vulnerability. +If necessary, a private channel specific to the issue may be created on the +OpenWallet Foundation's Discord server with invited participants added to the +discussion. + +## CNA/CVE Reporting + +This project maintains a list of **Common Vulnerabilities and Exposures +(CVE)** and uses GitHub as its **CVE numbering authority (CNA)** for issuing +CVEs. + +## Embargo List + +This project maintains a private embargo list. If you wish to be added to +the embargo list for a project, please email the [OpenWallet Foundation's +security list], including the project name and reason for being added to the +embargo list. Requests will be assessed by the security team in conjunction +with the appropriate OpenWallet Foundation staff, and a decision will be made +whether to accommodate the request. + +## GitHub Security Advisories + +This project uses [GitHub security advisories and the GitHub security process](https://docs.github.com/en/code-security/security-advisories) for handling security vulnerabilities. + +## Private Patch Deployment Infrastructure + +In creating patches and new releases that address security vulnerabilities, +this project uses the private development features of GitHub for security +vulnerabilities. GitHub has [extensive +documentation](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories) +about these features. \ No newline at end of file