CI/CD pipeline pentesting: what needs to be audited

A compromised CI/CD pipeline doesn't grant access to a single application: it grants access to the factory that builds and deploys every application. It's one of the highest-impact surfaces in any software development organization, yet it's rarely audited with the same rigor as the application it produces.

Why a compromised pipeline is worse than a compromised application

Compromising an application in production grants access to that specific application. Compromising the pipeline that builds it grants the ability to inject malicious code into every future deployment, persistently and with the legitimate signature of the organization's build process. It's exactly the pattern behind the most severe software supply chain incidents of recent years: the attacker doesn't attack the final product, they attack the factory that produces it, because the impact multiplies with every release and every customer.

Exposed secrets in environment variables, logs and configuration

Pipelines handle high-value credentials — deployment keys, package registry tokens, cloud credentials with broad permissions — usually as environment variables or secrets managed by the CI/CD platform. The most common failures are: secrets hardcoded directly in the pipeline's own configuration file (versioned in the repository), secrets leaked into execution logs by a poorly managed debug command, and secrets with excessive scope — a production deployment key accessible from a pipeline on any random development branch.

Runner permissions and untrusted code execution

In repositories that accept external contributions or fork pull requests, it's critical to check whether CI/CD workflows automatically execute code from an untrusted pull request with access to the same secrets as a main-repository workflow. It's a known attack vector: an external attacker submits a pull request that, without needing approval, runs arbitrary code on the runner with access to the pipeline's credentials. You should also review the isolation of self-hosted runners, which, if poorly segmented, can grant access to the organization's internal network.

Dependency and software supply chain integrity

A secure pipeline must verify the integrity of every dependency it installs — using lockfiles, checksums and, where possible, package signatures — to prevent dependency confusion attacks (publishing a malicious package with the same name as an internal one on a public registry) or the compromise of a legitimate upstream dependency. Auditing this involves reviewing the configuration of the package registries used, whether SBOMs (Software Bill of Materials) are generated and verified, and whether a dependency scanning process (SCA) is integrated into the pipeline itself, not just run occasionally by hand.

FAQ

Does CI/CD pipeline pentesting replace a source code audit?

No, they're complementary. A source code audit reviews the application itself (SAST, manual logic and vulnerability review); pipeline pentesting reviews the infrastructure that builds and deploys that application — secrets, permissions, dependency integrity. Both surfaces matter because an attacker can choose whichever is weaker.

Which CI/CD platforms does this type of assessment cover?

The methodology applies to any platform — GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps — because the risks (exposed secrets, runner permissions, dependency integrity) are conceptually the same, even though configuration details differ between platforms.