Sigstore is a growing community of volunteers, users, and vendors. The Sigstore community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues.
Reporting a vulnerabilitySend the vulnerability disclosure to security@sigstore.dev. The Security Response Committee will acknowledge the report within 24 hours.
Include steps to reproduce the vulnerability, the vulnerable versions, and any additional files to reproduce the vulnerability.
If you are only comfortable sharing under GPG, please start by sending an email requesting a public PGP key to use for encryption.
Security Response Committee (SRC)Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly and privately known exploits.
The SRC are responsible for organizing the entire response including internal communication and external disclosure, but will need help from relevant maintainers to successfully run this process.
The SRC currently consists of:
The SRC members will share various tasks as listed below:
Contact the team by sending email to security@sigstore.dev.
Security Response Committee MembershipThe SRC should ideally consist of 3-5 members. New potential members to the SRC can express their interest to the SRC members. These individuals can be nominated by SRC members or Sigstore maintainers to the current SRC members. Membership if possible should be vendor diverse (no more than 2:1 ratio of representation from any single vendor).
If representation changes due to employment change, then SRC members are encouraged to grow the team or replace themselves through mentoring new members.
Security Response Committee Lazy Consensus SelectionSelection of new members will be done by lazy consensus amongst members for adding new people with fallback on majority vote.
Members may step down at any time and propose a replacement from existing active contributors of Sigstore.
Thank you to the previous members of the SRC!
The Sigstore community asks that all suspected vulnerabilities be handled in accordance with Responsible Disclosure model.
Public Disclosure ProcessesIf anyone knows of a publicly disclosed security vulnerability please IMMEDIATELY email security@sigstore.dev to inform the SRC about the vulnerability so they may start the patch, release, and communication process.
If a reporter contacts the SRC to express intent to make an issue public before a fix is available, the SRC will request if the issue can be handled via a private disclosure process. If the reporter denies the request, the SRC will move swiftly with the fix and release process.
Patch, Release, and Public CommunicationFor each vulnerability, the SRC members will coordinate to create the fix and release, and notify the rest of the community.
All of the timelines below are suggestions and assume a Private Disclosure.
These steps should be completed within the first 24 hours of Disclosure.
These steps should be completed within the 1-7 days of Disclosure.
If the CVSS score is under ~4.0 (a low severity score) or the assessed risk is low the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc.
Note: CVSS is convenient but imperfect. Ultimately, the SRC has discretion on classifying the severity of a vulnerability.
The severity of the bug and related handling decisions must be discussed on in the security advisory, never in public repos.
With the Fix Development underway, the SRC needs to come up with an overall communication plan for the wider community. This Disclosure process should begin after the Fix Team has developed a Fix or mitigation so that a realistic timeline can be communicated to users.
Fix Release Day (Completed within 1-21 days of Disclosure)
Subject: Security release of sigstore/<project/ $VERSION is now available
To: sigstore-dev@googlegroups.com
Hello sigstore Community,
The Security Response Committee and maintainers of sigstore/$PROJECT would like
to announce the availability of sigstore/$PROJECT $VERSION.
This addresses the following CVE(s):
* CVE-YEAR-ABCDEF (CVSS score $CVSS): $CVESUMMARY
...
Upgrading to $VERSION is encouraged to fix these issues.
**Am I vulnerable?**
Run `$PROJECT --version` and if it indicates a base version of $OLDVERSION or
older that means it is a vulnerable version.
<!-- Provide details on features, extensions, configuration that make it likely that a system is
vulnerable in practice. -->
**How do I mitigate the vulnerability?**
<!--
[This is an optional section. Remove if there are no mitigations.]
-->
**How do I upgrade?**
<!--
[Outline upgrade steps]
-->
**Vulnerability Details**
<!--
[For each CVE]
-->
These steps should be completed 1-3 days after the Release Date. The retrospective process should be blameless.
Parts of this process were inspired by the etc-d's security handling process.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4