Continuous integration and continuous deployment pipelines have become the connective tissue of modern software delivery. They pull source code, build artefacts, run tests, and ship the results into production with minimal human intervention. That same speed and automation also makes them an attractive target. A compromised pipeline produces signed, deployed, trusted malicious software that bypasses every defence aimed at the perimeter or the production environment.
The Pipeline Is a Critical System
Treating the pipeline as low-risk infrastructure, the way many organisations do, ignores how much power it actually wields. Anyone who can modify pipeline configuration can ship arbitrary code to production. Anyone who can read the secrets stored in the pipeline can authenticate as the application identities they hold. Anyone who can influence the build process can introduce backdoors that propagate through the resulting artefacts. The blast radius rivals or exceeds production itself.
Source Code Repositories Need Tight Controls
GitHub, GitLab, Bitbucket, and Azure DevOps all host the source that pipelines build. The branch protection rules, the required approvers, the merge policies, and the access controls together determine what an attacker with developer access can accomplish. web application penetration testing that examines source control alongside the build pipeline catches issues that examining either in isolation would miss. Common findings include over-permissive branch policies, personal access tokens with excessive scopes, and admin access granted to far more people than the function requires.
Secrets Management in Pipelines
Pipelines need secrets to do their job. Where those secrets live, how they get exposed to running jobs, and who can read them deserves careful attention. Hardcoded credentials in pipeline configuration files appear regularly, sometimes in public repositories. Secrets stored in environment variables get logged inadvertently. Service principals used by the pipeline accumulate excessive privileges over time. Modern platforms offer better patterns through OIDC federation and dedicated secrets stores. Use them.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: I find pipeline secrets in places they should not be on most engagements. Build logs that printed environment variables for debugging, container images that copied entire .env files, public repository commits that included production credentials. The patterns repeat because nobody tests for them specifically until something has already gone wrong.
Build Artefact Integrity
An artefact built by a compromised pipeline is itself compromised, even if the source code passed every review. Signing build artefacts and verifying signatures on the way to production catches modifications between build and deploy. Maintaining provenance metadata, increasingly through SLSA frameworks and Sigstore tooling, makes the supply chain auditable. Combined with reproducible builds where feasible, this layer of integrity becomes a meaningful defence against pipeline-level attacks.
Self-Hosted Runners Bring Their Own Risks
Self-hosted CI runners, particularly those used for public repositories, become an attractive target for attackers who can submit pull requests. Pull request workflows running on attacker-supplied code in your privileged environment is a recipe for compromise unless properly scoped. Use ephemeral runners, restrict workflows from forks, segregate runner pools by risk class, and avoid storing privileged secrets on runners that handle untrusted code.
Validating the Whole Picture
Pipeline security spans source control, build infrastructure, secrets management, runtime environments, and the deployment targets themselves. A best penetration testing company who understands the full chain identifies weaknesses across the whole flow rather than focusing on one layer. The findings tend to be specific and actionable, since most pipeline issues have clean remediation paths once identified. The investment pays back the first time a developer account gets phished and the pipeline does not become the route to production.
