CI/CD Security Best Practices #
Secure CI/CD protects the path from source code to production. The goal is to make safe delivery the default by controlling identities, runners, secrets, artifacts, dependencies, infrastructure changes, and deployment approvals.
Overview #
Every CI/CD platform has different syntax, but the core security model is similar: protect the source, run trusted automation on isolated runners, use least-privilege credentials, build immutable artifacts, scan and sign what you ship, and preserve evidence for audits and incident response.
Best use cases #
- Organizations standardizing pipeline guardrails across multiple CI/CD tools.
- Teams moving from long-lived deployment keys to short-lived identity federation.
- Regulated services that need traceable approvals, artifacts, and deployment history.
- Platform teams creating reusable workflow templates and secure runner pools.
- Kubernetes and IaC deployments where misconfiguration can create production risk quickly.
Minimal pipeline example #
This example shows the control flow rather than a specific vendor syntax:
pipeline:
validate:
- lint
- unit-test
- secret-scan
- dependency-scan
- iac-scan
build:
- build-immutable-artifact
- generate-sbom
- scan-container-image
- sign-artifact
deploy_staging:
- assume-short-lived-deploy-identity
- deploy-same-artifact
- run-smoke-tests
deploy_production:
- require-approval-or-risk-check
- verify-artifact-signature
- deploy-same-artifact
- monitor-and-rollback-if-needed
Secrets handling #
- Store secrets in approved secret managers or CI/CD secret stores, never in repositories.
- Prefer short-lived credentials from OIDC, workload identity federation, or managed identity.
- Scope secrets by environment and repository so a test job cannot access production credentials.
- Mask secrets in logs and prevent them from being written to artifacts, caches, workspaces, or test reports.
- Rotate secrets, remove unused secrets, and alert on accidental exposure.
Deployment options #
- Direct deployment from CI/CD using least-privilege cloud or platform identities.
- GitOps deployment where CI produces artifacts and updates declarative desired state for a controller to reconcile.
- Progressive delivery with canary, blue-green, feature flags, or staged rollouts.
- Infrastructure deployment with Terraform, OpenTofu, Bicep, Pulumi, CloudFormation, Helm, or Kustomize.
- Manual approval, change-management integration, or automated risk scoring for sensitive production releases.
Security considerations #
- Protect pipeline configuration with code review, branch protection, CODEOWNERS, and required checks.
- Isolate runners by trust level; do not run untrusted pull requests on runners with production network access.
- Keep runner images patched and prefer ephemeral runners for high-risk jobs.
- Minimize token permissions and set explicit read/write scopes for each job.
- Build once, produce immutable artifacts, and promote the same artifact across environments.
- Generate SBOMs, scan dependencies and images, and sign or attest artifacts for high-risk systems.
- Use policy-as-code for Kubernetes and IaC changes before deployment.
- Retain logs, approvals, scan findings, artifact metadata, and deployment records for audits and investigations.
Related internal links #
- DevSecOps — Shift security into design, code, CI/CD, infrastructure, and runtime operations.
- GitOps — Reduce deployment credential exposure with pull-based reconciliation.
- Kubernetes — Apply image, admission, and runtime guardrails to clusters.
- Infrastructure as Code — Scan and govern cloud infrastructure changes before apply.
- GitHub Actions — Apply these controls to GitHub-native workflows.
- GitLab CI/CD — Apply these controls to GitLab pipelines and runners.
- Jenkins — Apply these controls to Jenkins controllers, credentials, plugins, and agents.
- Azure DevOps Pipelines — Apply these controls to service connections, environments, and approvals.
- CircleCI — Apply these controls to contexts, orbs, workflows, and runners.