OpenShift Pipelines is a Kubernetes-based continuous integration and continuous delivery system for building and running application workflows on OpenShift. It uses Tekton-style tasks and pipelines, with execution managed through cluster resources, service accounts and RBAC to control what build and release jobs can do.
What OpenShift Pipelines Actually Is
OpenShift Pipelines is a Kubernetes-native continuous integration and continuous delivery system, so its core job is to turn source changes into repeatable build, test, and deploy workflows inside the cluster. The important security implication is that pipeline execution is not just software automation, it is an execution path with real authority, governed by cluster resources, service accounts, and RBAC.
That means the platform is best understood as part delivery orchestration, part trusted runtime. The value comes from standardising application workflows, but the same machinery can also become a high-impact control point if the pipeline definition, runner configuration, or identity used for execution is abused.
Why Its Kubernetes Model Matters
Because OpenShift Pipelines runs on Kubernetes primitives, its security posture inherits the same trust boundaries as the cluster. Tasks, pipeline runs, secrets, images, and service accounts are all part of the workflow surface, which means the control plane, namespace boundaries, and role assignments directly shape what a pipeline can reach or change.
In practice, this makes the system more flexible than a standalone CI server, but also more sensitive to overbroad permissions. A pipeline that can create pods, mount secrets, or invoke cluster APIs can become a pathway into build infrastructure, deployment targets, or internal data if its scope is not tightly defined.
How Access Control Shapes Build and Release Risk
The main security question is not only whether a pipeline works, but what it can do if a task, template, or referenced secret is compromised. Service accounts and RBAC determine whether pipeline steps are limited to a narrow build job or can act with broader cluster-level authority.
This is why build systems are often treated as privileged infrastructure. The workflow may be intended for automation, but its permissions can implicitly authorize code execution, image publishing, deployment changes, and secret access. If those permissions are reused broadly across environments, one compromised pipeline can affect many downstream systems.
Where It Fits in a Secure Delivery Chain
OpenShift Pipelines should be treated as one layer in the software delivery trust chain, not as a standalone guarantee of supply-chain integrity. The workflow can verify, build, and promote artifacts, but the integrity of the output still depends on source controls, dependency hygiene, runner isolation, and artifact provenance.
That is why delivery platforms need clear boundaries around who can modify pipeline definitions, which images and tasks are trusted, and how outputs are promoted. In mature environments, pipeline hardening works alongside SLSA to make build provenance and artifact integrity easier to trust.
Risk and Threat Considerations
CI/CD systems are attractive targets because they sit close to source code, credentials, deployment targets, and production release paths. If an attacker can alter a pipeline, steal a runner secret, or abuse a service account, they may be able to inject malicious code, exfiltrate secrets, or pivot into connected systems.
Failure mechanism: compromise usually happens through poisoned pipeline definitions, stolen credentials, excessive service account privilege, or insecure build-time access to cluster resources and secrets.
Impact: the result can be unauthorized code delivery, secret exposure, tampered releases, or broader cluster compromise that is harder to spot than a direct application breach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Pipeline service accounts and RBAC depend on controlled account use. |
| Recommendation — Restrict pipeline account scope and review privileged automation accounts regularly. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Pipeline service accounts are non-human identities that can be overprivileged. |
| Recommendation — Apply least privilege to pipeline service accounts and remove unnecessary cluster rights. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Build and release workflows need provenance and artifact integrity controls. |
| Recommendation — Adopt SLSA-aligned provenance checks for pipeline outputs and build steps. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipelines rely on secrets and credentials that must be managed across their lifecycle. |
| AC-6 — Least Privilege | RBAC should constrain what build and release jobs can do in the cluster. | |
| Recommendation — Rotate and safeguard pipeline credentials and tokens with strict lifecycle control. Limit pipeline permissions to the minimum required for each task and environment. | ||
Practitioner Guidance
Why practitioners should care: the primary design question is how much authority each pipeline step really needs. Treat the pipeline runtime as a privileged execution environment and separate build, test, and deploy permissions instead of giving one shared identity broad access.
What to watch for: monitor changes to pipeline definitions, task images, service accounts, and secret references, because those are the places where legitimate automation most often turns into an abuse path. The cleanest deployments are the ones where workflow convenience never substitutes for explicit trust boundaries.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org