Insufficient PBAC (Pipeline-Based Access Controls)
OWASP Top 10 CI/CD Security Risks · CICD-SEC-5
Pipeline jobs run with whatever access their execution environment provides, and that access is frequently far broader than the job needs. A single compromised step therefore reaches credentials, networks, and artifacts belonging to unrelated parts of the system. Shared, long-lived runners make this worse by letting one job leave state, or secrets, behind for the next.
How it shows up in the real world
- All jobs in a pipeline receiving the full set of secrets, including production credentials for a test step.
- A self-hosted runner reused across jobs, retaining cached credentials and workspace contents.
- A build runner with network access to production databases and internal services.
- A job able to write to artifact stores and registries beyond the one it produces.
How to mitigate it
- Scope secrets to the specific job and environment that needs them, and inject them at the last moment.
- Use ephemeral, single-use runners and destroy them after each job.
- Segment runner networks so build environments cannot reach production, and use per-job identities.
- Restrict each job's write access to its own outputs, and require separate authorisation for deployment steps.
Practice this topic
Test your knowledge of Insufficient PBAC (Pipeline-Based Access Controls) with exam-style practice questions.
Rest of the CI/CD v1.0 list
CICD-SEC-1Insufficient Flow Control Mechanisms
Flow control is what stops a single change from reaching production unreviewed. Where those controls are missing or bypassable, anyone with commit access — or anyone who obtains it — can push code straight through to deployment. The problem is usually not the absence of a review process but the existence of paths around it: unprotected branches, direct registry pushes, or the ability to trigger a deployment without an approved artifact.
CICD-SEC-2Inadequate Identity and Access Management
CI/CD environments accumulate identities: human accounts, service accounts, bot users, integration tokens, and third-party app installations, spread across source control, build systems, registries, and cloud providers. They are rarely reviewed, frequently over-permissioned, and often outlive the person or project that created them, so the effective access of the whole system is far larger than anyone's model of it.
CICD-SEC-3Dependency Chain Abuse
Builds fetch dependencies automatically, and the resolution process itself can be manipulated. If a build can be induced to fetch a package the attacker controls — by claiming an internal name on a public registry, by taking over an abandoned package, or by registering a plausible misspelling — the attacker gets code execution inside the build with the build's credentials.
CICD-SEC-4Poisoned Pipeline Execution (PPE)
Pipelines execute configuration and scripts that live in the repository, which means influencing the repository can mean executing code in the build. Where a pipeline runs against untrusted contributions — most notably pull requests from forks — an outsider may be able to modify what runs and read the secrets available to that job. Variants differ in whether the pipeline definition itself is modified or a file it invokes is.
CICD-SEC-6Insufficient Credential Hygiene
CI/CD systems handle a large volume of secrets, and those secrets have a strong tendency to spread — into repositories, build logs, container image layers, environment variables, and artifact metadata. Long-lived static credentials are the core problem: they are copied between places, they outlast their purpose, and a single exposure remains exploitable until someone notices and rotates it.
CICD-SEC-7Insecure System Configuration
The CI/CD platform is itself production infrastructure holding credentials for everything, yet it is often configured with convenience in mind and patched on a slower schedule than the systems it deploys to. Self-hosted instances, runners, and orchestrators carry the usual hardening burden, and permissive defaults in the platform's own settings can undermine every control layered on top.
CICD-SEC-8Ungoverned Usage of 3rd Party Services
Modern pipelines integrate readily with external services — marketplace actions, code-quality tools, bots, and reusable workflows — and those integrations are typically granted broad, standing access to source and build environments. Because they can usually be added by any developer without security review, the set of third parties with write access to production code drifts well beyond what anyone has approved.
CICD-SEC-9Improper Artifact Integrity Validation
Between a reviewed commit and a running workload, an artifact passes through build, storage, promotion, and deployment. If nothing verifies at each handoff that the artifact is the one the pipeline produced from that commit, an attacker who can write to any intermediate store can substitute their own and have it deployed through the legitimate process, with no code change visible in review.
CICD-SEC-10Insufficient Logging and Visibility
Attacks on delivery infrastructure look like ordinary engineering activity, so distinguishing them depends almost entirely on telemetry. CI/CD logging is often thin, scattered across several tools, short-lived, and not forwarded anywhere that performs detection. That combination means a pipeline compromise can proceed without alarm and, afterwards, without enough evidence to establish what was built and shipped.