9.5.1. CI/CD Pipeline Security

💡 First Principle: A CI/CD pipeline is a supply chain — code enters at one end, and a deployable artifact exits at the other. Every stage of the pipeline is an opportunity to inject security verification, but also an opportunity for an attacker to inject malicious code if the pipeline itself is not secured. Pipeline security means both securing the artifacts flowing through the pipeline (scanning code and dependencies) and securing the pipeline infrastructure itself (build servers, credentials, artifact storage).

Security controls at each pipeline stage:

Gate policy: Automated gates are what let security keep pace with continuous deployment; human review is reserved for architecture changes and exceptions, not every commit. Set the build-breaking threshold by exploitability and impact: severe, exploitable findings (typically Critical and High, such as RCE or SQL injection) fail the build, and lower-severity findings become tracked tickets. IaC templates (Terraform, CloudFormation) are scanned the same way at the pull request, where tools such as Checkov or tfsec flag over-permissive IAM roles or public storage before the change is merged.

Keeping gates fast and honest: automated checks run in parallel with build and test, so they add minutes, not days. Block merges only on critical findings and route the rest to a security backlog. Tune rules to cut false positives, train developers to triage, and require security-team approval to suppress a finding — if developers can self-mark findings as false positives to unblock a merge, the gate becomes a formality.

Pipeline infrastructure security:

• Build server isolation — Build servers should be ephemeral (created fresh for each build, destroyed after) to prevent persistent compromise. A compromised build server that persists across builds can inject malicious code into every subsequent artifact.
• Secret management — Credentials needed during build (API keys, signing certificates, deployment credentials) must be stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager) and injected at runtime — never hardcoded in pipeline configuration files.
• Pipeline-as-code security — Pipeline definitions (Jenkinsfile, GitHub Actions workflows, GitLab CI YAML) are code and must be protected with the same rigor as application code: version control, code review, restricted modification permissions.
• Artifact integrity — Built artifacts should be signed. Deployment processes should verify signatures before deploying. This creates an unbroken chain of trust from source code to production.

SLSA (Supply-chain Levels for Software Artifacts):

SLSA defines four maturity levels for build integrity:

⚠️ Exam Trap: Secrets (API keys, database passwords, signing certificates) committed to version control are exposed permanently — even if deleted in a subsequent commit. Git history preserves every previous version of every file. A secret committed and then "deleted" is still accessible to anyone who can clone the repository and examine history. Secret scanning must check not just the current state but the full commit history.

Reflection Question: A post-incident review reveals that an attacker gained access to the organization's Jenkins build server, modified a build script to inject a cryptominer into the application binary, and the modified binary was automatically deployed to production through the CI/CD pipeline. No alerts were triggered. Identify the pipeline security controls that were missing, describe the architectural changes needed to prevent this attack class, and explain how SLSA Level 3 requirements would have detected the compromise.