-
Notifications
You must be signed in to change notification settings - Fork 508
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
📖 Update security policy to be specific to OpenSSF Scorecard (#4212)
* SECURITY: Revert to default OpenSSF security policy * SECURITY: Update policy to better describe disclosure and remediation * SECURITY: Reference LF policy and add fallback security contact * Apply suggestions from code review --------- Signed-off-by: Stephen Augustus <[email protected]> Signed-off-by: Stephen Augustus <[email protected]> Co-authored-by: Spencer Schrock <[email protected]>
- Loading branch information
1 parent
4895019
commit 3f38548
Showing
1 changed file
with
58 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,60 @@ | ||
# Reporting Security Issues | ||
# OpenSSF Scorecard Security Policy | ||
|
||
To report a security issue, please email | ||
[[email protected]](mailto:[email protected]) | ||
with a description of the issue, the steps you took to create the issue, | ||
affected versions, and, if known, mitigations for the issue. | ||
This document outlines security procedures and general policies for the | ||
OpenSSF Scorecard project. | ||
|
||
Our vulnerability management team will respond within 3 working days of your | ||
email. If the issue is confirmed as a vulnerability, we will open a | ||
Security Advisory and acknowledge your contributions as part of it. This project | ||
follows a 90 day disclosure timeline. | ||
This policy adheres to the [vulnerability management guidance](https://www.linuxfoundation.org/security) | ||
for Linux Foundation projects. | ||
|
||
- [Disclosing a security issue](#disclosing-a-security-issue) | ||
- [Vulnerability management](#vulnerability-management) | ||
- [Suggesting changes](#suggesting-changes) | ||
|
||
## Disclosing a security issue | ||
|
||
The OpenSSF Scorecard maintainers take all security issues in the project | ||
seriously. Thank you for improving the security of OpenSSF Scorecard. We | ||
appreciate your dedication to responsible disclosure and will make every effort | ||
to acknowledge your contributions. | ||
|
||
OpenSSF Scorecard leverages GitHub's private vulnerability reporting. | ||
|
||
To learn more about this feature and how to submit a vulnerability report, | ||
review [GitHub's documentation on private reporting](https://docs.github.com/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). | ||
|
||
Here are some helpful details to include in your report: | ||
|
||
- a detailed description of the issue | ||
- the steps required to reproduce the issue | ||
- versions of the project that may be affected by the issue | ||
- if known, any mitigations for the issue | ||
|
||
A maintainer will acknowledge the report within 72 hours, and will send a more | ||
detailed response within an additional 72 hours indicating the next steps in | ||
handling your report. | ||
|
||
If you've been unable to successfully draft a vulnerability report via GitHub | ||
or have not received a response during the alloted response window, please | ||
reach out via the [OpenSSF security contact email](mailto:[email protected]). | ||
|
||
After the initial reply to your report, the maintainers will endeavor to keep | ||
you informed of the progress towards a fix and full announcement, and may ask | ||
for additional information or guidance. | ||
|
||
## Vulnerability management | ||
|
||
When the maintainers receive a disclosure report, they will assign it to a | ||
primary handler. | ||
|
||
This person will coordinate the fix and release process, which involves the | ||
following steps: | ||
|
||
- confirming the issue | ||
- determining affected versions of the project | ||
- auditing code to find any potential similar problems | ||
- preparing fixes for all releases under maintenance | ||
|
||
## Suggesting changes | ||
|
||
If you have suggestions on how this process could be improved please submit an | ||
issue or pull request. |