Securing CI/CD pipelines without slowing engineering down

The CI/CD pipeline is where most organisations’ security posture is actually determined, and where most security programs do not look. The board document says all production code is reviewed by two engineers and signed releases are required. The pipeline says a self-approval is sufficient if the author also has merge rights, and the release artefact is whatever the build step happened to write to a shared bucket.

Pipeline security improvements are a high-leverage target because they generalise — every team using the platform inherits the change — and because the controls are concrete and testable, which audit appreciates. The challenge is that pipelines are owned by platform engineering, and most security programs do not have a working relationship with that team beyond raising tickets. That is the relationship to fix first.

Once you have it, the work falls into four bands roughly in order of impact.

Identity and provenance. The pipeline runner needs an identity that downstream systems can verify. OIDC federation between your CI platform and your cloud, container registry, and signing service replaces long-lived deployment keys. GitHub Actions, GitLab, and Buildkite all support this and the configuration is a few lines per repository. Combined with cosign and an in-toto attestation, the artefact you ship to production carries a verifiable record of which pipeline produced it from which commit. SLSA level 3 is the framework reference and it is achievable on commodity tooling without a dedicated pipeline rebuild.

Branch protection that actually protects. The default branch protection settings are inadequate for regulated firms. Require pull requests, require an approving review from someone who is not the author, require status checks to pass, dismiss stale reviews on new commits, restrict who can push to release branches, prevent force-pushes, and require signed commits. The audit objection that comes up here is “this slows engineers down.” The empirical answer is that for high-functioning teams the additional latency is measured in minutes, the catch rate of broken merges is materially better, and the audit conversation goes from a half-day to fifteen minutes. We have data points on this from three deployments and they all run the same way.

Secret management. This is where most pipelines leak. The mature pattern is short-lived workload identity (OIDC again) for cloud access, a secrets manager for everything else, no secrets in environment variables, no secrets in the repo, no secrets in the build logs. Add a secret-scanning pre-commit hook for inbound and a secret-scanning step in the pipeline as a defence in depth. Pre-commit catches the obvious case; the pipeline scan catches the merge from a fork or the engineer who skipped the hook. Quarterly rotation of any remaining static secret is the boring control that audits actually check.

Build environment isolation. A self-hosted runner with persistent state between jobs is the single biggest unmanaged risk in most pipelines we review. The fix is ephemeral runners — fresh container per job, no shared filesystem, no shared environment variables. Combined with network egress allow-listing on the runner (so a compromised dependency cannot exfiltrate to an arbitrary endpoint), this single change closes the supply chain attack class that compromised SolarWinds, Codecov, and several others. It is operationally fiddly to retrofit but easy to greenfield.

The piece that pulls all of this together is policy-as-code as a control plane, which we covered in a separate post. The short version is that you can express “production deployments require a SLSA level 3 attestation, signed by the org’s signing key, and the artefact must be from a protected branch” as a Conftest or OPA policy, and gate the deployment on the policy. The pipeline becomes its own auditor and the evidence trail is automatic.

For a CISO sponsoring this work, the practical sequence is: get OIDC federated to one production cloud account first (a week of work, enables everything else), enforce branch protection on the top ten repositories by traffic (a few hours), turn on secret scanning org-wide (a configuration change), then begin the migration to ephemeral runners which is the longest-tail item. Each step shows up clearly in the audit conversation and each is independently valuable. None require a tooling switch, which is usually the conversation that kills the program.