Skip to main content
DevOps Insightsguides & answers

Security

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.

  1. CICD-SEC-1

    Insufficient Flow Control Mechanisms

    Code or artifacts can travel from a developer's keyboard to production without anything standing in the way.

  2. CICD-SEC-2

    Inadequate Identity and Access Management

    The pipeline accumulates identities — human, machine, and inherited — that nobody has counted, scoped or retired.

  3. CICD-SEC-3

    Dependency Chain Abuse

    The build fetches code from the internet and runs it, and an attacker only has to get their package into that set.

  4. CICD-SEC-4

    Poisoned 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.

  5. CICD-SEC-5

    Insufficient Pipeline-Based Access Controls

    A pipeline step runs with far more access than its job requires, so any code that reaches it inherits the surplus.

  6. CICD-SEC-6

    Insufficient Credential Hygiene

    Secrets end up somewhere they were never meant to persist — a commit, a log line, an image layer, an environment dump.

  7. CICD-SEC-7

    Insecure System Configuration

    The systems that run the pipeline are themselves unpatched, over-permissioned or exposed.

  8. CICD-SEC-8

    Ungoverned Usage of Third-Party Services

    Third-party integrations accumulate broad, permanent access to source and pipelines, and nobody re-reviews them.

  9. CICD-SEC-9

    Improper Artifact Integrity Validation

    Nothing checks that the artifact reaching production is the one that was built from the reviewed source.

  10. CICD-SEC-10

    Insufficient Logging and Visibility

    When 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:

  1. Credential hygiene — because leaked secrets are the most common cause of a bad day, and the one where deleting the mistake does not undo it.
  2. Flow control — one required review on the branch that deploys changes a compromise from an outcome into an attempt.
  3. Dependency chain abuse — two flags on your install command close most of it.
  4. 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

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.