Security Reporting Policy for Open Source Projects (SECURITY.md)
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
Standardize the security reporting process in open source projects as there is no current standard process to privately disclose potential security vulnerabilities to project maintainers. Additionally, most open source projects do not provide information on how to disclose potential security vulnerabilities.
Intended users
Security Analyst, Project Maintainer
Further details
Similar process has been added by GitHub, details can be found here: https://help.github.com/en/articles/adding-a-security-policy-to-your-repository and a feature ticket opened with BitBucket found here: https://bitbucket.org/site/master/issues/18969/security-reporting-policy-for-open-source
IEEE Spectrum article on the subject here: https://spectrum.ieee.org/tech-talk/computing/software/github-releases-new-tools-to-report-vulnerabilities.
Link to paper is here: https://link.springer.com/chapter/10.1007/978-3-030-20883-7_2 Preprint of the paper can be found here: https://blcarlson01.github.io/assets/papers/CarlsonETAL19VulnerabilityNotification.pdf
Proposal
Given the lack of security reporting policies among open source projects, we recommend the creation of a SECURITY.md file, either during the creation of the repository or made available to easily add to an existing repository. This file would contain, at a minimum, contact information and the disclosure policy of an open source project. The creation of a SECURITY.md file would provide a solution to the open source community that is currently lacking a standard security reporting process. The overall goal is to increase communication between the maintainer and individuals/security researchers to properly disclose potential security vulnerabilities in open source projects.
Permissions and Security
The permissions and security required are consistent with the existing permissions as documented for users, groups, and projects.
Documentation
See further details section.
Testing
The primary testing would be internal to GitLab to include the Security.md as part of either the repo creation process or similar workflow process for existing repos.
What does success look like, and how can we measure that?
Success would be the adoption by the open source community of the Security.md to outline each project's security policy when it comes to reporting potential security vulnerabilities. This adoption will likely be slow, but build over time. The adoption of this file will increase the communication between the project maintainer and security researcher in disclosing potential security vulnerabilities in a private and secure manner.
Links / references
Research Paper: https://link.springer.com/chapter/10.1007/978-3-030-20883-7_2
Preprint of research paper: https://blcarlson01.github.io/assets/papers/CarlsonETAL19VulnerabilityNotification.pdf
IEEE Spectrum Article: https://spectrum.ieee.org/tech-talk/computing/software/github-releases-new-tools-to-report-vulnerabilities
GitHub variation: https://help.github.com/en/articles/adding-a-security-policy-to-your-repository
BitBucket feature request: https://bitbucket.org/site/master/issues/18969/security-reporting-policy-for-open-source