Module 06 · CI/CD Security

Securing the CI/CD Pipeline

Your CI/CD pipeline has production credentials, deploys to production, and is often the least secured system in your infrastructure. Attackers know this.

Seven critical areas to lock down before your pipeline becomes the breach vector.

Threat Landscape

CI/CD as an attack vector

CI/CD systems are trusted by design. They pull code, execute arbitrary commands, access secrets, build artifacts, and deploy to production. Compromise the pipeline — compromise everything downstream.

Attack Surface
Why attackers target CI/CD
Pipelines run with elevated privileges, store credentials for cloud/infra/registry access, and execute untrusted code (PRs from forks). A single poisoned build step can backdoor every deployment.
OWASP CI/CD Top 10
Systematic risk categories
Insufficient flow control, inadequate identity management, dependency chain abuse, poisoned pipeline execution, insufficient PBAC, insufficient credential hygiene, insecure system configuration, ungoverned 3rd-party usage, improper artifact integrity, and insufficient logging.

The OWASP CI/CD Security Top 10 documents the most critical risks. Most organizations fail on at least seven of ten categories.

Supply Chain Attacks

When the build system is the weapon

IncidentVectorImpact
SolarWinds (2020)Compromised build system injected backdoor into Orion updates18,000 organizations, including US government agencies
Codecov (2021)Modified bash uploader script exfiltrated CI environment variablesThousands of repos' secrets stolen over 2 months
ua-parser-js (2021)NPM account takeover, cryptominer injected into package8M weekly downloads compromised
3CX (2023)Supply chain attack through compromised upstream dependency600,000 customer installations affected

Common thread: attackers did not breach the target directly. They compromised a trusted component in the build chain, and the pipeline did the rest.

Pipeline Hardening

Hardening the pipeline itself

Signed Commits
Verify author identity
Require GPG or SSH-signed commits. Unsigned commits could come from compromised accounts or spoofed identities. GitHub vigilant mode flags unsigned commits.
Branch Protection
Enforce review gates
Require PR reviews before merge, enforce status checks, disable force pushes, require linear history. No direct pushes to main — ever. Use CODEOWNERS for critical paths.
OIDC Auth
No long-lived credentials
Use OpenID Connect to get short-lived tokens from cloud providers. GitHub Actions OIDC eliminates stored AWS/GCP/Azure credentials entirely. Tokens scoped per workflow, per repo.

Additional controls: pin actions/plugins to commit SHAs (not tags — tags are mutable), use ephemeral runners that are destroyed after each job, and isolate pipeline execution environments.

Self-hosted runners are particularly dangerous: a malicious PR can execute arbitrary code on your infrastructure unless you restrict fork PR workflows.

Security Testing

SAST, DAST, and SCA integration

SAST
Static Analysis
Analyze source code for vulnerabilities before compilation. Semgrep, CodeQL, SonarQube. Run on every PR. Fast feedback loop catches SQL injection, XSS, hardcoded secrets early.
DAST
Dynamic Analysis
Test running applications for vulnerabilities. ZAP, Burp Suite, Nuclei. Run against staging after deployment. Catches runtime issues SAST cannot — auth flaws, misconfigs, SSRF.
SCA
Software Composition
Audit dependencies for known CVEs. Dependabot, Snyk, Trivy. 80%+ of code is open-source dependencies. One vulnerable transitive dependency compromises your application.

Critical: do not just scan — gate deployments on results. A scan that produces warnings no one reads is security theater. Define severity thresholds that block merges and break builds.

Secret scanning (GitLeaks, TruffleHog) catches credentials committed to repos. Run it pre-commit and in CI.

Artifacts + SBOM

Artifact signing and SBOM

Artifact Signing
Verify what you deploy
Sign container images and binaries with Sigstore/Cosign. Verify signatures in admission controllers and deployment pipelines. If it is not signed by your CI, it does not run in production.
SBOM
Software Bill of Materials
Generate SPDX or CycloneDX SBOMs for every build. Know exactly what is in your artifacts. Required by US Executive Order 14028 for government suppliers. Essential for incident response — "are we affected by CVE-X?"
SLSA Framework
Supply chain levels
SLSA (Supply-chain Levels for Software Artifacts) defines 4 maturity levels. Level 3 requires hardened build platforms with non-falsifiable provenance. The gold standard for build integrity.
Provenance
Attestation chain
SLSA provenance attestations record who built what, when, from which source, on which platform. Attach as in-toto attestations to every artifact. Consumers verify the full chain.

The combination of signed artifacts + SBOM + provenance attestation creates a verifiable chain of custody from source code to production deployment.

Key Takeaway

Shift-left security culture

Remember this

Shift-left does not mean dumping security tools on developers. It means giving developers fast, actionable feedback in the tools they already use — IDE, PR, CLI.

A security gate that takes 45 minutes will be bypassed. A scan that returns 2,000 findings will be ignored. Prioritize, tune, and make the secure path the easiest path.

Treat your CI/CD pipeline as a production system: audit access, rotate credentials, monitor for anomalies, apply least privilege, and maintain an incident response plan for pipeline compromise.

The pipeline is the software supply chain. Securing it is not optional — it is existential.

1 / 7