Improper Artifact Integrity Validation

Incidents (8)

Attack path techniques used

• Push directly, without review (Submit malicious code)
• Delete branches and workflow runs (Delete code or cover tracks)
• Push a release tag to an unreviewed commit (Point a release tag at a bad commit)
• Repoint existing tags on a published Action (Point a release tag at a bad commit)
• Add a workflow that dumps secrets (Steal CI secrets and tokens)
• Run PR code in a privileged workflow (Steal CI secrets and tokens)
• Read secrets from the runner (Steal CI secrets and tokens)
• Poison a shared Actions cache (Poison the build or published package)
• Trigger the publish workflow from a tampered branch (Poison the build or published package)
• Publish a malicious version with a stolen token (Poison the build or published package)
• Flip private repos to public (Read or expose private code)
• Register the attacker's machine as a runner (Keep access)

Checklist items

The fixes for those techniques, plus the items ghtier tags with this risk.

• Branch protection on default/release branches: required reviews + required status checks
• Rulesets applied: push restriction, tag protection, sensitive file-path protection
• Enable audit logging and export it to a SIEM for retention and detection
• Third-party Actions pinned to a full commit SHA instead of a mutable tag or branch
• CODEOWNERS in place, required on sensitive paths
• Inventory every Actions secret and its visibility/scope; the results are usually surprising
• Cloud credentials migrated from static keys to OIDC federation, scoped to repo + branch
• Audit every use of pull_request_target and remove or restructure risky ones
• Set the default GITHUB_TOKEN permission to read-only at the org level
• Require approval for first-time/external contributor workflow runs on forks
• Restrict which Actions can run to GitHub-verified creators or an internal allow-list
• Adopt artifact attestations for build provenance on published binaries/images
• Publish packages with trusted publishing (OIDC) instead of long-lived registry tokens
• Put production secrets in environments with required reviewers
• Write and rehearse a credential-rotation runbook before you need it
• Restrict public repo creation, visibility changes, repo deletion, private forks and outside collaborator invites to owners
• Limit the number of organization owners to the minimum needed
• Disallow self-hosted runners on public repositories
• Require signed commits on the default branch of sensitive repos
• Make releases immutable, or protect release tags with a tag ruleset
• Do not restore Actions caches in release and publish workflows

Permissions involved

The GitHub permissions those incidents abused.