Pin GitHub Actions to commit SHAs and declare workflow permissions - #1415
Open
Totara-thib wants to merge 3 commits into
Open
Pin GitHub Actions to commit SHAs and declare workflow permissions#1415Totara-thib wants to merge 3 commits into
Totara-thib wants to merge 3 commits into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
Mutable tags are movable pointers: whoever controls an action, or anyone who compromises it, can re-point the tag and the next run executes unreviewed code with the job's token, including in the release workflow that publishes to PyPI. Same pattern as the tj-actions/changed-files incident (CVE-2025-30066). Pinning to the full commit sha freezes what runs; the version each sha corresponds to stays as a comment. Every sha was resolved from the upstream repository and cross-checked against its release tag. No workflow logic changes.
Without a permissions block, every job's GITHUB_TOKEN inherits the repository default scope, which is broader than these workflows need. All six jobs only check out, test, or publish through dedicated secrets (codecov token, PyPI token), the GitHub token itself is never used. Everything gets contents read.
Scans the workflows on each push to master and on pull requests, and fails when something regresses: an unpinned action, a job without a permissions block, an archived dependency, a known CVE. It runs on the CLI's built-in default configuration, no config file needed. Each run publishes the score to score.getplumber.io, shown as a badge in the README.
Totara-thib
force-pushed
the
ci-hardening
branch
from
076ce16 to
1eebb89
Compare
August 3, 2026 14:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi, drive-by CI hardening in three commits, one logical change each.
Commit 1 pins every action to its commit sha, versions kept as comments. A tag like @v1 is a movable pointer: whoever controls the action, or anyone who compromises it, can re-point it and your next run executes their code with the job's token, including in release.yaml which publishes to PyPI. Same pattern as the tj-actions/changed-files incident (CVE-2025-30066). All shas were resolved from the upstream repos and cross checked against their release tags. The pins stay maintainable: if you want them bumped automatically, a dependabot config with the github-actions ecosystem does it, one small block. Worth knowing: codecov/codecov-action is still on v1, bumping it to a current major would be a good separate change, this PR only freezes what you already run.
Commit 2 adds permissions: contents: read to both workflows. The scope is exact, not guessed: all six jobs only check out, test, or publish through dedicated secrets (codecov token, PyPI token), the GitHub token itself is never used.
Commit 3 adds Plumber to CI, the tool I used to find the issues in the first place, so none of this quietly drifts back:
One heads up: if the org uses an Actions allowlist in settings, patterns written against tags (like owner/action@v1) stop matching once refs are shas and workflows refuse to start. Entries need to be owner/action@* in that case.
To be fully transparent: I work on Plumber. If you do not want the tool in your CI, no hard feelings, say so and I remove that commit from the PR, the two hardening commits are the part that matters and they stand entirely on their own.