Your CI/CD pipeline is one of the most powerful — and most dangerous — systems in your infrastructure. It has access to source code, secrets, cloud credentials, production environments, and container registries. A compromised pipeline can deploy malicious code directly to production, exfiltrate secrets, or provide an attacker with persistent access to your entire infrastructure. Hardening your pipeline is not optional — it is a critical security requirement.
Understanding the Attack Surface
CI/CD pipelines present a broad attack surface that many organisations underestimate:
- Source code repositories — compromised developer accounts or malicious pull requests can inject code that the pipeline will build and deploy.
- Pipeline configuration — if pipeline definitions (Jenkinsfiles, GitHub Actions workflows, GitLab CI YAML) are stored in the repository, anyone with write access can modify the build process.
- Dependencies — supply chain attacks through compromised packages, container base images, or build tools can inject malicious code at build time.
- Secrets and credentials — API keys, cloud credentials, and deployment tokens stored in the pipeline are high-value targets.
- Build environments — shared build runners can leak secrets between projects or allow lateral movement between teams.
Securing Source Code and Pipeline Configuration
- Require code review — enforce mandatory pull request reviews before any code reaches the main branch. Use branch protection rules to prevent direct pushes to production branches.
- Protect pipeline definitions — treat CI/CD configuration files with the same scrutiny as application code. Changes to workflow files should require additional review from a security or platform team.
- Sign commits — implement commit signing with GPG or SSH keys to verify the identity of code authors and prevent commit spoofing.
- Limit repository permissions — follow the principle of least privilege. Not every developer needs write access to every repository, and external contributors should never trigger pipeline runs automatically.
Secrets Management
Proper secrets management is arguably the most important aspect of pipeline security:
- Never store secrets in code — this includes pipeline configuration files, Dockerfiles, and application code. Use your CI/CD platform's built-in secret management or an external vault.
- Use external secret managers — integrate with HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault rather than relying solely on the CI platform's secret storage.
- Scope secrets tightly — limit which pipelines and environments can access each secret. Production credentials should not be available to development branch builds.
- Rotate regularly — automate secret rotation and ensure your pipeline can handle credential updates without manual intervention.
- Audit access — log every time a secret is accessed and review these logs regularly for anomalies.
Securing the Build Process
- Use isolated build environments — run each build in a fresh, ephemeral container or VM. Never reuse build environments across projects or runs. This prevents secrets from leaking between builds.
- Pin dependencies — use lock files (package-lock.json, Pipfile.lock, go.sum) and verify checksums. For container base images, pin to specific SHA digests rather than mutable tags.
- Scan for vulnerabilities — integrate dependency scanning (Snyk, Trivy, Grype) and static analysis (SonarQube, Semgrep) into every pipeline run. Fail builds that introduce critical vulnerabilities.
- Sign artefacts — sign container images with Cosign or Notary and verify signatures before deployment. This ensures that only images built by your pipeline can be deployed to production.
- Implement SBOM generation — generate a Software Bill of Materials for every build to maintain visibility into what components are included in your deployments, which is increasingly important for NIS2 compliance.
Deployment Security
- Separate environments — use distinct credentials and service accounts for development, staging, and production deployments. A compromised dev pipeline should not be able to access production.
- Implement approval gates — require manual approval for production deployments, especially for sensitive services. Many CI/CD platforms support approval workflows natively.
- Use GitOps for production — consider a GitOps approach where the pipeline only updates a Git repository, and a separate operator deploys to production. This eliminates the need for the CI system to have direct production access.
- Monitor deployments — implement automated rollbacks triggered by health check failures and anomaly detection in your monitoring stack.
How ICTLAB Can Help
ICTLAB provides CI/CD pipeline security assessments and hardening services for Belgian organisations. We review your existing pipelines for vulnerabilities, implement security controls across the build and deployment process, and integrate security scanning into your workflows — all as part of a comprehensive DevSecOps approach.