Understand
The ten ways a pipeline gets you
Application security has a canon that most engineers have at least heard of. CI/CD security has one too, and it is far less widely read — which is a strange state of affairs, because the pipeline is usually the system with production credentials, arbitrary code execution and the least scrutiny of anything you run.
Think about it from an attacker’s side for a moment. Why would you spend weeks looking for a flaw in a hardened production service when the thing that builds that service will run whatever code is in a pull request, holds a credential that can deploy, and nobody has looked at its permissions since it was set up?
This guide walks through all ten risks. Each page is written three times over: once for somebody meeting the idea for the first time, once for somebody who needs to actually fix it this week, and once for somebody who has done the obvious things and wants the harder version. The vocabulary is defined on every page rather than assumed, because a good half of what makes this subject difficult is that everybody writing about it takes the words for granted.
You do not need to read them in order. If something specific is worrying you, go straight to it.
- CICD-SEC-1Insufficient Flow Control MechanismsCode or artifacts can travel from a developer's keyboard to production without anything standing in the way.
- CICD-SEC-2Inadequate Identity and Access ManagementThe pipeline accumulates identities — human, machine, and inherited — that nobody has counted, scoped or retired.
- CICD-SEC-3Dependency Chain AbuseThe build fetches code from the internet and runs it, and an attacker only has to get their package into that set.
- CICD-SEC-4Poisoned Pipeline Execution (PPE)An attacker who can influence what the pipeline runs gets to run code with the pipeline's privileges, without ever touching production.
- CICD-SEC-5Insufficient Pipeline-Based Access ControlsA pipeline step runs with far more access than its job requires, so any code that reaches it inherits the surplus.
- CICD-SEC-6Insufficient Credential HygieneSecrets end up somewhere they were never meant to persist — a commit, a log line, an image layer, an environment dump.
- CICD-SEC-7Insecure System ConfigurationThe systems that run the pipeline are themselves unpatched, over-permissioned or exposed.
- CICD-SEC-8Ungoverned Usage of Third-Party ServicesThird-party integrations accumulate broad, permanent access to source and pipelines, and nobody re-reviews them.
- CICD-SEC-9Improper Artifact Integrity ValidationNothing checks that the artifact reaching production is the one that was built from the reviewed source.
- CICD-SEC-10Insufficient Logging and VisibilityWhen something does go wrong in the pipeline, there is not enough evidence to work out what happened.
Where to start if you only have an afternoon
Ten risks is a lot to hold at once, and in practice they are not equally urgent for everybody. If you are starting from nothing, this is a reasonable order:
- Credential hygiene — because a leaked secret is the one mistake that deleting it does not undo.
- Flow control — one required review on the branch that deploys changes a compromise from an outcome into an attempt.
- Dependency chain abuse — two flags on your install command close most of it.
- Poisoned pipeline execution — if you accept pull requests from outside your team, read this one before the others.
The rest matter, and they matter more once those four are handled.
Related
- Kubernetes manifest analyzer — paste a manifest and see which of these show up in it
- Dockerfile analyzer — the same for the image build
- Troubleshooting — if something is failing right now rather than insecure
Where the framework comes from
The ten risks, their identifiers and their titles are OWASP Top 10 CI/CD Security Risks, by Daniel Krivelevich and Omer Gil, published September 2022 under CC BY-SA 4.0. It is the canonical description and it is worth reading directly.
Everything on these pages — the explanations, the checks, the fixes, the glossaries — is written here rather than paraphrased from there. A summary of a page that already exists is just a worse version of that page.
Terms used here (3)plain definitions
Short definitions for the vocabulary on this page, in case any of it is new. Each links to the full entry.
- CI/CD
- Continuous Integration and Continuous Delivery/Deployment — the practice of automating the build, test, and release process. CI merges code changes frequently and runs automated tests. Continuous delivery keeps every change that passes in a releasable state, so it can go to production at any time; continuous deployment goes one step further and releases every passing change to production automatically.
- DevOps
- A way of building and running software in which the people who write it and the people who operate it share responsibility for how it behaves in production, and automate the path between the two. In practice that means small changes merged often (continuous integration), an automated route to production (continuous delivery), infrastructure described in code, and monitoring that tells the team quickly when something breaks. It is a set of practices and a way of working rather than a single tool. DORA's research measures it with four numbers: how often a team deploys, how long a change takes to reach production, how often a deployment fails, and how quickly the team recovers when one does.
- Pipeline
- An automated sequence of stages that code passes through from commit to production. A typical pipeline includes building, testing, security scanning, staging deployment, and production release, with gates between each stage.