A compromised CI/CD pipeline is as critical as a breach in production servers, because it is the source from which those servers are generated. Protecting it requires controls as strict or stricter than the production perimeter.
What is CI/CD
CI/CD (Continuous Integration / Continuous Deployment) is a set of practices and tools that automate the process of compiling, testing and deploying code to production. Continuous integration (CI) means that each code commit is automatically compiled and tested. Continuous deployment (CD) automatically carries validated changes to production or staging without manual intervention. An insecurely configured CI/CD pipeline is an open door for malicious code injection: an attacker who compromises repository credentials or CI/CD infrastructure can inject malware directly into applications deployed to millions of users.
Why it matters
For a CISO, CI/CD pipelines represent a critical risk point. They are the path through which code becomes production services. If an attacker can modify, redirect or inject content into a CI/CD pipeline, they compromise the integrity of everything that comes out of it. Historical incidents like SolarWinds and 3CX demonstrated that the software supply chain is a first-order target. CI/CD hardening practices include: role-based access control (RBAC), multi-factor authentication on repositories, code change auditing, automated security testing (SAST, DAST), signing of compiled artefacts, isolation of CI/CD infrastructure, and dependency scanning (SCA) to detect vulnerable or malicious libraries. Without these measures, the risk is exponential.
Key points
Vulnerabilities in dependencies (third-party libraries) are automatically introduced into compiled code if there is no dependency scanning (Software Composition Analysis - SCA) in the pipeline. A popular library with a discovered vulnerability can affect millions of applications.
Secrets (API keys, tokens, passwords) should not be in source code. They must be injected at deployment time from a secure vault. A secret exposed in a repository is almost impossible to fully revoke (Git maintains history).
Artefact signing guarantees that what was deployed is exactly what was compiled. Without signing, someone could swap an artefact in transit or storage without being noticed.
Example: CI/CD pipeline hardening in a tech startup
A startup with 50 developers uses GitHub for version control and GitHub Actions for CI/CD. Initially: (1) Any developer can merge code to main. (2) Secrets (AWS API keys, database tokens) are in environment variables with global access. (3) No automated security tests. (4) Compiled artefacts are not signed. An attacker compromises a junior developer's account. They inject code that steals customer data every night. The code passes functional tests because the logic is still correct. It deploys to production and affects 100,000 users before detection. After the incident, they implement: branch protection on main (requires review from 2 people), RBAC on GitHub (only tech leads can merge), secrets in AWS Secrets Manager (injected at deployment time, not in code), SAST (SonarQube) blocking suspicious patterns before merge, SCA alerting on vulnerable dependencies, artefact signing with cosign, and immutable audit logs. A new injection attempt is blocked automatically in the pull request.
Common mistakes
- Storing secrets in repository or code. Once in Git, the secret exists forever, even if you delete it later. Using secure vaults (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets) injected at deployment time is non-negotiable.
- Not validating code origin. Anyone who can merge is a vulnerability. Implementing branch protection, requiring code reviews from trusted people and using cryptographic commit signatures significantly reduces risk.
- Omitting automated security tests. SAST (static analysis), DAST (dynamic analysis) and SCA (composition analysis) in the pipeline detect vulnerabilities before they reach production. They are essential.
- Not auditing who accesses the pipeline or what changes are made. Without immutable logs of changes and access, it is impossible to investigate a compromise. Full audit and traceability are critical.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between CI and CD?
Continuous integration (CI) is the automation of compilation and testing each time there is a code change. Continuous deployment (CD) automates the release of that code to production. CI is mandatory; CD is optional if manual approval is required.
How do I protect credentials in CI/CD?
Never store them in code or visible variables. Use a secure vault (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets). The pipeline extracts credentials from the vault only when it runs, with strict role-based access control (RBAC).
What are SAST and DAST in CI/CD?
SAST (Static Application Security Testing) analyses source code without executing it, detecting patterns of known vulnerabilities. DAST (Dynamic Application Security Testing) executes the application and searches for behavioural vulnerabilities. Both should be in the pipeline automated.
What is Software Composition Analysis (SCA)?
SCA scans all dependencies (third-party libraries) of your code to detect vulnerable versions or components known to be malicious. It is critical because most modern code depends on dozens or hundreds of external libraries.