What is pipeline-based access control (CICD-SEC-5) in CI/CD?

Pipeline-based access control (PBAC) means limiting each CI/CD pipeline, and each step inside it, to the exact data and resources it needs. OWASP lists weak PBAC as risk number five in its Top 10 CI/CD Security Risks. If malicious code runs in a build, PBAC decides how far it can reach.

What does OWASP say the problem is?

The OWASP entry for CICD-SEC-5, Insufficient PBAC, describes it as the context in which each pipeline and step runs. That includes access to code, secrets, environment variables and other pipelines, permissions on the underlying host and other nodes, and ingress and egress filters to the internet.

The impact statement is blunt. Malicious code that runs in the context of a pipeline node has the full permissions of the stage it runs in. It can read secrets, reach the host, and connect to any system the pipeline can. The damage is set by how granular your controls are, not by how the code got there.

How does malicious code end up in a build?

Several routes are routine. A compromised or typosquatted package runs an install script. A pull request from a fork changes a workflow file. A third party tool used in a step is itself tampered with. OWASP's reference list for this risk points to a code coverage tool compromised to steal environment variables from builds, and to dependency confusion attacks that executed code on CI nodes.

You cannot prevent every one of these. PBAC is the control you can plan for, because it assumes the first line failed.

What does over-broad access look like?

Here is a constructed example. A company has one shared runner pool and one deploy credential stored as an organization-wide secret. A documentation site build pulls a dependency that runs a post-install script. That script reads the environment, finds the deploy credential, and has network access to anywhere. A job that should only build static pages now holds the key to production.

Nothing in that story required a clever attack. It needed three defaults: shared nodes, wide secrets and open egress.

What does OWASP recommend?

The guidance maps neatly to practical settings:

• Do not use a shared node for pipelines with different sensitivity. Share nodes only between pipelines with the same confidentiality needs.
• Scope secrets so each pipeline and step gets only what it requires.
• Return the execution node to a pristine state after each run.
• Run jobs as an OS user with least privilege, and keep pipeline jobs' permissions on the controller limited.
• Patch the execution node.
• Segment the network so the node reaches only the resources it needs, and avoid unlimited internet access for build nodes.
• Run package installation scripts in a separate context that cannot see secrets from other stages.

How is this different from branch protection or code review?

Those controls decide who can change the pipeline definition. PBAC decides what a pipeline can do once it is running, whoever changed it. You need both, because a reviewed change can still pull in a hostile dependency at run time.

How to check or apply this

1. Inventory your pipelines and mark each as public-facing, internal or production-deploying.
2. Separate runners by that sensitivity. Production deploy jobs get their own ephemeral, dedicated nodes.
3. List every secret and write down which jobs use it. Remove the rest of the access, and move to short-lived credentials where your platform supports them.
4. Make the token each job receives read-only by default, and grant write scopes per job.
5. Put an egress allow list on build nodes. Allow your package proxy and artifact store, and block the rest.
6. Install dependencies in a step that holds no secrets, then pass only the built output forward.
7. Test it. Add a harmless step that tries to read a secret it should not have, and confirm it fails.

Safeguard policies and gates can sit in front of that last stage, blocking a merge or a release when a dependency or finding breaks a rule you set. That covers what enters the build; it does not replace scoping the runner.

Quick check

Sources

• OWASP Top 10 CI/CD Security Risks, CICD-SEC-5 Insufficient Pipeline-Based Access Controls
• OWASP Top 10 CI/CD Security Risks, CICD-SEC-3 Dependency Chain Abuse

Last reviewed: 18 October 2026.