← NIST SP 800-204D
5.3
Implementation strategy
How to roll the controls out in stages. One item covers the clients that talk to CI/CD systems, such as developer machines and their tools, without detailed requirements.
Summary in ghtier's words. Read NIST 800-204D's own text
Incidents (6)
Last 12 months (2): GitHub's internal repositories taken through a VS Code extension, GlassWorm: editor extensions that steal GitHub tokens and force-push
2026
2025
- GlassWorm: editor extensions that steal GitHub tokens and force-pushUser October 2025
- Shai-Hulud self-propagating worm (1.0 & 2.0)Organization September 2025
- Nx "s1ngularity"Organization August 2025
- GitHub MCP / agentic token breadthApplication May 2025
2022
- CircleCI session-cookie theftUser December 2022
Attack path techniques used
- Push directly, without review (Submit malicious code)
- Force push or delete a protected branch (Delete code or cover tracks)
- Delete branches and workflow runs (Delete code or cover tracks)
- Add a workflow that dumps secrets (Steal CI secrets and tokens)
- Run PR code in a privileged workflow (Steal CI secrets and tokens)
- Steal a session and read secrets from a CI vendor (Steal CI secrets and tokens)
- 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)
- Clone private repos with a stolen token (Read or expose private code)
- Flip private repos to public (Read or expose private code)
- Get an agent to copy private code into public (Read or expose private code)
- Register the attacker's machine as a runner (Keep access)
Checklist items
The fixes for those techniques.
- Branch protection on default/release branches: required reviews + required status checks
- Rulesets applied: push restriction, tag protection, sensitive file-path protection
- Deletion and force-pushes prevented on critical branches
- Require signed commits on the default branch of sensitive repos
- Enable audit logging and export it to a SIEM for retention and detection
- 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
- Enforce an IP allow list for Git and web UI access from trusted ranges
- Write and rehearse a credential-rotation runbook before you need it
- 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
- Set an organization-wide maximum PAT lifetime (90 days is a reasonable default)
- Disable classic PATs organization-wide, forcing migration to fine-grained PATs
- Audit and revoke stale PATs, unused SSH keys, and inactive accounts
- 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
- Review every currently installed GitHub App / OAuth App and its granted scope
- Keep OAuth app access restrictions on and require security/IT approval for new apps
- Disallow self-hosted runners on public repositories
Permissions involved
The GitHub permissions those incidents abused.