Files
container/.github/workflows
Melissa Kilby ae279105a2 chore: restrict GitHub workflow permissions - future-proof (#781)
See https://github.com/swiftlang/github-workflows/issues/167 for
additional context

This approach aligns with security best practices, as detailed in the
following documentation:

-
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
-
https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#defining-access-for-the-github_token-scopes
-
https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/


The default GITHUB_TOKEN permissions are defined at the repository
level. This PR modifies the workflow-level overrides to conform to
OpenSSF best practices -> defense in depth.

Allow me to quote OpenSSF:

https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

> The highest score is awarded when the permissions definitions in each
workflow's yaml file are set as read-only at the top level and the
required write permissions are declared at the run-level.”

> Remediation steps
> - Set top-level permissions as read-all or contents: read as described
in GitHub's documentation.
> - Set any required write permissions at the job-level. Only set the
permissions required for that job; do not set permissions: write-all at
the job level.


Compare to the LLVM project:

Top-level: contents read, e.g.
https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L3-L4
-> this makes it future-proof

Job-level: Allow write permissions as needed, e.g.
https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L53-L58

Signed-off-by: Melissa Kilby <mkilby@apple.com>
2025-10-17 15:03:41 -07:00
..