CI/CD security best practices for 2026: secrets management, scoped access, dependency scanning, signed artifacts, and audit logging in one checklist.
TL;DR
- Your build system holds credentials for every environment it deploys to, which makes it a higher value target.
- Six controls carry most of the weight: managed secrets, scoped access, dependency scanning, signed artifacts, audit logs.
- Only 43% of organizations have automated their CI and build pipelines, while 51% have automated coding workflows.
- Roll out in three moves, visibility then policy then enforcement, so teams see failures before anything blocks a merge.
What are CI/CD security best practices?
CI/CD security best practices are the controls that protect your delivery pipeline itself, and 86% of engineering leaders and practitioners say those checks need more automation.
- Secrets stay in a managed store, injected at runtime.
- Access is scoped per environment through RBAC.
- Dependencies are pinned, inventoried in an SBOM, and artifacts signed.
Your build system has more access than the services it deploys. It can reach staging, production, the artifact registry, and the cloud accounts underneath all three. Production cannot reach back.
That asymmetry is why CI/CD security best practices start with the pipeline itself, not the code moving through it. One compromised pipeline hands over signing keys, deploy credentials, and a trusted path into every environment at once. The controls below are ordered the way teams adopt them: this week's fixes, then the quarter's.
Why is CI/CD security a top attack surface?
Because the pipeline is where trust concentrates. It holds cloud credentials, registry tokens, and signing keys, and whatever it produces is trusted downstream by definition. Compromise a running service and you get that service. Compromise the pipeline and you get everything it deploys to, with a legitimate signature attached.
The OWASP Top 10 CI/CD Security Risks catalogs the result: over-permissioned identities, poisoned pipeline execution, and ungoverned dependencies. None of it requires a novel exploit, only a pipeline nobody scoped down.
AI widened the same surface without changing its shape. More code arrives from more places, faster than review absorbs it.
Among the teams using AI coding tools most frequently, 50% report more vulnerabilities or security incidents since adopting AI (Harness, State of DevOps Modernization 2026). Pipeline security decides whether that volume ships safely or just ships.
This concentrated trust is a massive liability when organizations rely on 'Open Execution Pipelines.' In an open model, what runs in your pipeline is determined by external references, mutable version tags, and unverified third-party code. As seen in the catastrophic TeamPCP attack on Trivy in March 2026, an open execution model allows threat actors to compromise the CI/CD supply chain and deploy malicious credential-harvesting code directly into victims' pipelines.
What belongs on a CI/CD security best practices checklist?
Six controls cover most of the risk: secrets, access, dependencies, artifact integrity, runners, and audit evidence. Start with the scanners you already own, because most teams pay for more than they run. What separates a checklist people use from one that sits in a wiki is sequencing: some items take an afternoon, some take a quarter, and pretending otherwise is how backlogs stall.
Which quick wins can you ship this week?
- Get secrets out of pipeline config. Move every credential into a managed secret store, inject at runtime, and rotate anything ever committed. It lives in the git history whether or not it sits in the current file.
- Minimize the use of third-party actions. Switch to built-in steps wherever possible to reduce your exposure to supply chain attacks through compromised plugins or actions.
- Pin third-party actions to a commit SHA. A tag can be moved by whoever owns the repo. This structural vulnerability that allowed the TeamPCP attackers to force-push malicious code to 76 of 77 version tags of the Trivy action in 2026. A SHA cannot be altered. This one change closes the most common path into a build.
- Protect the pipeline definition like production code. A pipeline anyone can edit without approval is an unreviewed deploy path.
- Scope one runner to one environment. Stop letting one build agent hold credentials for staging and production at once. Delegates with limited reach limit the risk of escalating attacks.
Which structural fixes belong on the quarter's plan?
- Generate and attest an SBOM on every build. A release-time inventory is the only reliable answer when the next registry compromise lands. Harness generates SBOMs for artifacts as a pipeline step.
- Sign commits and artifacts, then verify before deploy. Provenance proves a binary came from your build and not somewhere else. Sigstore has made signing close to free.
- Keep audit evidence in one place. A SOC 2 audit asks for exactly this, and assembling it by hand from six systems months later is expensive.
Which pipeline security misconfigurations show up most often?
Almost none of this starts with a sophisticated attack. It starts with a default nobody changed.
Hardcoded credentials in pipeline config. A token gets pasted into a YAML file to unblock a Friday build, the build works, and the token stays. Now it lives in every clone and fork. Rotating it is the fix; scanning every commit stops the next one.
Over-broad IAM roles on build agents. Build roles get provisioned wide because narrowing them breaks pipelines while you tune, leaving an agent that can read every bucket in the account. Scope from what the pipeline used last month, not from what someone requested at setup.
Unpinned dependencies and unverified third-party actions. A workflow that pulls an action at a floating tag runs whatever that tag points to today, a mechanism behind several recent registry compromises. Third-party code carries risk before anyone attacks it: 87% of scanned codebases contain at least one vulnerability (Black Duck, Open Source Security and Risk Analysis 2026). OpenSSF Scorecard checks for pinned dependencies automatically. When floating tags are hijacked in an open execution pipeline, attackers deploy purpose-built payloads to scrape process memory for decrypted secrets, sweep filesystems for .kube/config and .env files, and harvest Cloud Metadata (IMDS) to pivot from a simple build job to full IAM role access
Each was a convenience that made sense in isolation and became a risk once nobody revisited it. Pipeline security is a review problem before it is a tooling problem.
How do you roll out a secure CI/CD pipeline without slowing teams down?
In three moves: visibility, then policy, then enforcement.
Visibility first. Run every scanner in report-only mode across all pipelines. Nothing blocks, and within two weeks you know your real finding rate instead of guessing at it. It is also when you find the noise, because a control that cries wolf gets switched off by the third sprint.
Policy second. Write the rules as code and run them in warning mode against live pipelines. Teams see what would have failed, and why, with time to fix it.
Enforcement last, and narrow. Block on critical severity only, with a documented exception path and a named approver. Skipping ahead to this step is what earns security a reputation for blocking releases.
51% of organizations have automated their coding workflows, but only 43% have automated their CI and build pipelines (Harness, State of AI in Software Engineering 2025). A secure CI/CD pipeline has to account for the manual steps still in the middle.
How Harness approaches CI/CD security
Harness starts with an emphasis on governed pipelines and providing steps (actions) as out-of-the-box capabilities rather than relying on third-party providers. The intent is to reduce the likelihood of compromise by default and further reduce the blast radius of any compromise that may occur. This layered defense of the pipeline infrastructure itself is critical.
When we turn our attention to securing your code, it’s important to recognize that most teams do not lack scanners. They lack a way to reconcile what those scanners find across the whole delivery lifecycle: build, test, secure, deploy, and operate. Four tools report one vulnerability four ways, severity ratings disagree, and policy sits in a document nobody opens during a release.
Security Testing Orchestration runs commercial and open source scanners as pipeline steps, then normalizes and deduplicates the results so one issue reads as one issue. Supply chain security handles SBOM generation, attestation, and SLSA provenance. Policy runs as code through OPA across every pipeline rather than per team, RBAC scopes who can change what, and a platform audit trail records it for the next audit.
Triage stops being a cross-reference of four dashboards. Teams get one prioritized list, policy that applies the same way on every pipeline, and a record of named exceptions. The work shifts from arguing about which alerts are real to fixing them.
How regulated teams enforce DevOps security best practices at scale
How did Deluxe stop teams from bypassing security scans?
Deluxe put scanning behind centralized policy so no team could route around it. Its pipelines flag vulnerabilities early and block builds until critical issues are addressed, and reusable templates stand up a compliant pipeline in under 30 minutes.
"For every check-in, we invoke the pipeline so that security scans flag any high or critical severity issue. Our centralized policies ensure no team can bypass it."
Vikas Mehta, Enterprise Architect Principal, Deluxe
Source: Deluxe case study
How did Citi cut release times from days to seven minutes?
Consistently enforcing standard controls is the binding constraint in regulated finance. Citi transformed delivery for 20,000 engineers and brought release times down from days to seven minutes, using templates and policy to keep pipeline design flexible without letting standards drift.
"Harness CD's template system and OPA framework lets us give application teams the flexibility to design CD pipelines in a way that fits the requirements of the businesses they serve while being sure they are following all required and recommended practices. It lets users enforce policy and promote standardisation without restricting what engineers can achieve."
Michael Freeman, lead software engineer for the platform, Citi
Source: Citi case study
Closing the gap between what your pipeline can reach and what it should
Your pipeline will always touch more than any service it deploys, because that is the job. What changes is how much of that reach is deliberate, scoped, and written down where an auditor can read it.
Start with credentials and pinned dependencies this week, and put SBOMs, signing, and policy on the quarter's plan. Keep the list somewhere your team revisits, because CI/CD security best practices decay the moment a new default goes unreviewed. To run these controls in one place, book a demo.
