github.com/yogeshkumararora/slsa-github-generator@v1.10.1-0.20240520161934-11278bd5afb4/SECURITY.md (about) 1 # Security Policy 2 3 This document includes information about the vulnerability reporting, patch, 4 release, and disclosure processes, as well as general security posture. 5 6 <!-- markdown-toc --bullets="-" -i SECURITY.md --> 7 8 <!-- toc --> 9 10 - [Supported Versions](#supported-versions) 11 - [Reporting a Vulnerability](#reporting-a-vulnerability) 12 - [When Should I Report a Vulnerability?](#when-should-i-report-a-vulnerability) 13 - [When Should I NOT Report a Vulnerability?](#when-should-i-not-report-a-vulnerability) 14 - [Vulnerability Response](#vulnerability-response) 15 - [Security Release & Disclosure Process](#security-release--disclosure-process) 16 - [Private Disclosure](#private-disclosure) 17 - [Public Disclosure](#public-disclosure) 18 - [Security Releases](#security-releases) 19 - [Severity](#severity) 20 - [Security Posture](#security-posture) 21 - [Security Team](#security-team) 22 - [Security Policy Updates](#security-policy-updates) 23 24 <!-- tocstop --> 25 26 ## Supported Versions 27 28 The following versions are currently supported and receive security updates. 29 Release candidates will not receive security updates. 30 31 | Version | Supported | 32 | --------- | ------------------ | 33 | >= 2.0.x | :white_check_mark: | 34 | >= 1.10.x | :white_check_mark: | 35 | <=1.9.x | :x: | 36 37 ## Reporting a Vulnerability 38 39 We're extremely grateful for security researchers and users that report 40 vulnerabilities to us. All reports are thoroughly investigated by the project 41 [security team](#security-team). 42 43 Vulnerabilities are reported privately via GitHub's 44 [Security Advisories](https://docs.github.com/en/code-security/security-advisories) 45 feature. Please use the following link to submit your vulnerability: 46 [Report a vulnerability](https://github.com/yogeshkumararora/slsa-github-generator/security/advisories/new) 47 48 Please see 49 [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability) 50 for more information on how to submit a vulnerability using GitHub's interface. 51 52 ### When Should I Report a Vulnerability? 53 54 - You think you discovered a potential security vulnerability in slsa-github-generator 55 - You are unsure how a vulnerability affects slsa-github-generator 56 - You think you discovered a vulnerability in another project that slsa-github-generator depends on 57 - For projects with their own vulnerability reporting and disclosure process, please report it directly there 58 59 ### When Should I NOT Report a Vulnerability? 60 61 - You need help tuning GitHub Actions for security 62 - You need help applying security related updates 63 - Your issue is not security related 64 65 ### Vulnerability Response 66 67 Each report is acknowledged and analyzed by the [Security Team](#security-team) 68 within 14 days. This will set off the 69 [Security Release Process](#security-release--disclosure-process). 70 71 Any vulnerability information shared with the Security Team stays within 72 slsa-github-generator project and will not be disseminated to other projects 73 unless it is necessary to get the issue fixed. 74 75 As the security issue moves from triage, to identified fix, to release planning 76 we will keep the reporter updated. 77 78 ## Security Release & Disclosure Process 79 80 Security vulnerabilities should be handled quickly and sometimes privately. The 81 primary goal of this process is to reduce the total time users are vulnerable 82 to publicly known exploits. 83 84 ### Private Disclosure 85 86 We ask that all suspected vulnerabilities be privately and responsibly 87 disclosed via the [private disclosure process](#reporting-a-vulnerability) 88 outlined above. 89 90 Fixes may be developed and tested by the [Security Team](#security-team) in a 91 [temporary private fork](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) 92 that are private from the general public if deemed necessary. 93 94 ### Public Disclosure 95 96 Vulnerabilities are disclosed publicly as GitHub [Security 97 Advisories](https://github.com/yogeshkumararora/slsa-github-generator/security/advisories). 98 99 A public disclosure date is negotiated by the [Security Team](#security-team) 100 and the bug submitter. We prefer to fully disclose the bug as soon as possible 101 once a user mitigation is available. It is reasonable to delay disclosure when 102 the bug or the fix is not yet fully understood, the solution is not 103 well-tested, or for vendor coordination. The timeframe for disclosure is from 104 immediate (especially if it's already publicly known) to several weeks. For a 105 vulnerability with a straightforward mitigation, we expect report date to 106 disclosure date to be on the order of 14 days. 107 108 If you know of a publicly disclosed security vulnerability please IMMEDIATELY 109 [report the vulnerability](#reporting-a-vulnerability) to inform the 110 [Security Team](#security-team) about the vulnerability so they may start the 111 patch, release, and communication process. 112 113 If possible the Security Team will ask the person making the public report if 114 the issue can be handled via a private disclosure process. If the reporter 115 denies the request, the Security Team will move swiftly with the fix and 116 release process. In extreme cases you can ask GitHub to delete the issue but 117 this generally isn't necessary and is unlikely to make a public disclosure less 118 damaging. 119 120 ### Security Releases 121 122 Once a fix is available it will be released and announced via the project on 123 GitHub and in the [OpenSSF #slsa-tooling slack 124 channel](https://slack.com/app_redirect?team=T019QHUBYQ3&channel=slsa-tooling). 125 Security releases will announced and clearly marked as a security release and 126 include information on which vulnerabilities were fixed. As much as possible 127 this announcement should be actionable, and include any mitigating steps users 128 can take prior to upgrading to a fixed version. 129 130 Fixes will be applied in patch releases to all [supported 131 versions](#supported-versions) and all fixed vulnerabilities will be noted in 132 the [CHANGELOG](./CHANGELOG.md). 133 134 ### Severity 135 136 The [Security Team](#security-team) evaluates vulnerability severity on a 137 case-by-case basis, guided by [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document). 138 139 ## Security Posture 140 141 We aim to reduce the number of security issues through several general 142 security-concious development practices including the use of unit-tests, 143 end-to-end (e2e) tests, static and dynamic analysis tools, and use of 144 memory-safe languages. 145 146 We aim to fix issues discovered by analysis tools as quickly as possible. We 147 prefer to add these tools to "pre-submit" checks on PRs so that issues are 148 never added to the code in the first place. 149 150 In general, we observe the following security-conscious practices during 151 development (This is not an exhaustive list). 152 153 - All PRs are reviewed by at least one [CODEOWNER](./CODEOWNERS). 154 - All unit and linter pre-submit tests must pass before a PRs is merged. See 155 the [Pre-submits and Unit Tests](./CONTRIBUTING.md#pre-submits-and-unit-tests) 156 section of the Contributor Guide for more information. 157 - All releases include no known e2e test failures. See 158 [RELEASE.md](./RELEASE.md) for info on the release process. See the 159 [End to End (e2e) Tests](./CONTRIBUTING.md#end-to-end-e2e-tests) section of 160 the Contributor Guide for more information on e2e tests. 161 - We refrain from using memory-unsafe languages (e.g. C, C++) or memory-unsafe 162 use of languages that are memory-safe by default (e.g. the Go 163 [unsafe](https://pkg.go.dev/unsafe) package). 164 165 ## Security Team 166 167 The Security Team is responsible for the overall security of the 168 project and for reviewing reported vulnerabilities. Each member is familiar 169 with designing secure software, security issues related to CI/CD, GitHub 170 Actions and build provenance. 171 172 <!-- NOTE: Team membership should be synced with CODEOWNERS for SECURITY.md --> 173 174 Security Team: 175 176 - Kris Kooi (@kpk47) 177 - Joshua Locke (@joshuagl) 178 - Laurent Simon (@laurentsimon) 179 180 Security Team membership is currently considered on a case-by-case basis. 181 182 ## Security Policy Updates 183 184 Changes to this Security Policy are reviewed and approved by the 185 [Security Team](#security-team).