OWASP CI/CD Part 5 - Insufficient PBAC

One of the more overlooked yet critical vulnerabilities highlighted in the OWASP Top 10 for CI/CD Security Risks is Insufficient PBAC (Pipeline-Based Access Controls).

Let’s unpack what PBAC is, why it's essential, and how you can leverage modern access control tools like Open Policy Agent (OPA) and Rego to mitigate these risks effectively.

What is PBAC?

Pipeline-Based Access Control (PBAC) refers to fine-grained permissions tied to the context in which pipelines execute. This means evaluating what each pipeline (and each step within that pipeline) is allowed to access and modify.

CI/CD pipelines typically perform highly sensitive actions:

• Cloning and building source code.
• Accessing secrets from vaults, environment variables, or identity services (like the AWS Metadata Service).
• Creating and deploying artifacts, sometimes directly to production.

When PBAC is insufficient or misconfigured, attackers can exploit this to move laterally, exfiltrate data, or inject malicious artifacts. A compromised pipeline execution node inherits all the permissions of the pipeline stage it runs in, which are often far more than necessary.

How Does This Work in the Real-World?

To understand the real-world implications of insufficient PBAC, consider a scenario where an attacker successfully injects malicious code into your CI/CD pipeline. If that pipeline has broad, unrestricted access (such as embedded secrets, open network connectivity, and permissions to deploy to production environments) the consequences can be severe. 

Sensitive data like environment variables or authentication tokens may be exposed, enabling unauthorised access to internal systems or third-party services. Worse still, the attacker could tamper with the build itself, leading to the deployment of compromised software directly into production.

Beyond data leaks and malicious deployments, such an attacker might also use shared credentials or misconfigured access to pivot laterally within the CI/CD environment, compromising other pipeline nodes or even underlying infrastructure. The extent of damage in these cases is directly proportional to the level of control (and also restraint) imposed by your PBAC implementation. 

When pipelines are over-permissive, it’s like leaving every door in your system unlocked while leaving your house keys with the intruder. Granular, well-scoped PBAC policies are essential to limiting the blast radius while mitigating the potential risks.

PBAC Shouldn’t Just Be About User Permissions

It’s critical to understand that PBAC goes beyond user-level RBAC.
PBAC spans the entire execution environment.

While user-level access is foundational, PBAC must extend far beyond that to encompass the full breadth of the pipeline's execution environment. This includes: control over secrets that grant access to critical credentials, tokens, and identity services; network boundaries such as ingress and egress filters that regulate communication with internal systems or the public internet; and software artifacts, which require strict governance over which packages can be built, tested, or deployed.

Equally critical is the execution context, which sets the permissions that pipelines have over file systems, hosts, and even other pipelines. These elements define the scope and power of a pipeline and, if left unchecked, create opportunities for lateral movement and privilege escalation by adversaries. While modern CI/CD platforms like GitHub Actions, GitLab CI, Azure Pipelines, and CircleCI provide built-in access control features, they often lack the fine-grained enforcement required to secure complex environments effectively. 

This is where Rego’s Policy-as-Code (PaC) approach in tools like OPA is really powerful. OPA Rego enables teams to define and enforce detailed access policies programmatically across the entire CI/CD surface area.

Solving PBAC with PaC

Policy as Code (PaC) provides a scalable, auditable, and automated way to enforce access controls across your infrastructure and CI/CD pipelines. When applied to PBAC, PaC ensures:

• Consistency: Rules are enforced identically across environments.
• Auditability: Policies live in source control, making them reviewable and testable.
• Automation: Enforced at runtime inside the CI pipeline.
• Versioning: Policies evolve alongside your infrastructure, with traceable changes.

The most widely adopted tool for PaC is the CNCF project OPA, which uses the Rego language to express policies.

Rego is Powerful but Complex

Rego is a purpose-built language designed for policy enforcement. Its capabilities include support for RBAC, ABAC, and ReBAC models, as well as fine-grained decisions based on rich context. Rego also boasts high performance at scale. While Rego introduces a different way of thinking compared to traditional scripting languages. It’s approachable for anyone with a scripting background, and certainly becomes intuitive for first-time users with a little bit of practice. Its roots in logical programming (Prolog and Datalog) make it very different from typical scripting or general-purpose languages like Python or Go, however, the examples below should speed up the learning process.

In simple cases, Rego can feel declarative and familiar.
Here’s a simple example of a Rego policy to illustrate PBAC:

In this policy, the default allow = false line ensures that access is denied unless explicitly allowed. You’ll see this logic being used regularly in Rego. The allow block specifies conditions where access is granted. In this example, if the user is called "Nigel", they should only be able to read the associated helm package resources.

This works for basic cases, but as policies grow to reflect real-world scenarios, they naturally become more sophisticated, often involving nested logic, conditional rules, and integrations with external systems.

Practical Case for PBAC in Rego

Below is a more realistic Rego policy from Cloudsmith’s OWASP CI/CD Guide that implements PBAC:

This policy restricts who can access various pipeline stages and enforces stricter controls over protected repositories like "production".

Applying Rego in Package Management with Cloudsmith

Rego’s utility extends well beyond CI pipelines. It can also be used effectively to enforce package access and compliance policies within artifact registries like Cloudsmith. For example, in a Cloudsmith context, Rego policies can be written to automatically block developers and DevOps teams from using packages flagged with known vulnerabilities, leveraging risk indicators such as CVSS or EPSS scores. 

Additionally, Rego can be used to quarantine and therefore restrict access to packages that violate licensing policies - such as those distributed under copyleft or GPL licenses that may be non-compliant with organisational or legal requirements. The following example illustrates how such a policy might be implemented using Rego.

Alternatively, you can quarantine packages with CVSS scores exceeding a defined risk using Cloudsmith’s integration with OPA through Rego policies. This is particularly useful when a known fix has been published within a recent timeframe, letting you take timely action. 

You can see an example of this below:

This example highlights how Rego can be used to enforce multiple layers of access control over the software packages we build and consume. By embedding PaC directly into the package management workflow, DevSecOps teams can proactively enforce licensing and vulnerability compliance long before a package reaches production. 

Download our free eBook

If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, beyond enforcing PBAC policies, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems - download it here.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet