The Forgotten Attack Surface
When most practitioners think about offensive security, the mental model defaults to the familiar ones like exposed web endpoints, misconfigured network services, credential spraying against Active Directory. These are well-documented paths with established tooling, detection logic, and defensive playbooks. CI/CD pipelines are none of those things.
The software delivery pipeline, from the moment a developer pushes a commit to the moment a container image lands in production, represents one of the most structurally privileged and least scrutinized attack surfaces in the modern enterprise. A compromised CI/CD pipeline doesn’t just give an attacker access to one machine. It gives them the ability to inject malicious artifacts into every downstream system that trusts the build output, across every environment, with signing certificates and deployment credentials fully intact.
This is the threat model that our bootcamp “Commit → Build → Pwn” is built around: a structured, red team approach to attacking the full DevOps ecosystem, from source control enumeration to cloud workload compromise.
To Begin With
The core reason pipelines are so valuable to an attacker comes down to implicit trust. In most organizations, the artifacts produced by a CI/CD system are treated as authoritative. Container images are pulled and run. NPM packages are installed. Infrastructure-as-code is applied to cloud accounts. The trust is baked into the architecture.
This trust is often justified, when the pipeline is clean. But pipelines have a wide attack surface and a notoriously weak security posture. They are complex, multi-tenant, credential-dense systems built for developer velocity, not adversarial resilience.
Key structural weaknesses include:
- Build systems require credentials like tokens for Docker registries, AWS access keys, GitHub deploy keys, service account certificates. These secrets live in environment variables, in pipeline configuration files (which are often version-controlled), and in pipeline-platform secret stores that are accessible to any job executing in that environment.
- Misconfigured IAM roles attached to build runners commonly hold write access to artifact registries, production deployment targets, or cloud management APIs, far beyond what any individual pipeline stage actually requires.
- Source code management platforms like GitHub are frequently under-secured. Personal access tokens with overly broad scopes, branch protection rules that only apply to main, and repositories with misconfigured webhook secrets create entry points before a single line of pipeline YAML is even evaluated.
Supply chain inheritance: CI/CD systems consume third-party components like base images, GitHub Actions, npm packages, build scripts and inherit their security posture. A single malicious or compromised upstream dependency, if not pinned by digest, can inject arbitrary code into every build that references it.
The Kill Chain: From Commit to Cloud
The bootcamp structures its attack curriculum as a complete, end-to-end kill chain. Each phase produces artifacts like credentials, tokens, code execution that feed directly into the next phase. This is the right mental model for understanding how real pipeline compromises unfold.
Phase 1: Source Code Reconnaissance & Backdooring
The attack surface begins at the repository. Before touching a single pipeline job, an adversary can extract significant intelligence and gain persistence from the SCM layer alone.
Enumeration targets in GitHub:
- Exposed secrets in commit history (API keys, cloud credentials, private keys), often committed accidentally and never rotated even after removal from HEAD
- .env files, terraform.tfvars, and *.tfstate files checked in outside of .gitignore
- GitHub Actions workflow files (.github/workflows/*.yml) that reveal pipeline structure, environment variables, and injected secrets
- Organization-level settings: branch protection configuration, required reviewers, allowed merge strategies
Once read access to a repository is established either via a stolen PAT, a compromised developer account, or an overly permissive OAuth application, an attacker can introduce stealthy backdoors. The most impactful vector is modifying CI/CD workflow definitions. Since these files are version-controlled and executed by the pipeline runner on every trigger event, a malicious commit or pull request that alters a workflow file can achieve arbitrary code execution within the build environment.
Phase 2: Developer Tooling & Supply Chain Weaponization
Beyond the repository itself, attackers can compromise the build environment before a pipeline job ever runs by targeting the tools developers and build systems rely on.
Some of the key attack areas here include :
- IDE extensions operate with the full privileges of the developer’s session. A malicious or compromised VS Code extension can silently exfiltrate credentials from ~/.gitconfig, ~/.aws/credentials, SSH agent sockets, and active browser sessions. Because extensions are trusted by the IDE sandbox model and update automatically, they represent a persistent, low-visibility persistence mechanism.
- Many CI platforms support dynamic workflows, configurations that are partially generated at runtime or that pull external scripts. If any portion of the pipeline definition is constructed from attacker-controlled input (e.g., a PR branch name, a commit message, an environment variable sourced from a webhook payload), script injection becomes possible. GitHub Actions, for instance, historically allowed ${{ github.event.pull_request.head.ref }} expressions to be injected into run: steps, enabling arbitrary command execution from a forked PR.
- Dependency confusion, typosquatting, and direct package compromise are well-documented but still operationally effective attack vectors. If a build system npm installs packages from a registry without lockfile enforcement or integrity validation, an attacker controlling a dependency can execute arbitrary code at install time via preinstall and postinstall lifecycle hooks, running within the CI runner’s environment, with full access to its injected secrets.
Phase 3: Jenkins CI Platform Exploitation
Jenkins remains one of the most widely deployed CI platforms in the enterprise, and it remains one of the most consistently misconfigured.
Below table shows some of the most common Jenkins misconfigurations which are often found in the wild.
The Jenkins Script Console deserves specific attention. If accessible, whether due to no authentication, weak credentials, or an SSRF that routes to it from a compromised service, it provides a direct Groovy execution environment with access to the full Jenkins API. From there, an attacker can enumerate and decrypt stored credentials using Jenkins’ own com.cloudbees.plugins.credentials classes, modify existing jobs to exfiltrate build artifacts, or pivot to the underlying host OS.
Additionally, Jenkins stores credentials encrypted at rest using a master key derived from hudson.util.Secret. On the filesystem, the encrypted blobs live in $JENKINS_HOME/credentials.xml and job-specific config.xml files. If an attacker achieves read access to the Jenkins home directory either via path traversal, direct filesystem access on a shared runner, or through a privileged API call, offline decryption is straightforward using the co-located master.key and hudson.util.Secret files.
Phase 4: Cloud-Native Pipeline Exploitation
Modern organizations increasingly rely on cloud-native CI/CD services like AWS CodePipeline/CodeBuild, Azure DevOps, and GCP Cloud Build. These services introduce cloud identity into the build environment, creating a direct bridge between pipeline compromise and cloud infrastructure compromise.
AWS CodePipeline / CodeBuild
CodeBuild jobs execute within containers that have access to the IAM role attached to the CodeBuild project. If this role has overly permissive policies which is often a common finding, given that infrastructure engineers often grant * permissions to avoid troubleshooting friction, extracting the role’s temporary credentials via the EC2 Instance Metadata Service (IMDS) endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>) gives an attacker AWS API access scoped to that role. That being said, the IMDS V2 mitigates this by enforcing the hop limits for such requests.
From there, lateral movement into other AWS services follows naturally: reading from S3 buckets referenced in the pipeline, pushing to ECR to poison container images, accessing Secrets Manager entries, or assuming other IAM roles if sts:AssumeRole is permitted.
Environment variable exfiltration is also highly impactful. CodeBuild injects plaintext environment variables into the build environment, and these frequently include API keys, service account tokens, and database connection strings that operators consider “secure” because they’re managed through the CodeBuild console rather than hardcoded in source.
Azure DevOps
Azure DevOps introduces the concept of pipeline identities, Azure Active Directory service principals that pipeline agents authenticate as when executing jobs. These identities are often granted contributor or owner roles on Azure subscriptions, or broad permissions within Azure DevOps organizations themselves.
Key attack vectors include:
- Extracting the $(System.AccessToken) variable, which is a pre-authorized OAuth token for the Azure DevOps REST API, available by default in pipeline runs
- Abusing the REST API with the extracted token to enumerate repositories, variable groups (which store secrets), service connections, and agent pool configurations
- Leveraging service connections which store Azure credentials for deployment to pivot directly into Azure resource management operations
- Exploiting pipeline agent SSRF conditions to reach Azure IMDS and harvest managed identity tokens
Ending Notes
Personally, CI/CD has become sort of a favourite research area of mine as lots of things are unexplored and the impact is quite high. Especially, the area of workflow execution is something I like for vulnerability research because the underlying infrastructure often contains some subtle misconfigurations as uncovered by researchers on multiple managed CI/CD platforms.
