Third-party CI actions are pinned to full commit SHAs, not mutable tags

A uses: someorg/some-action@v3 line in a GitHub Actions workflow trusts whoever controls that tag, forever: tags are mutable, so a compromised or malicious maintainer can retag v3 to point at new code and your CI runs it on the next push, with full access to your repository checkout and every secret exposed to the job. That is exactly what happened in the tj-actions/changed-files compromise (March 2025, CVE-2025-30066): attackers retagged the action and exfiltrated CI secrets from thousands of repositories that referenced it by tag. Pinning third-party actions to a full 40-character commit SHA makes the reference immutable, so upstream retagging cannot change what your pipeline executes. This evidences SOC 2 CC6.8 (prevention and detection of unauthorized or malicious software) and supports CC8.1 (change management: only authorized, reviewed changes enter the build pipeline). AI-generated and vibe-coded apps fail this almost universally, because every tutorial, template, and AI-scaffolded workflow writes @v4 style tags: the SHA-pinning convention only shows up when someone has been burned by supply chain attacks, and coding assistants reproduce the tutorial form.

For every third-party action in .github/workflows/*.yml, replace the mutable tag with the full 40-character commit SHA of the release you intend, keeping the version as a trailing comment so humans can still read it:

uses: tj-actions/changed-files@2f7c5bfce28377bc069a65ba478de0a74aa0ca32 # v46.0.1

Resolve the SHA with git ls-remote https://github.com/<owner>/<repo> refs/tags/<tag> or from the action's Releases page. Then add a .github/dependabot.yml entry with package-ecosystem: github-actions so Dependabot proposes SHA bumps when new releases ship, keeping pins current without reintroducing mutable refs.