CI CD Security: A Practical Playbook for Modern Pipelines
September 24, 2026•CloudCops
A dependency update lands late on Friday. The pull request looks harmless, the tests pass, and the pipeline promotes the build without human intervention. By the time the on-call engineer notices unusual database traffic, the runner has already executed an unreviewed install hook, used an overprivileged cloud role, and handed an attacker a path into production.
That scenario is why CI/CD security can't be reduced to repository permissions or a vulnerability scanner. The pipeline connects source code, dependencies, build infrastructure, artifact registries, cloud identities, and production environments. Protecting it requires engineering controls, but it also requires governance, evidence, and a recovery plan for the moment a trusted build path stops being trustworthy.
Why Pipelines Are the New Front Line
A modern delivery pipeline is a privileged automation system disguised as a sequence of routine jobs. It checks out code, resolves packages, runs scripts, creates artifacts, publishes them, and authenticates against deployment targets. Each action can be legitimate, yet the combined trust chain gives attackers a route from an apparently ordinary change to a production compromise.
The risk is no longer theoretical. A 2026 survey of 400 IT, cybersecurity, and application professionals found that 77% of organizations experienced a software supply chain incident in the previous 12 months. The same software supply chain security report from Docker found that respondents ranked AI technology as their leading risk at 40%, ahead of third-party code at 39% and software dependencies at 38%.
How the blast radius expands
Consider three failure paths:
- A compromised build agent can inspect workspace files, environment variables, caches, and tokens available to the job. If the runner is persistent, later jobs may inherit files or credentials that the original task never needed.
- A tampered container image can pass application tests while carrying malicious code into the registry. If deployment uses mutable tags, the image running in production might not be the image that reviewers approved.
- A leaked deployment credential can bypass the intended release path entirely. The attacker doesn't need to alter source code if the credential can change infrastructure, deploy an image, or modify an environment directly.
The privilege assigned to the pipeline determines the damage. A test job with no secrets has a limited failure mode. A shared runner with cloud administrator access, package publishing rights, and production deployment permissions becomes a central compromise point.
ReversingLabs reported that malware on open-source platforms increased by 73% year over year in 2025, while npm recorded 10,819 malicious open-source packages, accounting for nearly 90% of detections across major open-source platforms in that threat picture. Its 2025 State of Software Supply Chain Security report describes a shift toward attacks on developer tooling, repositories, and CI/CD infrastructure itself.
Practical rule: Give every pipeline job the smallest authority needed for its current stage. Don't let a test runner inherit production deployment power because a later job needs it.
Teams looking for broader operating guidance can also review these top ten DevOps tips for AI teams, particularly where AI-assisted workflows process untrusted repository content. The useful question isn't whether your platform can run a build. It's whether an attacker can alter what gets built, what gets published, or where it gets deployed.
What CI/CD Security Actually Means
Think of the pipeline as a factory with four stations. Intake receives source changes and pull requests. Assembly compiles, tests, and packages them. Shipping stores and promotes the resulting artifacts. Deployment moves approved artifacts into environments where they can affect customers and data.
Each station has a different trust boundary:
- Intake: Protect repositories, branch rules, pull request workflows, commit identities, and review decisions. A signed commit has limited value if the receiving system doesn't verify the signature or if an untrusted workflow can rewrite the release branch.
- Assembly: Protect runners, build images, caches, package resolution, tool plugins, and environment variables. The central question is whether the build process can be influenced without leaving evidence.
- Shipping: Protect registries, artifact metadata, SBOMs, signatures, and promotion permissions. An artifact registry should preserve the exact object reviewers approved, not merely a mutable label such as
latest. - Deployment: Protect cloud roles, cluster credentials, admission policies, release approvals, and rollback paths. The deployment system must distinguish an approved artifact from an artifact that happens to have a familiar name.
CI security answers whether the software was built from the intended source with controlled inputs and a trustworthy process. CD security answers whether that exact artifact reaches the intended environment through an authorized path, under policies that limit the consequences of a mistake or compromise.
NIST SP 800-204D treats CI/CD as part of the software attack surface and recommends signed attestations for build artifacts, together with verification of inputs and outputs at each step. The NIST-oriented CI/CD supply chain guidance summarized by ReversingLabs frames provenance as a way to trace a release to its source, build entity, and process.
That gives a practical security test:
- Can an attacker change what gets built?
- Can an attacker change where it gets deployed?
If the answer to either question is yes, adding another scanner won't close the fundamental gap. You need authenticated identities, controlled build inputs, verifiable artifacts, and a recovery path that can revoke trust when those controls fail.
Mapping Threats to Controls
A useful audit starts with attack surfaces rather than products. The table below maps the area under pressure to a control category and a concrete implementation. Treat the final column as a verification target, not a shopping list.
CI/CD Threats Mapped to Mitigations
| Attack Surface | Primary Threat | Control Category | Concrete Implementation |
|---|---|---|---|
| Source control | Unauthorized changes, workflow tampering, malicious pull requests | Branch protection and verified identity | GitHub protected branches with required reviews, CODEOWNERS, and verified commit signatures |
| Build runner | Workspace theft, poisoned caches, secret exposure, persistence | Ephemeral and hardened execution | Ephemeral GitHub Actions or GitLab runners, restricted egress, read-only base images, and teardown after each job |
| Artifact registry | Image substitution, mutable tags, unverified packages | Immutability and provenance verification | Amazon ECR immutable tags, digest references, cosign verify, and signed attestations |
| Deploy plane | Credential misuse, unauthorized environment changes | Federated identity and policy enforcement | OIDC role assumption, Kubernetes RBAC, and OPA Gatekeeper policies |
| Runtime feedback loop | Silent drift, unapproved changes, incomplete investigations | Admission control and auditability | Kyverno or Gatekeeper admission rules, Kubernetes audit logs, and centralized deployment events |
Branch protection often fails open. A rule that requires a pull request but no meaningful reviewer leaves the approval process ceremonial. Signed commits have the same weakness if the server accepts unsigned commits on a release branch or nobody checks whether the signing identity belongs to the expected person or automation account.
Runner isolation also needs scrutiny. A self-hosted runner can look secure because it sits inside a private network, yet that placement increases the consequences of a compromised job if the runner can reach internal services. Ephemeral execution reduces persistence, but it doesn't excuse broad network access or excessive job permissions.
Artifact controls should be tied to deployment enforcement. Generating an SBOM is useful because it records what components are inside an artifact. Provenance answers a different question, namely how the artifact was built and whether that build path can be trusted. The SBOM and SLSA provenance distinction explains why mature programs use both rather than treating one as a substitute for the other.
A control that only produces a report is visibility. A control that blocks an unsafe release changes the risk.
Finally, test the feedback loop. If production rejects an unsigned image, someone needs the event, the reason, the affected commit, and the rollback option. Without those links, teams discover a policy failure during an outage and disable the policy to restore service.
Hardening Terraform, GitOps, and Runner Pipelines
Security improvements work best when they fit the existing delivery path. The objective isn't to create a parallel approval bureaucracy. It's to make unsafe states difficult to merge, difficult to promote, and easy to investigate.
Terraform
Store remote state in a dedicated backend with restrictive access, encryption, versioning, and audit logging. Authenticate CI jobs with OIDC-backed cloud roles instead of storing permanent access keys in repository secrets. Run terraform fmt, terraform validate, and an IaC scanner such as trivy config or checkov before a plan can merge.
Use OPA or Sentinel to block risky plans, including public storage, unrestricted security groups, and unapproved regions. CloudCops' guidance on Terraform policy as code is useful when turning those checks into merge-time controls rather than after-the-fact audit findings.
A minimal Conftest rule can reject public S3 buckets:
package terraform.security
deny[msg] {
resource := input.resource.aws_s3_bucket[_]
resource.acl == "public-read"
msg := "public S3 buckets are not permitted"
}
GitOps
For ArgoCD and Flux, protect the Git repositories as production control planes. Bind access to SSO identities, use narrow RBAC roles, require review for environment directories, and pin container images by digest instead of mutable tags.
ArgoCD's verification model should reject an image unless its signature matches the expected identity and issuer. The exact manifest varies by ArgoCD and policy-controller version, so validate it against the version you operate rather than copying an example blindly. The important behavior is deterministic, signed-image verification before sync, not the presence of a field that your controller ignores.
Flux's ImageUpdateAutomation can update Git references, but the automation account still needs reviewable boundaries. Pair image updates with Kustomize overlays, signed image verification, and a policy that prevents an automated commit from changing unrelated production configuration.
Runner pipelines
For GitHub Actions, GitLab, and Concourse, prefer ephemeral runners or isolated worker pools. Pin third-party actions and plugins to immutable commit SHAs, grant jobs only the permissions they need, restrict egress where feasible, and use short-lived OIDC credentials for cloud access.
A GitHub Actions role assumption should look conceptually like this:
permissions:
id-token: write
contents: read
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
aws-region: eu-west-1
The trust policy must validate repository, ref, audience, and workflow claims. A role name in YAML isn't a security boundary by itself.
Hardening Controls by Pipeline Layer
| Pipeline Layer | Top Controls | Common Cargo Cult |
|---|---|---|
| Terraform | Restricted state, OIDC, validation, IaC scans, policy gates | Running a scanner but allowing the plan to merge with ignored findings |
| GitOps | Protected repositories, digest pinning, signed-image verification, narrow RBAC | Calling Git the source of truth while granting direct cluster-admin access |
| Runners | Ephemeral workers, pinned actions, isolated egress, minimal tokens | Using self-hosted runners without workspace cleanup or network restrictions |
| Registries | Immutable tags, digest promotion, signatures, retention policy | Generating an SBOM while allowing unsigned replacement images |
| Emergency access | Expiring break-glass credentials, approval logging, post-incident review | Keeping permanent administrator credentials “for emergencies” |
Break-glass access has a place, especially during recovery. Make it expire in minutes, require a named approver, record its use, and revoke it automatically when the incident ends.
Repeat Build or Promote Build
The choice between repeat-build and promote-build is one of the most consequential CI/CD security decisions, yet teams often inherit it from their first pipeline template.
In a repeat-build model, each environment recompiles or re-images from source. This can maximize reproducibility when the toolchain is hermetic and every input is pinned. It also means every stage executes a new build process, with fresh opportunities for dependency drift, runner compromise, and toolchain inconsistency.
In a promote-build model, one signed artifact moves from testing through staging and production unchanged. Each environment verifies the artifact and its attestations, but doesn't rebuild it. The result is cleaner for forensics and faster to redeploy, especially when the same image must move across regions during disaster recovery.
The decision framework
| Decision Factor | Repeat Build | Promote Build |
|---|---|---|
| Build reproducibility | Strong when the toolchain is hermetic | Depends on the original build being reproducible |
| Artifact tampering | Limits reliance on a previously produced artifact, but repeats trust decisions | Makes substitution detectable through signatures and digests |
| Delivery speed | Slower because each stage builds again | Faster because gates validate an existing artifact |
| Forensics | Multiple build records can complicate analysis | One artifact and one provenance chain simplify investigation |
| Patching | A new build can incorporate changed inputs at each stage | Requires a deliberate rebuild and re-signing flow |
| Operational fit | Useful for controlled monorepos and fresh environment-specific SBOM requirements | Strong fit for multi-service SaaS and regional redeployment |
Repeat-build can be sensible for a monorepo with strong hermeticity, regulated workloads that require environment-specific analysis, or teams still dependent on mutable Docker tags. It does not solve the problem if builds are not reproducible. Re-running an uncontrolled process in another environment creates a second artifact, not stronger assurance.
Promote-build is usually the better default for services that need rapid, auditable promotion. It becomes especially compelling when paired with signed SLSA-style provenance and immutable storage. Compliance interpretations vary by system and assessor, so avoid treating a framework name as a substitute for control analysis. PCI DSS 4.0 and FedRAMP Moderate environments commonly push teams toward promote-build or an equivalent immutable-artifact design because reviewers need evidence that the released object is the approved object.
Choose the model you can verify under pressure, not the model that sounds most reproducible in a design document.
Short Lived Credentials and Signed Provenance
Static cloud keys in repository secrets create a long-lived trust relationship between a code host and a cloud account. Base64 encoding doesn't change that relationship. If an attacker reads the secret, the credential remains useful until someone rotates or revokes it.
OIDC federation changes the flow:
- A GitHub Actions or GitLab job requests a signed identity token from its platform OIDC provider.
- The cloud IAM trust policy validates claims such as
sub,aud, repository, branch, and workflow identity. - The security token service issues temporary credentials for a narrowly scoped role.
- The job uses those credentials for its task, while the artifact receives signed provenance tied to the source and build environment.
The exact session duration should follow the workload's needs, not a universal template. A deployment job shouldn't receive permissions to administer unrelated accounts, regions, or services.
For image signing, cosign can use keyless signing through Sigstore Fulcio, where the workload identity becomes part of the signing record. SLSA provenance generated by tools such as slsa-github-generator or Tekton Chains links the artifact to its source commit, builder, and inputs. The difference between SBOM visibility and provenance matters here because an SBOM can identify a vulnerable library while provenance can show whether the artifact came from the expected build path.
Admission controllers should reject unsigned or unverifiable images. You can enforce the same expectation in Terraform or OPA by blocking an apply or promotion when the required attestation isn't present. Keep the small set of secrets that must persist, such as certain registry or KMS credentials, in dedicated stores with ownership, rotation, and usage alerts.
An ArgoCD sync from ECR should follow a clear trust chain. ArgoCD reads a digest-pinned image reference, the verification policy checks the signature and issuer identity, the admission layer confirms the deployment meets policy, and the cluster records the sync and image digest. If any link fails, the deployment stops with an actionable event.
The following video provides a visual introduction to provenance and short-lived trust flows:
Turning Compliance Into Pipeline Evidence
Auditors rarely need another screenshot of a green pipeline. They need repeatable evidence that connects a change to an identity, an artifact, an approval, and a deployment decision.
For ISO 27001 secure-coding controls, collect SAST results, dependency decisions, signed commits, and SBOM changes. Threat-intelligence inputs can enter as dependency advisories, package denials, or documented risk decisions. For SOC 2 change management, the merged pull request and its signed provenance attestation can form the change record, while deployment approvals remain versioned beside the release metadata.
GDPR obligations require a different lens. Tag pipeline inputs and services according to data categories such as personal data or special category data, then use those tags to trigger deployment gates or DPIA evidence when a change introduces a new processing path. The pipeline shouldn't claim to solve privacy governance, but it can make the relevant decision visible at the point where the system changes.
Compliance control to pipeline evidence map
| Regulatory Control | Pipeline Evidence Required | Source System | Retention |
|---|---|---|---|
| ISO 27001 secure coding | Review record, SAST result, dependency decision, signed commit | Git and security tooling | Immutable evidence store under the approved retention class |
| ISO 27001 threat intelligence | Advisory input, affected dependency assessment, remediation decision | Dependency tooling and security case system | Linked to the affected build and risk decision |
| SOC 2 change management | Merged PR, approver chain, provenance attestation, deployment record | Git, CI platform, artifact registry | Versioned release evidence |
| GDPR security and privacy by design | Data classification, policy result, DPIA trigger or decision | IaC policy engine and privacy workflow | Linked to the change and processing path |
A practical evidence record might contain:
pipeline_run_id
commit_sha
signer_identity
sbom_hash
vuln_summary
approver_chain
retention_class
Store each field in the system that owns it. Git owns source and approval history. The OIDC issuer owns workload identity. The artifact registry owns binary digests and signatures. IaC scanners and policy engines own configuration decisions.
Teams often bolt on a GRC platform after the delivery system is already operating. Reconstructing evidence from chat threads and screenshots is slow, incomplete, and difficult to defend. A policy-as-code approach, such as the one described in this compliance as code implementation guide, keeps controls close to the change that triggered them.
When external testing is required, pair pipeline evidence with compliance-ready pentest reports that identify scope, findings, remediation, and retest status. The scanner brand matters less than whether the evidence is consistent, tamper-evident, and reproducible.
A 30 60 90 Day Rollout and the Signals That Prove It Works
A security program fails when it asks a platform team to rebuild every pipeline before reducing the most dangerous exposure. Start with inventory and privilege, then add provenance and enforcement to the services where compromise would hurt most.
Days 1 to 30
Create an inventory of runners, secrets stores, artifact registries, deployment roles, and workflow triggers. Mark which jobs can reach production, publish packages, or process untrusted pull request content.
Enable branch protection, meaningful review requirements, pipeline isolation, and workspace cleanup. Replace the most dangerous long-lived cloud keys with OIDC where the change is small and the trust policy can be reviewed properly.
Days 31 to 60
Select the five services with the largest blast radius, rather than the five services that are easiest to modify. Add SBOM generation, signed artifacts, SLSA-style provenance, environment-gated promotion, and a documented break-glass procedure.
A small platform team can make steady progress by publishing reusable workflow templates, Terraform modules, and policy bundles. Avoid forcing every application team to implement identity federation or signature verification independently.
Days 61 to 90
Connect pipeline events to security monitoring and define service-level objectives for detecting poisoned builds, revoking compromised tokens, and restoring a known-good artifact. Run a controlled exercise against the build path. Test whether responders can identify the affected commit, invalidate trust, stop promotion, and redeploy an approved artifact.
An enterprise with 200 or more repositories should phase the work by risk tier instead of promising universal coverage immediately. A startup platform team with five people may be able to establish the foundation within three months, while a larger estate may need six to nine months to migrate templates, identities, registries, and evidence flows safely.
Track signals that demonstrate control rather than activity:
- Poisoned-build detection time: How quickly the team identifies an untrusted build or dependency.
- Signed-provenance coverage: The share of released artifacts carrying verifiable provenance.
- Pipeline secret trend: Whether workflows are moving away from persistent credentials.
- Token revocation time: How quickly responders invalidate a compromised identity.
- Recovery confidence: Whether the team can redeploy the exact known-good artifact without rebuilding under uncertainty.
The goal isn't a perfect dashboard. It's a delivery system where trust is explicit, evidence travels with the artifact, and responders know what to revoke when the pipeline becomes suspect.
CloudCops GmbH designs and secures cloud-native, cloud-agnostic platforms with Terraform, GitOps, Kubernetes, policy as code, and auditable CI/CD workflows. If your team needs to reduce runner privilege, introduce signed promotion, or turn pipeline activity into compliance evidence, visit CloudCops GmbH to discuss an architecture and rollout plan.
Ready to scale your cloud infrastructure?
Let's discuss how CloudCops can help you build secure, scalable, and modern DevOps workflows. Schedule a free discovery call today.
Continue Reading
10 Essential SBOM Generation Tools for 2026
Discover the top 10 SBOM generation tools for 2026. Compare Syft, Trivy, and others for SPDX/CycloneDX support, CI/CD integration, and cloud-native use cases.
What Is SBOM: Critical for 2026 Security & Compliance
Learn what is sbom, why a Software Bill of Materials is critical for 2026 security & compliance, and its use in CI/CD.
Cloud Security Strategy: 2026 Playbook
Build a cloud security strategy for 2026 with core pillars, frameworks, policy-as-code, KPIs, and a roadmap for startups, SMBs, and enterprises.