From 95bf50cad457b489a1ce2dc06ebd2e5d0a8b5977 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Tue, 4 Jun 2024 17:38:08 -0700 Subject: [PATCH 01/18] feat: Add SPEC 8 - Securing the Release Process * This SPEC draft was written at the 2024 Scientific Python Developer Summit. --- spec-0008/index.md | 227 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 spec-0008/index.md diff --git a/spec-0008/index.md b/spec-0008/index.md new file mode 100644 index 00000000..58bf7e3c --- /dev/null +++ b/spec-0008/index.md @@ -0,0 +1,227 @@ +# SPEC-8: Securing the Release Process + +--- + +title: "SPEC 8 — Securing the Release Process" +number: 8 +date: 2024-06-04 +author: + +- "Matthew Feickert " +- "Pamphile Roy " +- "Juanita Gomez " +- "Seth Larson " +- "Lars Grüter " + discussion: https://discuss.scientific-python.org/t/spec-8-supply-chain-security + endorsed-by: + +--- + +## Description + + + +Securing the Open Source supply chain (OSSC) is becoming a more relevant concern in recent years, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. +The Python Software Foundation (PSF) is also taking the importance of the OSSC seriously, as demonstrated by the [creation of the PSF Security Developer in Residence position in 2023](https://pyfound.blogspot.com/2023/06/announcing-our-new-security-developer.html). + +With the creation of the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being more widely adopted there are now high level developer tools, maintained by professional security teams, that are available with clear recommendations on how to use them. + +This SPEC outlines the requirements for practically adopting these security tools and recommendations with a focus on securely publishing release artifacts. +Securely building release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). + +This SPEC is written with GitHub in mind, note these recommendations still apply with other services such as GitLab and we refer project to these services' documentations and guidelines. + +## Implementation + +With a focus on securing the release artifact distribution process, the following processes and standards should be adopted. + +### Document the release process + +The release process should be clearly and fully documented in the developer documentation and describe each step to make a release and the permissions required to do so. + +### Hardening workflow environment permissions + +Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `on workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). +This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. + +It is also strongly recommended that the repository requires signed commits so that all releases have a verified commit to which they correspond. +The branch from which the release is made should also be protected. + +#### Restrict permissions in CI runners to the minimum required + +To restrict the attack surface area of arbitrary code execution in CI runners, the default permissions the runners have should be restricted to the minimum possible (read access). In the GitHub Action workflow, this is accomplished by defining the following workflow global permissions block before any jobs are defined. + +```yaml +permissions: + content: read +``` + +Elevating permissions beyond this should be done at the job level by redefining the permissions block in the job. + +#### Restrict permitted actions in workflows + +GitHub allows to restrict the actions that workflows can use via repositories settings at `https://github.com/ORG/PROJECT/settings/actions`. +A reasonable default setup is to: + +- allow actions from the repository itself and actions created by GitHub, +- as well as an allow list of actions from third party repositories. + + ``` + OWNER/REPOSITORY@* + ``` + +Consult [Managing GitHub Actions permissions for your repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository) for more details. + +#### Use GitHub Actions environments + +Use a GitHub Actions environment + +```yaml +environment: + name: publish-package +``` + +and enforce additional review by at least one other maintainer to run a GitHub Actions workflow that publishes to PyPI. +Additional reviewer requirements can be configured per GitHub Actions environment under `https://github.com/ORG/PROJECT/settings/environments/` in the "Deployment protection rules" section. + +![github-actions-environment](https://hackmd.io/_uploads/S1SErQ0EC.png) + +### Pin GitHub Actions release workflows to their full release commit SHAs + +GitHub actions must be pinned using full commit SHA corresponding to the release version being used. +Using versions or small hashes is susceptible to attacks. + +```yaml +- uses: actions/some-action@1fe14e04876783b259436247a3898d2fe7d5548f #vX.Y.Z +``` + +Dependabot can be used to automatically update the hashes. +It is important that this happens as part of a reviewed process. + +```yaml! +# .github/dependabot.yml +version: 2 +updates: + # Maintain dependencies for GitHub Actions + - package-ecosystem: "github-actions" + directory: "/" + schedule: + interval: "monthly" + groups: + actions: + patterns: + - "*" +``` + +### Adopt SLSA through use of GitHub Attestations + +A component of SLSA is [software attestation](https://slsa.dev/attestation-model) which allows for public validation of software artifacts and provenance. +GitHub provides the [`actions/attest-build-provenance`](https://github.com/actions/attest-build-provenance) GitHub Action which implements SLSA to generate signed build provenance attestations for workflow artifacts. +Attestations are publishes to the project GitHub under `https://github.com/ORG/PROJECT/attestations/`. + +```yaml +- uses: actions/attest-build-provenance@ # vX.Y.Z + with: + subject-path: "dist/-*" +``` + +GitHub has also added the [`gh attestation verify`](https://cli.github.com/manual/gh_attestation_verify) command to the GitHub CLI utility, which verifies the integrity and provenance of an artifact using its associated cryptographically signed attestations. +This can be used by individual users and also in GitHub Actions workflows where the GitHub CLI utility is installed by default. + +```yaml +- name: Verify sdist artifact attestation + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + run: gh attestation verify dist/-*.tar.gz --repo ${{ github.repository }} + +- name: Verify wheel artifact attestations + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + run: gh attestation verify dist/-*.whl --repo ${{ github.repository }} +``` + +### Adopt OIDC through the use of PyPI Trusted Publishers + +[Trusted Publishers](https://docs.pypi.org/trusted-publishers/) provide a way to securely establish a short lived authentication token between a project repository and a distribution platform — such as PyPI. +It replaces the need to use a long lived token to authenticate, reducing the security risks associated with authentication tokens (e.g., tokens being compromised, the need to rotate tokens). + +Trusted Publishers can be used in GitHub Actions by using the [`pypa/gh-action-pypi-publish`](https://github.com/pypa/gh-action-pypi-publish) GitHub Action defaults in a GitHub Actions environment. + +```yaml +jobs: + publish: + name: Publish release to PyPI + runs-on: ubuntu-latest + environment: publish-package + permissions: + # IMPORTANT: this permission is mandatory for trusted publishing + id-token: write + steps: + # retrieve your distributions here + # ... + + - name: Publish distribution to PyPI + uses: pypa/gh-action-pypi-publish@ # vX.Y.Z + with: + print-hash: true +``` + +### Example workflow + +The following is a complete example of workflow which can be used as a starting point: + +```yaml +name: publish distributions + +on: + workflow_dispatch: + +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true + +permissions: + contents: read + +jobs: + publish: + name: Publish Python distribution to PyPI + runs-on: ubuntu-latest + permissions: + id-token: write + attestations: write + environment: + name: publish-package + + steps: + # - name: Collect built artifacts + # ... + + - name: Generate artifact attestation for sdist and wheels + uses: actions/attest-build-provenance@ # vX.Y.Z + with: + subject-path: "dist/-*" + + - name: Verify sdist artifact attestation + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + run: gh attestation verify dist/-*.tar.gz --repo ${{ github.repository }} + + - name: Verify wheel artifact attestations + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + run: gh attestation verify dist/-*.whl --repo ${{ github.repository }} + + - name: Publish distribution to PyPI + uses: pypa/gh-action-pypi-publish@ # vX.Y.Z + with: + print-hash: true +``` + +## Notes + +- [Concise Guide for Developing More Secure Software from the OpenSSF](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) +- [GitHub Blog: Introducing Artifact Attestations–now in public beta](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) From be7c7502e84496ab935fdddb83bf02e94684071b Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Wed, 12 Jun 2024 22:36:40 +0200 Subject: [PATCH 02/18] Apply suggestions from code review Co-authored-by: Tim Head --- spec-0008/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 58bf7e3c..29a63dc8 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -44,10 +44,10 @@ The release process should be clearly and fully documented in the developer docu ### Hardening workflow environment permissions -Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `on workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). +Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. -It is also strongly recommended that the repository requires signed commits so that all releases have a verified commit to which they correspond. +It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that all releases have a verified commit to which they correspond. The branch from which the release is made should also be protected. #### Restrict permissions in CI runners to the minimum required @@ -77,7 +77,7 @@ Consult [Managing GitHub Actions permissions for your repository](https://docs.g #### Use GitHub Actions environments -Use a GitHub Actions environment +Use a [GitHub Actions environment](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment) ```yaml environment: @@ -120,7 +120,7 @@ updates: A component of SLSA is [software attestation](https://slsa.dev/attestation-model) which allows for public validation of software artifacts and provenance. GitHub provides the [`actions/attest-build-provenance`](https://github.com/actions/attest-build-provenance) GitHub Action which implements SLSA to generate signed build provenance attestations for workflow artifacts. -Attestations are publishes to the project GitHub under `https://github.com/ORG/PROJECT/attestations/`. +Attestations are published to the project GitHub under `https://github.com/ORG/PROJECT/attestations/`. ```yaml - uses: actions/attest-build-provenance@ # vX.Y.Z @@ -171,7 +171,7 @@ jobs: ### Example workflow -The following is a complete example of workflow which can be used as a starting point: +The following is a complete example of a workflow which can be used as a starting point: ```yaml name: publish distributions From eaa1ae48b11f24bc14febd34b59be6c9b49caab1 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Mon, 17 Jun 2024 23:09:33 -0500 Subject: [PATCH 03/18] Use for loop approach to get `gh attestation verify` working within reason This isn't great, but it works for the time being. --- spec-0008/index.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 29a63dc8..42200b88 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -132,15 +132,15 @@ GitHub has also added the [`gh attestation verify`](https://cli.github.com/manua This can be used by individual users and also in GitHub Actions workflows where the GitHub CLI utility is installed by default. ```yaml -- name: Verify sdist artifact attestation +- name: Verify artifact attestation env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: gh attestation verify dist/-*.tar.gz --repo ${{ github.repository }} - -- name: Verify wheel artifact attestations - env: - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: gh attestation verify dist/-*.whl --repo ${{ github.repository }} + shell: bash + run: | + for artifact in dist/*; do + echo "# ${artifact}" + gh attestation verify "${artifact}" --repo ${{ github.repository }} + done ``` ### Adopt OIDC through the use of PyPI Trusted Publishers @@ -205,15 +205,15 @@ jobs: with: subject-path: "dist/-*" - - name: Verify sdist artifact attestation - env: - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: gh attestation verify dist/-*.tar.gz --repo ${{ github.repository }} - - - name: Verify wheel artifact attestations + - name: Verify artifact attestation env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: gh attestation verify dist/-*.whl --repo ${{ github.repository }} + shell: bash + run: | + for artifact in dist/*; do + echo "# ${artifact}" + gh attestation verify "${artifact}" --repo ${{ github.repository }} + done - name: Publish distribution to PyPI uses: pypa/gh-action-pypi-publish@ # vX.Y.Z From ce242c1663df3c1c1a29d5fb60244b04dba0f561 Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Sat, 13 Jul 2024 19:58:45 +0200 Subject: [PATCH 04/18] Update index.md Co-authored-by: Matthew Feickert --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 42200b88..aa5a54a5 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -56,7 +56,7 @@ To restrict the attack surface area of arbitrary code execution in CI runners, t ```yaml permissions: - content: read + contents: read ``` Elevating permissions beyond this should be done at the job level by redefining the permissions block in the job. From 2addd0328e48f66ef4f0919757ff105c93983aea Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Sat, 13 Jul 2024 19:59:13 +0200 Subject: [PATCH 05/18] Update index.md Co-authored-by: Stefan van der Walt --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index aa5a54a5..0f8817f8 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -29,7 +29,7 @@ The Python Software Foundation (PSF) is also taking the importance of the OSSC s With the creation of the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being more widely adopted there are now high level developer tools, maintained by professional security teams, that are available with clear recommendations on how to use them. -This SPEC outlines the requirements for practically adopting these security tools and recommendations with a focus on securely publishing release artifacts. +This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. Securely building release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). This SPEC is written with GitHub in mind, note these recommendations still apply with other services such as GitLab and we refer project to these services' documentations and guidelines. From 9c22f17a50ae74645a25ce3a013e010ee99c037a Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Sat, 13 Jul 2024 19:59:25 +0200 Subject: [PATCH 06/18] Update index.md Co-authored-by: Stefan van der Walt --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 0f8817f8..cd99ae4a 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -30,7 +30,7 @@ The Python Software Foundation (PSF) is also taking the importance of the OSSC s With the creation of the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being more widely adopted there are now high level developer tools, maintained by professional security teams, that are available with clear recommendations on how to use them. This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. -Securely building release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). +Securely *building* release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). This SPEC is written with GitHub in mind, note these recommendations still apply with other services such as GitLab and we refer project to these services' documentations and guidelines. From afe1f7dcb8b723125e90e5f5e5eb99e3082275f4 Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Sat, 13 Jul 2024 19:59:41 +0200 Subject: [PATCH 07/18] Update index.md Co-authored-by: Stefan van der Walt --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index cd99ae4a..acae4199 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -32,7 +32,7 @@ With the creation of the [Supply-chain Levels for Software Artifacts (SLSA) fram This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. Securely *building* release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). -This SPEC is written with GitHub in mind, note these recommendations still apply with other services such as GitLab and we refer project to these services' documentations and guidelines. +While this SPEC is written with GitHub in mind, the same recommendations apply to other services, such as GitLab. ## Implementation From 214438c45140fc47fed9e0f254ab8e1af5389eef Mon Sep 17 00:00:00 2001 From: Pamphile Roy <23188539+tupui@users.noreply.github.com> Date: Sat, 13 Jul 2024 19:59:56 +0200 Subject: [PATCH 08/18] Update index.md Co-authored-by: Stefan van der Walt --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index acae4199..23b57b3b 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -47,7 +47,7 @@ The release process should be clearly and fully documented in the developer docu Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. -It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that all releases have a verified commit to which they correspond. +It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that each release corresponds to a verified commit. The branch from which the release is made should also be protected. #### Restrict permissions in CI runners to the minimum required From 1be873f360242955ad3d1a337a1c0fd734c9fda9 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 13 Jul 2024 11:04:40 -0700 Subject: [PATCH 09/18] fix: Address comments from Tim Head's review * Format things that are supposed to be variables that are project dependent like Shell variables (preceeded with a '$'). * Be more explicit with the actions permissions. * Add information on using RELEASING.md for making a release. --- spec-0008/index.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 23b57b3b..c429a84e 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -41,6 +41,7 @@ With a focus on securing the release artifact distribution process, the followin ### Document the release process The release process should be clearly and fully documented in the developer documentation and describe each step to make a release and the permissions required to do so. +It is recommended that this is a dedicated page in the developer section of the documentation website, though providing instructions in a `RELEASING.md` in the top level of the repository is also a common approach. ### Hardening workflow environment permissions @@ -63,15 +64,15 @@ Elevating permissions beyond this should be done at the job level by redefining #### Restrict permitted actions in workflows -GitHub allows to restrict the actions that workflows can use via repositories settings at `https://github.com/ORG/PROJECT/settings/actions`. -A reasonable default setup is to: +GitHub allows restricting the actions that workflows can use via the repository actions permissions settings at `https://github.com/$ORG/$PROJECT/settings/actions`. +A reasonable default is to select -- allow actions from the repository itself and actions created by GitHub, -- as well as an allow list of actions from third party repositories. +> Allow $ORG, and select non-$ORG, actions and reusable workflows - ``` - OWNER/REPOSITORY@* - ``` +and the suboptions: + +* Allow actions created by GitHub +* Allow specified actions and reusable workflows Consult [Managing GitHub Actions permissions for your repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository) for more details. @@ -85,7 +86,7 @@ environment: ``` and enforce additional review by at least one other maintainer to run a GitHub Actions workflow that publishes to PyPI. -Additional reviewer requirements can be configured per GitHub Actions environment under `https://github.com/ORG/PROJECT/settings/environments/` in the "Deployment protection rules" section. +Additional reviewer requirements can be configured per GitHub Actions environment under `https://github.com/$ORG/$PROJECT/settings/environments/` in the "Deployment protection rules" section. ![github-actions-environment](https://hackmd.io/_uploads/S1SErQ0EC.png) @@ -120,7 +121,7 @@ updates: A component of SLSA is [software attestation](https://slsa.dev/attestation-model) which allows for public validation of software artifacts and provenance. GitHub provides the [`actions/attest-build-provenance`](https://github.com/actions/attest-build-provenance) GitHub Action which implements SLSA to generate signed build provenance attestations for workflow artifacts. -Attestations are published to the project GitHub under `https://github.com/ORG/PROJECT/attestations/`. +Attestations are published to the project GitHub under `https://github.com/$ORG/$PROJECT/attestations/`. ```yaml - uses: actions/attest-build-provenance@ # vX.Y.Z From a782ef2126549a83f79a394b7f3d62ff144749de Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 13 Jul 2024 14:22:05 -0700 Subject: [PATCH 10/18] =?UTF-8?q?Add=20phrasing=20revisions=20following=20?= =?UTF-8?q?St=C3=A9fan's=20comments?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Juanita Gomez --- spec-0008/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index c429a84e..553cba76 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -24,10 +24,10 @@ Briefly and clearly describe the recommendation. https://github.com/scientific-python/summit-2024/issues/9 --> -Securing the Open Source supply chain (OSSC) is becoming a more relevant concern in recent years, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. +Open source libraries constitute a significant portion of the world’s digital infrastructure. Securing the Open Source supply chain (OSSC) is therefore an increasing concern, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. The Python Software Foundation (PSF) is also taking the importance of the OSSC seriously, as demonstrated by the [creation of the PSF Security Developer in Residence position in 2023](https://pyfound.blogspot.com/2023/06/announcing-our-new-security-developer.html). -With the creation of the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being more widely adopted there are now high level developer tools, maintained by professional security teams, that are available with clear recommendations on how to use them. +With the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being widely adopted, several high level developer tools, maintained by professional security teams, have been created with clear recommendations on how to use them. This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. Securely *building* release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). From 34843136468b635b625a007871cadc6b7d32448f Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 13 Jul 2024 14:24:21 -0700 Subject: [PATCH 11/18] nit: Don't use unicode charecters when ascii version exists --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 553cba76..238b4c7f 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -24,7 +24,7 @@ Briefly and clearly describe the recommendation. https://github.com/scientific-python/summit-2024/issues/9 --> -Open source libraries constitute a significant portion of the world’s digital infrastructure. Securing the Open Source supply chain (OSSC) is therefore an increasing concern, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. +Open source libraries constitute a significant portion of the world's digital infrastructure. Securing the Open Source supply chain (OSSC) is therefore an increasing concern, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. The Python Software Foundation (PSF) is also taking the importance of the OSSC seriously, as demonstrated by the [creation of the PSF Security Developer in Residence position in 2023](https://pyfound.blogspot.com/2023/06/announcing-our-new-security-developer.html). With the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being widely adopted, several high level developer tools, maintained by professional security teams, have been created with clear recommendations on how to use them. From db51e0d0cc18d6a6eb2237c3778e3f6362e935d0 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 09:56:55 -0700 Subject: [PATCH 12/18] chore: Revise phrasing for brevity --- spec-0008/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 238b4c7f..733fd1f7 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -30,7 +30,7 @@ The Python Software Foundation (PSF) is also taking the importance of the OSSC s With the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being widely adopted, several high level developer tools, maintained by professional security teams, have been created with clear recommendations on how to use them. This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. -Securely *building* release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). +Securely _building_ release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). While this SPEC is written with GitHub in mind, the same recommendations apply to other services, such as GitLab. @@ -53,7 +53,7 @@ The branch from which the release is made should also be protected. #### Restrict permissions in CI runners to the minimum required -To restrict the attack surface area of arbitrary code execution in CI runners, the default permissions the runners have should be restricted to the minimum possible (read access). In the GitHub Action workflow, this is accomplished by defining the following workflow global permissions block before any jobs are defined. +To restrict the attack surface area of arbitrary code execution in CI runners, the _default_ runner permissions should be restricted to the minimum possible (read access). In the GitHub Action workflow, this is accomplished by defining the following workflow global permissions block before any jobs are defined. ```yaml permissions: @@ -65,11 +65,11 @@ Elevating permissions beyond this should be done at the job level by redefining #### Restrict permitted actions in workflows GitHub allows restricting the actions that workflows can use via the repository actions permissions settings at `https://github.com/$ORG/$PROJECT/settings/actions`. -A reasonable default is to select +A reasonable default is to select the -> Allow $ORG, and select non-$ORG, actions and reusable workflows +* Allow $ORG, and select non-$ORG, actions and reusable workflows -and the suboptions: +option and the suboptions: * Allow actions created by GitHub * Allow specified actions and reusable workflows From 4816dbfe360af2f837a42f676b84a59ca6415830 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 10:27:39 -0700 Subject: [PATCH 13/18] Apply Brigitta's suggested changes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Brigitta Sipőcz --- spec-0008/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 733fd1f7..71be8d95 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -27,9 +27,9 @@ https://github.com/scientific-python/summit-2024/issues/9 Open source libraries constitute a significant portion of the world's digital infrastructure. Securing the Open Source supply chain (OSSC) is therefore an increasing concern, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 [`xz` utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)) and [malware attacks on PyPI](https://blog.pypi.org/posts/2024-04-10-domain-abuse/) highlighting the need for supply chain security to be taken seriously. The Python Software Foundation (PSF) is also taking the importance of the OSSC seriously, as demonstrated by the [creation of the PSF Security Developer in Residence position in 2023](https://pyfound.blogspot.com/2023/06/announcing-our-new-security-developer.html). -With the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) standard being widely adopted, several high level developer tools, maintained by professional security teams, have been created with clear recommendations on how to use them. +With the [Supply-chain Levels for Software Artifacts (SLSA) framework](https://slsa.dev/) and [OpenID Connect (OIDC) standard](https://openid.net/developers/how-connect-works/) being widely adopted, several high level developer tools, maintained by professional security teams, have been created with clear recommendations on how to use them. -This SPEC outlines pragmatic recommendations for adopting these security tools, and recommendations on how to publish release artifacts securely. +This SPEC outlines pragmatic recommendations for adopting these security tools and recommendations on how to publish release artifacts securely. Securely _building_ release artifacts will be covered in a later SPEC. This set of recommendations complements the recommendations from [SPEC 6 — Keys to the Castle](https://github.com/scientific-python/specs/blob/main/spec-0006/index.md). While this SPEC is written with GitHub in mind, the same recommendations apply to other services, such as GitLab. From 8d492bd37d70f9ab7789ad0cb739c56905fd0ba2 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 11:04:52 -0700 Subject: [PATCH 14/18] fix: Correct metadata formatting --- spec-0008/index.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 71be8d95..48a65cfb 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -1,20 +1,17 @@ # SPEC-8: Securing the Release Process --- - title: "SPEC 8 — Securing the Release Process" number: 8 date: 2024-06-04 author: - -- "Matthew Feickert " -- "Pamphile Roy " -- "Juanita Gomez " -- "Seth Larson " -- "Lars Grüter " - discussion: https://discuss.scientific-python.org/t/spec-8-supply-chain-security - endorsed-by: - + - "Matthew Feickert " + - "Pamphile Roy " + - "Juanita Gomez " + - "Seth Larson " + - "Lars Grüter " +discussion: https://discuss.scientific-python.org/t/spec-8-supply-chain-security +endorsed-by: --- ## Description From 18e8c8259b0b6946b98f18ee13f067ec2f3b89ac Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 11:18:26 -0700 Subject: [PATCH 15/18] Apply Brigitta's suggested changes on using bullet lists --- spec-0008/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index 48a65cfb..dc6ea6be 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -42,11 +42,11 @@ It is recommended that this is a dedicated page in the developer section of the ### Hardening workflow environment permissions -Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). +* Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. -It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that each release corresponds to a verified commit. -The branch from which the release is made should also be protected. +* It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that each release corresponds to a verified commit. +* The branch from which the release is made should also be protected. #### Restrict permissions in CI runners to the minimum required From 5ddb16e8a7da352ceb3082d3d34aeec43792d0fa Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 11:35:34 -0700 Subject: [PATCH 16/18] Use 'release team' to make it clear which members of the maintainer team --- spec-0008/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index dc6ea6be..ad4947cf 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -42,7 +42,7 @@ It is recommended that this is a dedicated page in the developer section of the ### Hardening workflow environment permissions -* Workflows that publish release artifacts should have _run triggers_ that require intentional actions by maintainers (e.g., `workflow_dispatch` in GitHub Actions) and require multiple maintainers to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). +* Workflows that publish release artifacts should have _run triggers_ that require intentional actions by the release team (e.g., `workflow_dispatch` in GitHub Actions) and require multiple the release team members to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. * It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that each release corresponds to a verified commit. @@ -82,7 +82,7 @@ environment: name: publish-package ``` -and enforce additional review by at least one other maintainer to run a GitHub Actions workflow that publishes to PyPI. +and enforce additional review by at least one other release team maintainer to run a GitHub Actions workflow that publishes to PyPI. Additional reviewer requirements can be configured per GitHub Actions environment under `https://github.com/$ORG/$PROJECT/settings/environments/` in the "Deployment protection rules" section. ![github-actions-environment](https://hackmd.io/_uploads/S1SErQ0EC.png) From f492de47a6e4982a248f967ebc3d431fbbc80f49 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sun, 14 Jul 2024 11:42:11 -0700 Subject: [PATCH 17/18] Fix grammar tyop MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Brigitta Sipőcz --- spec-0008/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index ad4947cf..e4ceaa2f 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -42,7 +42,7 @@ It is recommended that this is a dedicated page in the developer section of the ### Hardening workflow environment permissions -* Workflows that publish release artifacts should have _run triggers_ that require intentional actions by the release team (e.g., `workflow_dispatch` in GitHub Actions) and require multiple the release team members to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). +* Workflows that publish release artifacts should have _run triggers_ that require intentional actions by the release team (e.g., `workflow_dispatch` in GitHub Actions) and require multiple release team members to approve the workflow to run (c.f. "Use GitHub Actions environments" section below). This is to safeguard the project from any one maintainer having the ability to commit to the default branch and make a release directly. * It is also strongly recommended that the repository requires [signed commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) so that each release corresponds to a verified commit. From 01bacf6528492c157be3fbb0e0540d3380270e8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20Gr=C3=BCter?= Date: Sun, 14 Jul 2024 20:44:28 +0200 Subject: [PATCH 18/18] Update spec-0008/index.md --- spec-0008/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/spec-0008/index.md b/spec-0008/index.md index e4ceaa2f..ebd8a5d8 100644 --- a/spec-0008/index.md +++ b/spec-0008/index.md @@ -1,5 +1,3 @@ -# SPEC-8: Securing the Release Process - --- title: "SPEC 8 — Securing the Release Process" number: 8