CI/CD pipelines are the assembly lines of modern software. They take source code and turn it into deployed applications, running tests, building artifacts, and pushing to production—often with minimal human oversight. That makes them one of the most attractive targets in the entire software supply chain.
A compromised pipeline can inject malicious code into every build. It can exfiltrate secrets that unlock access to production environments, cloud accounts, and customer data. And because pipelines are trusted by design—they need broad access to do their jobs—compromising one often means compromising everything downstream.
Despite this, most penetration testing engagements treat CI/CD pipelines as out of scope. That's a mistake.
The Attack Surface
A typical CI/CD pipeline involves multiple systems with distinct attack surfaces:
Source code management (GitHub, GitLab, Bitbucket): Where code is stored and where pipeline execution is triggered. Branch protection rules, access controls, and webhook configurations all matter.
CI/CD platforms (Jenkins, GitHub Actions, GitLab CI, CircleCI): The execution engines that run build jobs. These systems have access to secrets, network resources, and artifact stores.
Artifact repositories (Artifactory, Nexus, Docker registries): Where build outputs are stored before deployment. Tampering with artifacts here affects every downstream environment.
Deployment targets (Kubernetes clusters, cloud services, servers): Where pipeline output ultimately runs. The credentials needed to push to these targets are some of the most valuable secrets in the pipeline.
Secret management (Vault, AWS Secrets Manager, environment variables): How credentials and tokens are stored and injected into builds. Weak secret management is the most common finding in pipeline pen tests.
Reconnaissance Phase
Before attacking the pipeline, map it. Gather as much information as possible about:
- Which CI/CD platform is in use and what version
- How builds are triggered (webhooks, schedules, manual)
- What secret management approach is used
- Where artifacts are stored and how they're promoted between environments
- What access controls govern who can modify pipeline configurations
- Which third-party actions, plugins, or integrations are installed
Public repositories often leak pipeline configurations. GitHub Actions workflows, Jenkinsfiles, and GitLab CI YAML files in public repos tell you exactly how the pipeline works, what secrets it references, and which third-party components it trusts.
Attack Techniques
Secret Extraction
Secrets in CI/CD are the crown jewels. Common extraction techniques include:
Environment variable dumping: Many pipelines inject secrets as environment variables. If you can execute arbitrary code in a build context—through a malicious pull request, for instance—you can dump the environment and extract every secret available to that build.
Build log analysis: Pipelines sometimes log secret values accidentally, especially when debugging is enabled. Even when secrets are masked in logs, the masking is often imperfect or can be bypassed by encoding the output.
File system inspection: CI/CD runners may cache credentials on disk. Docker socket access, kubeconfig files, cloud provider credential files, and SSH keys on the build runner are all fair game.
Network interception: In shared build environments, it may be possible to intercept network traffic from other build jobs, capturing secrets in transit.
Pipeline Configuration Tampering
If you can modify the pipeline configuration, you control the build:
Pull request poisoning: Many CI/CD systems run pipelines on pull requests from any contributor. A malicious PR can modify the pipeline configuration to execute arbitrary code in the CI environment, even if the PR is never merged.
Branch protection bypass: Find ways to push directly to protected branches or trigger pipelines that skip required checks.
Cron job injection: Some CI/CD systems support scheduled builds. Injecting a cron-triggered build that runs with elevated privileges provides persistent access.
Artifact Tampering
Compromising artifacts after the build but before deployment is a powerful attack:
Registry credential theft: If you can access the credentials for the artifact repository, you can replace legitimate artifacts with trojaned versions.
Cache poisoning: Many build systems cache dependencies. Poisoning the cache means every subsequent build incorporates your malicious code without any change to the source repository.
Tag manipulation: In container registries, mutating a tag to point to a different image can redirect deployments to a malicious container.
Third-Party Action/Plugin Exploitation
CI/CD platforms rely heavily on third-party integrations:
Malicious actions/plugins: GitHub Actions, Jenkins plugins, and similar extensions run with the same privileges as the pipeline. A compromised action can access every secret and resource available to the build.
Pinning violations: Actions referenced by branch name (e.g., uses: action@main) instead of commit SHA can be changed by the action's maintainer at any time, including maliciously.
Supply chain through plugins: The CI/CD platform's own dependency chain is an attack vector. A compromised Jenkins plugin or GitHub Action is a supply chain attack on everyone who uses it.
Runner Compromise
The machines that execute build jobs are attack targets:
Shared runner exploitation: In environments where build runners are shared between projects or teams, escaping from one build to another can cross trust boundaries.
Persistent runner compromise: Self-hosted runners that aren't ephemeral may retain data from previous builds, including secrets and source code.
Container escape: Build jobs that run in containers may be able to escape to the host, especially if Docker-in-Docker is enabled or the Docker socket is mounted.
Testing Methodology
Phase 1: Access Control Review
Test who can modify pipeline configurations, access secrets, and trigger builds. Common findings:
- Developers with admin access to CI/CD platforms
- Service accounts with overly broad permissions
- Missing branch protection on deployment branches
- No approval requirements for pipeline configuration changes
Phase 2: Secret Management Assessment
Evaluate how secrets are stored, rotated, and scoped:
- Are secrets scoped to the minimum required context?
- Are production secrets accessible from PR builds?
- How frequently are secrets rotated?
- Can secrets be extracted through log manipulation?
Phase 3: Build Integrity Testing
Verify that build outputs can be trusted:
- Are builds reproducible?
- Are artifacts signed?
- Is there provenance tracking from source to artifact?
- Can build cache be poisoned?
Phase 4: Deployment Pipeline Testing
Assess the security of the deployment process:
- What credentials are needed for deployment?
- Is there separation between staging and production deployment credentials?
- Can deployment be triggered outside the normal approval process?
- Are deployment artifacts verified before execution?
Reporting Pipeline Findings
Pipeline vulnerabilities often require specialized context in the report. Include:
- A diagram of the pipeline architecture showing trust boundaries
- The exact path from initial access to impact for each finding
- Risk ratings that account for the blast radius of pipeline compromise
- Specific remediation steps, not just generic recommendations
- Quick wins vs. long-term architectural improvements
How Safeguard.sh Helps
Safeguard.sh integrates with CI/CD pipelines to provide continuous supply chain validation during the build process. The platform verifies dependency integrity, generates SBOMs at build time, and flags when builds pull components from unapproved sources. For organizations acting on pen test findings, Safeguard.sh provides the detection layer that catches the artifacts of pipeline compromise—unexpected dependencies, unsigned components, and deviations from the established software bill of materials.