ci: declare workflow-level contents: read on 2 workflows#4906
ci: declare workflow-level contents: read on 2 workflows#4906arpitjain099 wants to merge 1 commit into
contents: read on 2 workflows#4906Conversation
Pins the default GITHUB_TOKEN to contents: read on the workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout. The other workflows in this directory are left implicit because they need write scopes that a maintainer is better placed to declare. Motivation: CVE-2025-30066 (March 2025 tj-actions/changed-files compromise) exfiltrated GITHUB_TOKEN from workflow logs. Per-workflow caps bound runtime authority irrespective of repo or org default, give drift protection if the default ever widens, and are credited per-file by the OpenSSF Scorecard Token-Permissions check. YAML validated locally with yaml.safe_load. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
I don't think we have a workflow that is triggered on |
@AkihiroSuda This PR is about improving security through preventing default token permission cascade which here prevents writes and only makes read permissions which makes the least privilege principle on the actions |
Your reply doesn't seem to answer my question. |
|
May I ask if you are a human or a bot? You seem to have submitted 445 PRs just in 3 days: https://github.com/pulls?q=is%3Apr+author%3Aarpitjain099+created%3A2026-05-13..2026-05-15+ |
@AkihiroSuda Not a bot, I am using automation but all the PRs I am working upon cover similar improvements across multiple repos and I individually vet each PR. |
3 participants
Pins the default
GITHUB_TOKENtocontents: readon 2 workflows in.github/workflows/that don't call a GitHub API beyond the initial checkout.The following files were left implicit because they reference
GITHUB_TOKEN/ use a write-scope action / trigger onpull_request_target. Those scopes are best declared by maintainers:workflow-flaky.yml,workflow-tigron.yml.Why
CVE-2025-30066 (March 2025
tj-actions/changed-filessupply-chain compromise) exfiltratedGITHUB_TOKENfrom workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF ScorecardToken-Permissionscheck.YAML validated locally with
yaml.safe_loadon each touched file.