← OWASP Top 10 CI/CD Security Risks
CICD-SEC-1
Insufficient Flow Control Mechanisms
Code or artifacts can reach production without a second person or an automated gate approving them. On GitHub that is a default branch, tag or release anyone with write access can change alone.
Summary in ghtier's words. Read OWASP CI/CD's own text
Incidents (6)
Last 12 months (4): ChainDrop: a hijacked maintainer account publishes through trusted publishing, Megalodon: mass backdooring of CI workflows, hackerbot-claw autonomous agent RCE, GlassWorm: editor extensions that steal GitHub tokens and force-push
2026
- ChainDrop: a hijacked maintainer account publishes through trusted publishingOrganization August 2026
- Megalodon: mass backdooring of CI workflowsOrganization May 2026
- hackerbot-claw autonomous agent RCEOrganization February 2026
2025
- GlassWorm: editor extensions that steal GitHub tokens and force-pushUser October 2025
- GhostActionOrganization September 2025
2023
- Dependabot impersonationUser July 2023
Attack path techniques used
- Push directly, without review (Submit malicious code)
- Have a workflow approve the PR (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)
- Push a release tag to an unreviewed commit (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)
- Publish a malicious version with a stolen token (Poison the build or published package)
- Leave a dormant workflow behind (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
- Set the default GITHUB_TOKEN permission to read-only at the org level
- 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
- Require approval for first-time/external contributor workflow runs on forks
- 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
- Turn off "Allow GitHub Actions to create and approve pull requests"
Permissions involved
The GitHub permissions those incidents abused.