Problem
Every workflow step in .github/workflows/ci.yml and .github/workflows/contributors.yml references third party actions by mutable tag (actions/checkout@v7, actions/setup-node@v7, and the actions used inside the contributors workflow). Tags are movable refs: whoever controls the action repo can repoint v7 at new code.
.github/workflows/ci.yml also has no top level permissions: block, so its jobs get the repository default token scope. contributors.yml does set permissions: per job, so the repo already knows the pattern, CI just never got it.
Why it matters
contributors.yml triggers on pull_request_target and issue_comment, which run with write access to this repository and access to secrets, from contexts a fork can influence. A compromised or repointed tag in that workflow is a supply chain path to repo write. Pinning to a commit SHA removes the mutable-ref class of attack entirely.
Suggested approach
- Pin every
uses: in both workflows to a full 40 character commit SHA, with the human readable version in a trailing comment, for example uses: actions/checkout@<sha> # v7.x.
- Add
permissions: contents: read at the top of ci.yml and narrow any job that needs more.
- Configure Dependabot to keep the pins fresh.
.github/dependabot.yml exists already, add a github-actions ecosystem entry so the SHAs get bumped by PR rather than going stale.
- Re-read the
pull_request_target job in contributors.yml while you are in there and confirm it never checks out or executes untrusted PR code.
Done when
- No
uses: line in .github/workflows/ references a tag or branch.
ci.yml declares explicit least privilege permissions.- Dependabot covers
github-actions.
If you want to take this on, comment on the issue to claim it and it will be assigned. Please keep to a maximum of 2 open claims per person at a time so other contributors get a chance.
Problem
Every workflow step in
.github/workflows/ci.ymland.github/workflows/contributors.ymlreferences third party actions by mutable tag (actions/checkout@v7,actions/setup-node@v7, and the actions used inside the contributors workflow). Tags are movable refs: whoever controls the action repo can repointv7at new code..github/workflows/ci.ymlalso has no top levelpermissions:block, so its jobs get the repository default token scope.contributors.ymldoes setpermissions:per job, so the repo already knows the pattern, CI just never got it.Why it matters
contributors.ymltriggers onpull_request_targetandissue_comment, which run with write access to this repository and access to secrets, from contexts a fork can influence. A compromised or repointed tag in that workflow is a supply chain path to repo write. Pinning to a commit SHA removes the mutable-ref class of attack entirely.Suggested approach
uses:in both workflows to a full 40 character commit SHA, with the human readable version in a trailing comment, for exampleuses: actions/checkout@<sha> # v7.x.permissions: contents: readat the top ofci.ymland narrow any job that needs more..github/dependabot.ymlexists already, add agithub-actionsecosystem entry so the SHAs get bumped by PR rather than going stale.pull_request_targetjob incontributors.ymlwhile you are in there and confirm it never checks out or executes untrusted PR code.Done when
uses:line in.github/workflows/references a tag or branch.ci.ymldeclares explicit least privilege permissions.github-actions.If you want to take this on, comment on the issue to claim it and it will be assigned. Please keep to a maximum of 2 open claims per person at a time so other contributors get a chance.