Hardening GitHub Actions Against Outside Threats
Summary:
Many recent supply chain attacks did not compromise a maintainer. They got into the release pipeline, usually GitHub Actions, and shipped malware under the project's own trusted identity. Karlo Zanki's long first installment covers attackers with no credentials at all, grounded in named incidents: tj-actions/changed-files (repointed tags, about 23,000 repositories exposed), the Nx pull request title injection, Ultralytics and TanStack cache poisoning, and more. The fixes are mostly mechanical. Pin actions with the new gh actions-lock lockfile rather than a bare SHA, since a SHA proves immutability but not provenance. Default GITHUB_TOKEN to read-only. Keep fork code out of pull_request_target and away from jobs that hold publish credentials. Pass untrusted values through env instead of interpolating them into run steps. Set cache-mode to none on release jobs, use ephemeral self-hosted runners if any, install from a frozen lockfile with scripts off, and restrict egress. It also recommends a release-age cooldown for dependencies, which we added to this site's own installs this week. One date to note: GitHub moves public repositories to enforcing its stricter default event policy on December 2, 2026. Part two will cover insiders and stolen credentials, where these controls stop helping.
Excerpt:
"Socket's checklist for keeping attackers without credentials out of your GitHub Actions release pipeline: lockfiles, read-only tokens, safe triggers, cache isolation and egress control."
#Supply Chain Security#GitHub Actions#Security#DevOps#npm
Read Full Source