From 60f9fddf95ee137785eaea64446212105ec6aefa Mon Sep 17 00:00:00 2001 From: Ian Lewis Date: Wed, 15 Feb 2023 09:08:34 +0900 Subject: [PATCH] docs: Add security policy. (#1262) Signed-off-by: Ian Lewis Co-authored-by: Joshua Lock --- CODEOWNERS | 1 + CONTRIBUTING.md | 80 +++++++++++++-------- SECURITY.md | 183 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 235 insertions(+), 29 deletions(-) create mode 100644 SECURITY.md diff --git a/CODEOWNERS b/CODEOWNERS index c6b5702d10..c21c97cc5b 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -1 +1,2 @@ * @asraa @ianlewis @laurentsimon @joshuagl @naveensrinivasan +SECURITY.md @asraa @ianlewis @laurentsimon @joshuagl diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 570d165fd5..a2233cac43 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,20 +1,4 @@ -# CONTRIBUTING - -- [Contributor Guide](#contributor-guide) - - [Prerequisites](#prerequisites) - - [Create a GitHub account](#create-a-github-account) - - [Code of Conduct](#code-of-conduct) - - [Setting up your development environment](#setting-up-your-development-environment) - - [Development](#development) - - [Testing](#testing) - - [Pre-submits and Unit Tests](#pre-submits-and-unit-tests) - - [End to End (e2e) Tests](#end-to-end-e2e-tests) - - [Linters](#linters) - - [Releasing](#releasing) - - [Community](#community) - - [Communication](#communication) - -## Contributor Guide +# Contributor Guide This guide will help you understand the overall organization of the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) @@ -26,20 +10,40 @@ This document is the single source of truth for how to contribute to the code base. Feel free to browse the [open issues](https://github.com/slsa-framework/slsa-github-generator/issues) and file new ones, all feedback is welcome! -### Prerequisites + + + + +- [Prerequisites](#prerequisites) + - [Create a GitHub account](#create-a-github-account) + - [Code of Conduct](#code-of-conduct) + - [Setting up your development environment](#setting-up-your-development-environment) +- [Development](#development) + - [Preferred Languages](#preferred-languages) +- [Testing](#testing) + - [Pre-submits and Unit Tests](#pre-submits-and-unit-tests) + - [End-to-End (e2e) Tests](#end-to-end-e2e-tests) + - [Linters](#linters) +- [Releasing](#releasing) +- [Community](#community) +- [Communication](#communication) + + + +## Prerequisites Before submitting code, you should first complete the following prerequisites. -#### Create a GitHub account +### Create a GitHub account Before you get started, you will need to [signup](http://github.com/signup) for a GitHub user account. -#### Code of Conduct +### Code of Conduct Please make sure to read and observe the [Code of Conduct]. -#### Setting up your development environment +### Setting up your development environment It is not required to set up a developer environment in order to contribute to slsa-github-generator but it may be required for code changes. @@ -66,7 +70,7 @@ install them on your development machine. - [eslint](https://eslint.org/) (NOTE: eslint is installed automatically so you don't need to install it) -### Development +## Development Since this project includes reusable workflows for use on GitHub Actions local development is limited to building and testing the binaries used by the reusable @@ -89,13 +93,31 @@ Some example test repos: - [actions-test](https://github.com/ianlewis/actions-test/tree/main/.github/workflows) - [slsa-on-github-test](https://github.com/laurentsimon/slsa-on-github-test/tree/main/.github/workflows) -### Testing +### Preferred Languages + +We prefer the use of the following programming languages: + +- [Go](https://go.dev/) - For builders/generators. +- [TypeScript](https://www.typescriptlang.org/) - For GitHub actions. +- [Bash](https://www.gnu.org/software/bash/) - For scripts in GitHub actions and workflows. + +We do not have a strict rule that proscribes the use of a specific language. +However, any PRs that introduce a new language should include justification for +adding the new language as well as a plan for adding the necessary tooling and +testing infrastructure. + +We will generally reject PRs that introduce the use of memory-unsafe +languages or use of existing languages in memory-unsafe ways (e.g. the Go +[unsafe](https://pkg.go.dev/unsafe) package). See the +[Security Policy](./SECURITY.md) for more info. + +## Testing A number of automated tests and linters are used to maintain stability and good code quality. New PRs that include new functionality should include automated tests for that functionality. -#### Pre-submits and Unit Tests +### Pre-submits and Unit Tests Pre-submits run on each Pull Request and will block it from being merged if they fail. These tests are located in the [.github/workflows](.github/workflows) @@ -112,10 +134,10 @@ make unit-test Tests for GitHub Actions created with Typescript require [Jest](https://jestjs.io). ``` -make ts-test +make ts-test ``` -#### End-to-End (e2e) Tests +### End-to-End (e2e) Tests This project has a number of End-to-End tests that are scheduled to run daily. These tests are located in the @@ -125,7 +147,7 @@ testing [README.md](https://github.com/slsa-framework/example-package/blob/main/.github/workflows/README.md) for more information about e2e tests. -#### Linters +### Linters You can run all linters using `make`. @@ -136,7 +158,7 @@ make lint These linters will also run as GitHub checks for pull requests via [pre-submit.lint.yml](.github/workflows/pre-submit.lint.yml) file. -### Releasing +## Releasing Please see [RELEASE.md](RELEASE.md). @@ -145,7 +167,7 @@ Please see [RELEASE.md](RELEASE.md). This project is part of the [SLSA Community](https://slsa.dev/community) working with the SLSA Tooling SIG. -### Communication +## Communication The [`#slsa-tooling`](https://slack.com/app_redirect?team=T019QHUBYQ3&channel=slsa-tooling) channel in the [OpenSSF Slack](https://slack.openssf.org/) is used for diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..d8f3cc3490 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,183 @@ +# Security Policy + +This document includes information about the vulnerability reporting, patch, +release, and disclosure processes, as well as general security posture. + + + + + +- [Supported Versions](#supported-versions) +- [Reporting a Vulnerability](#reporting-a-vulnerability) + - [When Should I Report a Vulnerability?](#when-should-i-report-a-vulnerability) + - [When Should I NOT Report a Vulnerability?](#when-should-i-not-report-a-vulnerability) + - [Vulnerability Response](#vulnerability-response) +- [Security Release & Disclosure Process](#security-release--disclosure-process) + - [Private Disclosure](#private-disclosure) + - [Public Disclosure](#public-disclosure) + - [Security Releases](#security-releases) + - [Severity](#severity) +- [Security Posture](#security-posture) +- [Security Team](#security-team) +- [Security Policy Updates](#security-policy-updates) + + + +## Supported Versions + +The following versions are currently supported and receive security updates. + +| Version | Supported | +| ------- | ------------------ | +| 1.4.x | :white_check_mark: | +| <=1.2.x | :x: | + +## Reporting a Vulnerability + +We're extremely grateful for security researchers and users that report +vulnerabilities to us. All reports are thoroughly investigated by the project +[security team](#security-team). + +Vulnerabilities are reported privately via GitHub's +[Security Advisories](https://docs.github.com/en/code-security/security-advisories) +feature. Please use the following link to submit your vulnerability: +[Report a vulnerability](https://github.com/slsa-framework/slsa-github-generator/security/advisories/new) + +Please see +[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) +for more information on how to submit a vulnerability using GitHub's interface. + +### When Should I Report a Vulnerability? + +- You think you discovered a potential security vulnerability in slsa-github-generator +- You are unsure how a vulnerability affects slsa-github-generator +- You think you discovered a vulnerability in another project that slsa-github-generator depends on + - For projects with their own vulnerability reporting and disclosure process, please report it directly there + +### When Should I NOT Report a Vulnerability? + +- You need help tuning GitHub Actions for security +- You need help applying security related updates +- Your issue is not security related + +### Vulnerability Response + +Each report is acknowledged and analyzed by the [Security Team](#security-team) +within 14 days. This will set off the +[Security Release Process](#security-release--disclosure-process). + +Any vulnerability information shared with the Security Team stays within +slsa-github-generator project and will not be disseminated to other projects +unless it is necessary to get the issue fixed. + +As the security issue moves from triage, to identified fix, to release planning +we will keep the reporter updated. + +## Security Release & Disclosure Process + +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 known exploits. + +### Private Disclosure + +We ask that all suspected vulnerabilities be privately and responsibly +disclosed via the [private disclosure process](#reporting-a-vulnerability) +outlined above. + +Fixes may be developed and tested by the [Security Team](#security-team) in a +[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) +that are private from the general public if deemed necessary. + +### Public Disclosure + +Vulnerabilities are disclosed publicly as GitHub +[Security Advisories](https://github.com/slsa-framework/slsa-github-generator/security/advisories). + +A public disclosure date is negotiated by the [Security Team](#security-team) +and the bug submitter. We prefer to fully disclose the bug as soon as possible +once a user mitigation is available. It is reasonable to delay disclosure when +the bug or the fix is not yet fully understood, the solution is not +well-tested, or for vendor coordination. The timeframe for disclosure is from +immediate (especially if it's already publicly known) to several weeks. For a +vulnerability with a straightforward mitigation, we expect report date to +disclosure date to be on the order of 14 days. + +If you know of a publicly disclosed security vulnerability please IMMEDIATELY +[report the vulnerability](#reporting-a-vulnerability) to inform the +[Security Team](#security-team) about the vulnerability so they may start the +patch, release, and communication process. + +If possible the Security Team will ask the person making the public report if +the issue can be handled via a private disclosure process. If the reporter +denies the request, the Security Team will move swiftly with the fix and +release process. In extreme cases you can ask GitHub to delete the issue but +this generally isn't necessary and is unlikely to make a public disclosure less +damaging. + +### Security Releases + +Once a fix is available it will be released and announced via the project on +GitHub and in the [OpenSSF #slsa-tooling slack +channel](https://slack.com/app_redirect?team=T019QHUBYQ3&channel=slsa-tooling). +Security releases will announced and clearly marked as a security release and +include information on which vulnerabilities were fixed. As much as possible +this announcement should be actionable, and include any mitigating steps users +can take prior to upgrading to a fixed version. + +Fixes will be applied in patch releases to all [supported +versions](#supported-versions). + +### Severity + +The [Security Team](#security-team) evaluates vulnerability severity on a +case-by-case basis, guided by [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document). + +## Security Posture + +We aim to reduce the number of security issues through several general +security-concious development practices including the use of unit-tests, +end-to-end (e2e) tests, static and dynamic analysis tools, and use of +memory-safe languages. + +We aim to fix issues discovered by analysis tools as quickly as possible. We +prefer to add these tools to "pre-submit" checks on PRs so that issues are +never added to the code in the first place. + +In general, we observe the following security-conscious practices during +development (This is not an exhaustive list). + +- All PRs are reviewed by at least one [CODEOWNER](./CODEOWNERS). +- All unit and linter pre-submit tests must pass before a PRs is merged. See + the [Pre-submits and Unit Tests](./CONTRIBUTING.md#pre-submits-and-unit-tests) + section of the Contributor Guide for more information. +- All releases include no known e2e test failures. See + [RELEASE.md](./RELEASE.md) for info on the release process. See the + [End to End (e2e) Tests](./CONTRIBUTING.md#end-to-end-e2e-tests) section of + the Contributor Guide for more information on e2e tests. +- We refrain from using memory-unsafe languages (e.g. C, C++) or memory-unsafe + use of languages that are memory-safe by default (e.g. the Go + [unsafe](https://pkg.go.dev/unsafe) package). + +## Security Team + +The Security Team is responsible for the overall security of the +project and for reviewing reported vulnerabilities. Each member is familiar +with designing secure software, security issues related to CI/CD, GitHub +Actions and build provenance. + + + +Security Team: + +- Asraa Ali (@asraa) +- Ian Lewis (@ianlewis) +- Joshua Locke (@joshuagl) +- Laurent Simon (@laurentsimon) + +Security Team membership is currently considered on a case-by-case basis. + +## Security Policy Updates + +Changes to this Security Policy are reviewed and approved by the +[Security Team](#security-team).