CICD-SEC-1 is the first risk in the OWASP Top 10 CI/CD Security Risks. Insufficient flow control means one person or one automation can push code or artifacts through the pipeline to production with no second approval or review. An attacker who gains that one account inherits the same power.
What exactly does OWASP define?
OWASP defines it as the ability of an attacker who has obtained permissions to a system in the CI/CD process, such as source control, CI or an artifact repository, to single handedly push malicious code or artifacts down the pipeline because no mechanism enforces extra approval or review.
The reasoning is plain. CI/CD is built for speed, and code can go from a laptop to production in minutes with little human involvement. Organisations therefore add controls so no single entity, human or application, can ship without review. CICD-SEC-1 is what happens when those controls are missing or have gaps.
What are the abuse paths?
OWASP lists several, and they are concrete enough to test:
- Pushing to a branch that deploys to production automatically
- Pushing code and then manually triggering a pipeline that ships it
- Changing a shared utility library that production code uses
- Abusing an auto merge rule that merges pull requests meeting preset conditions
- Using exclusions in branch protection to bypass it
- Uploading an artifact to a repository posing as one built by the pipeline
- Changing production code or infrastructure directly, such as a serverless function, without approval
Notice how many are about exceptions: an excluded user, a trusted bot, an auto merge rule. Review rules usually fail at their edges.
What does OWASP recommend?
Set up flow control so no single entity can ship sensitive code or artifacts without external verification. The listed measures include branch protection on branches that feed production or other sensitive systems, avoiding exclusions of accounts or branches from those rules, and making sure accounts that may push unreviewed code cannot also trigger the deployment pipelines for that repository.
It also advises limiting auto merge rules to the minimum contexts, reviewing their code to ensure they cannot be bypassed, and controlling who may publish artifacts so that only the pipeline can write to protected repositories.
Has this happened in real projects?
OWASP's references point to public cases. Attackers pushed unreviewed malicious code directly to the main branch of the PHP git repository. An auto merge rule in Homebrew, meant to merge trivial changes, turned out to be bypassable. Researchers also showed that GitHub Actions could be used to get around required reviews and push to a protected branch. Read the original disclosures through the OWASP page before quoting details, since they are the primary record.
The last recommendation is about drift: detect and fix differences between what runs in production and what the pipeline produced, so a hand edit in production cannot sit unnoticed.
A constructed example
A team protects the main branch by requiring one approval. The build bot, however, is exempt so it can push version bumps. The bot's token is stored in a CI variable readable by any job.
A contributor opens a pull request that changes a test script. The script prints the token to the build log of a job that runs on pull requests from forks, and the contributor reads it. Using the bot's exemption, they push a change straight to main, and the deployment pipeline ships it. Each control existed, and the exception defeated them all.
The fix has three parts: remove the bot's bypass or restrict it to a version file, scope its token to that single task, and keep deployment from triggering on pushes by accounts that bypass review.
How to check or apply this
- List every repository that deploys to production, directly or through a shared library.
- For each, export branch protection settings and list every exempt user, team and bot.
- Require at least one review from someone other than the author on protected branches.
- Remove or narrow every exemption, and document those that must remain.
- Audit auto merge rules and confirm they cannot be satisfied by an attacker controlled change.
- Restrict artifact repository writes to the pipeline identity.
- Require approval for production deployment jobs, enforced by the platform and not by convention.
- Alert when a protected branch changes without a review record.
Quick check
Is branch protection enough?
It is the main control but not the whole of it. Exemptions, auto merge rules, manual pipeline triggers and artifact repositories are separate paths to production that need their own limits.
Where does OWASP rank this risk?
It is listed first, as CICD-SEC-1, in the OWASP Top 10 CI/CD Security Risks.
Sources
- OWASP, CICD-SEC-1: Insufficient Flow Control Mechanisms
- OpenSSF Scorecard checks, including Branch Protection and Code Review
Last reviewed: 18 October 2026.
