mirror of
https://github.com/apple/container.git
synced 2026-07-12 12:37:02 +00:00
ae279105a2
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>