CI/CD pipeline

A CI/CD pipeline is an automated workflow that covers the stages of Continuous Integration (CI) and Continuous Delivery/Deployment (CD) in software development. In simpler terms, it’s the process that builds, tests, and deploys code changes automatically. 

For example, when developers commit code to a repository, the CI stage kicks in to compile the code and run unit tests. If all tests pass, the CD stage can then deploy the new build to a staging or production environment. These pipelines are orchestrated by tools like Jenkins, GitLab CI, GitHub Actions, Azure DevOps, or others, and consist of a series of steps (build, test, scan, deploy, etc.) defined in code (often as a YAML or similar configuration). 

From an identity perspective, the CI/CD pipeline itself often acts with certain identities: it may use service accounts or API keys to access repositories, cloud infrastructure, or production servers. In essence, the pipeline automates what used to be manual ops tasks, enabling rapid and frequent releases.

How does it affect identity security?

CI/CD pipelines are a critical part of the software supply chain, and securing them is a significant aspect of identity security. If a pipeline is compromised, attackers can inject malicious code into applications or steal secrets that are embedded in the pipeline, such as API keys, certificates, or credentials for deployment. Because the pipeline has access to source code and often privileged deployment rights (like the ability to push code to production or spin up cloud resources), it’s a high-value target. 

Ensuring identity security here means tightly controlling who (and which processes) can modify the pipeline, and what the pipeline itself can access. Practicing the principle of least privilege in pipelines might involve giving the pipeline its own service identity with only the minimal rights needed (for example, permission to deploy to one specific cluster, but nothing else). It also involves protecting secrets (using vaults or secret managers, rather than plain text in config files). 

A secure CI/CD pipeline will have strong authentication for any triggers or webhooks, code signing to validate build integrity, and monitoring to detect unusual build or deployment activities. Essentially, the CI/CD pipeline extends your identity boundary: not only must your users be trustworthy, but the automated processes acting on behalf of your organization must be trustworthy as well.

Case study

A dramatic example of a CI/CD pipeline compromise is the SolarWinds “Sunburst” supply chain attack in 2020. In that incident, nation-state hackers infiltrated SolarWinds’ build environment – effectively the CI/CD pipeline for their Orion software – and inserted a backdoor into the software updates that SolarWinds was compiling for customers​. 

The attackers introduced malware (later called SUNSPOT and SUNBURST) into the build process, which silently injected malicious code into SolarWinds’ Orion product without triggering the developers’ suspicion. Because the build system itself was compromised, it dutifully signed and delivered the trojanized software as if it were legitimate. This backdoored update was then installed by thousands of SolarWinds’ customers, including U.S. government agencies, leading to one of the largest supply chain breaches in history. 

The root cause was that the pipeline’s security was breached – the attackers had access to the software signing process and the identity under which builds ran. This case underscores that CI/CD pipelines are part of the trusted computing base; if attackers break into the pipeline, they effectively hijack the identity of the software publisher.

‍