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).