Your CI/CD Pipeline Is Your Biggest Attack Surface (And Your Security Team Doesn't Own It)

The most dangerous assumption in modern software security is that your supply chain is safe because you own the code. You do not own the code. You own the business logic. The code that runs your business is assembled from dependencies, base images, third-party libraries, and build tools — most of which your security team has never audited, and your CI/CD pipeline pulls in automatically on every build.

The CI/CD pipeline has become the highest-value target in enterprise software security. It sits at the intersection of developer access, production deployment authority, and automated trust. Compromise the pipeline and you do not need to breach the application — you wait for the next deployment to do it for you.

The governance gap makes this worse: engineering owns the pipeline, security does not have access to it, and neither team has clear accountability for its security posture. The result is that the system with the highest deployment authority in your organisation is also the least audited attack surface you have.

How SolarWinds Changed the Threat Model

In December 2020, SolarWinds disclosed that attackers had compromised their build pipeline and inserted malicious code into a routine software update. The malicious code was compiled, tested, signed with SolarWinds' legitimate certificate, and distributed to 18,000 customers — including multiple US government agencies — through the normal software update process.

The attackers did not breach SolarWinds' customers directly. They breached the trust relationship between a software vendor and its customers by owning the production of the software itself. The signed certificate, the legitimate update channel, the trusted vendor relationship — all of it became a delivery mechanism for malware.

SolarWinds was not an anomaly. XZ Utils (2024), 3CX (2023), Codecov (2021) — supply chain attacks are accelerating, growing in sophistication, and expanding from traditional software vendors to CI/CD infrastructure itself. The attack surface shifted from applications to the machinery that builds them.

The 6 Most Exploited CI/CD Attack Vectors

1. Dependency Confusion and Poisoned Packages

Package registries — npm, PyPI, Maven, RubyGems — are open platforms. Attackers register public packages with the same names as internal private packages. When a build pipeline resolves dependencies, it can fetch the attacker's public version instead of the internal one.

In 2021, security researcher Alex Birsan demonstrated dependency confusion attacks against 35 major companies including Apple, Microsoft, and Tesla — using only public techniques and responsible disclosure. The same method is now weaponised in active attacks. If your pipeline lacks private registries with explicit resolution precedence, this attack is viable today.

2. Secrets Exposed in Build Environments

Secrets routinely leak through CI/CD environments: API keys committed to source code and missed by reviewers, credentials printed in verbose build logs, cloud access tokens accessible through the metadata endpoint of a build runner, and signing certificates stored as unencrypted environment variables.

An attacker who gains read access to your CI/CD environment — through a misconfigured webhook, a compromised GitHub token, or a server-side request forgery vulnerability in a build step — inherits every secret that pipeline has ever handled. Pipeline secrets often have broad production access with no MFA protection and no expiry.

3. Unverified and Unscanned Base Images

Most container builds start with a base image from a public registry. Snyk research (2023) found that 51% of popular Docker Hub images contain at least one critical vulnerability, and many images are months behind on patches.

Beyond vulnerable images, malicious images have been found in public registries — uploaded by accounts with names similar to legitimate publishers. If your pipeline pulls base images by tag without digest pinning or cryptographic verification, you are introducing unaudited code into every container you build.

4. Compromised Build Runners and Agents

Build runners are high-privilege machines. A self-hosted GitHub Actions runner, Jenkins agent, or GitLab runner typically has access to production secrets, cloud deployment credentials, and source code repositories. They are also, in most organisations, the least-patched machines in the environment.

The 3CX supply chain attack (2023) began with a compromised build environment that injected malicious code into the 3CX softphone application before it was signed and distributed to 600,000 customers. The entry point was not the application — it was the runner.

5. Unsigned and Unverified Artifacts

If build artifacts — container images, binaries, packages — are not cryptographically signed, there is no integrity guarantee between build and deployment. An attacker with registry write access can replace a legitimate artifact with a malicious one and the deployment pipeline will deploy it without detection.

Artifact signing is one of the most consistently absent security controls in enterprise pipelines, despite being freely available through tools like Sigstore and cosign. A signed artifact with a verified provenance chain is extremely difficult to tamper with without detection.

6. Insufficient RBAC on Deployment Tooling

In many organisations, anyone with repository write access can trigger a production deployment. There are no environment-specific approval gates, no separation between staging and production deployment authority, and no break-glass procedures for emergency changes.

This is a governance problem that manifests in the CI/CD layer. A compromised developer account or a malicious pull request merged by an inattentive reviewer can become a production deployment within minutes, with no additional authorisation required.

The SLSA Framework — A Practical Hardening Standard

Supply chain Levels for Software Artifacts (SLSA, pronounced like the condiment) is a framework developed by Google and now maintained as a CNCF project. It defines four progressive levels of supply chain security maturity:

• SLSA Level 1 — Provenance is generated: every build produces a documented record of what source code and dependencies went in, and what artifact came out
• SLSA Level 2 — Provenance is signed and hosted on a tamper-resistant service; build environment is version-controlled
• SLSA Level 3 — Build environment is hardened and non-falsifiable; source code has two-party review for every change
• SLSA Level 4 — Hermetic builds with no external network access during build; two-person review required for all changes

SLSA Level 2 is the practical target for most enterprise CI/CD pipelines. It covers the majority of supply chain attack scenarios while remaining achievable with mainstream tooling (GitHub Actions, GitLab CI, Tekton) without requiring a complete pipeline rebuild.

5 Immediate Actions to Reduce CI/CD Risk

1. 1Scan dependencies on every build — Integrate Trivy or Snyk into your pipeline. Block builds with critical-severity CVEs. Do not allow unscanned dependencies to reach production.
2. 2Pin all container image references by digest — Replace floating tags like :latest with full SHA256 digest references. This guarantees the exact image pulled is the exact image you verified.
3. 3Move all secrets to a dedicated secrets manager — HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Eliminate secrets from environment variables, source code, and build logs entirely.
4. 4Sign your artifacts with Sigstore or cosign — Free, open-source, and integrates with all major container registries. Add signature verification as a mandatory deployment gate.
5. 5Enforce OIDC-based cloud authentication — Replace static API keys and long-lived cloud credentials with short-lived OIDC tokens. Eliminate standing credentials from your runner environments.

Who Actually Owns This Problem?

The CI/CD security gap persists because of an ownership problem. Development teams own the pipeline configuration. Security teams lack access to it and often lack the platform engineering knowledge to audit it. The pipeline is categorised as infrastructure, not application — so it receives infrastructure-level security attention, which is rarer and shallower.

The structural fix is a platform engineering team with explicit security accountability for pipeline infrastructure. Platform teams own the golden-path CI/CD templates, runner configuration, registry access policies, and deployment gates. When security requirements are built into the golden path, every team using the platform inherits them automatically — without depending on individual team compliance.

Securing Your Pipeline with GYSP

GYSP's Cyber Security practice works alongside our Cloud & DevOps Engineering team to deliver pipeline security programmes that close the governance gap without slowing delivery velocity.

We start with a pipeline security audit — mapping every attack vector across your current CI/CD environment, identifying the highest-risk gaps, and delivering a hardening roadmap sequenced by risk severity and implementation effort. Remediation covers SLSA framework implementation, secrets management migration, artifact signing, and runner security hardening.

“The SolarWinds attack was not a failure of application security. It was a failure of build pipeline security. Every organisation that ships software needs to understand: your pipeline is a production system with production-grade access — and it needs to be secured like one.”

— Dhaval S, Network & Security Lead — GYSP.tech