How do you build a CI/CD pipeline you can trust?

A trusted CI/CD pipeline is one where you can say who can change it, what secrets and systems it can reach, and how you know the artifact it produced is the one you meant to ship. OWASP's Top 10 CI/CD Security Risks and the SLSA framework give you a concrete way to check each.

Why is the pipeline a target?

OWASP describes CI/CD systems as delivering code from an engineer's workstation to production, and says that adversaries have shifted attention to them because they offer an efficient path to an organization's crown jewels. The pipeline holds credentials, runs code from many sources and writes to production. Compromise it and you inherit all of that.

OWASP lists ten risks: insufficient flow control mechanisms, inadequate identity and access management, dependency chain abuse, poisoned pipeline execution, insufficient pipeline-based access controls, insufficient credential hygiene, insecure system configuration, ungoverned use of third-party services, improper artifact integrity validation, and insufficient logging and visibility.

Rather than walk the list, group it by three questions.

Who can change the pipeline?

Poisoned pipeline execution (CICD-SEC-4) is the case where someone with access to source control, but not the build environment, injects commands into the pipeline configuration and makes the build run them. OWASP's mitigations include running pipelines that execute unreviewed code on isolated nodes without secrets, being careful about pipelines triggered from forks or external contributors, requiring manual approval where needed, pairing each branch that triggers a sensitive pipeline with a branch protection rule, and reviewing the CI configuration file before the pipeline runs, or keeping it in a separate protected branch.

Constructed example: an outside contributor opens a pull request that edits the workflow file to print environment variables to the log. If the pipeline runs on that pull request with production secrets in scope, the secrets are gone before anyone reviews the diff. The fix is structural: untrusted code runs where no secrets exist.

What can the pipeline reach?

Identity (CICD-SEC-2) and credential hygiene (CICD-SEC-6) are about reach. OWASP recommends mapping every identity across the engineering systems with the permissions granted and the permissions actually used, removing what is unnecessary, centralizing identities in an identity provider instead of local accounts, disabling stale accounts, and giving permissions an expiry where possible. For credentials: give each set the least privilege it needs, avoid sharing across contexts, prefer temporary credentials over static ones, rotate static ones, limit use to predetermined conditions such as a source IP or identity, and scan for secrets in code, including with an IDE plugin and scans of past commits.

Dependencies (CICD-SEC-3) belong here too: what the pipeline pulls in is what it runs.

What does the pipeline ship?

Improper artifact integrity validation (CICD-SEC-9) lets an attacker with a foothold ship a malicious artifact that looks benign. OWASP recommends validating integrity from development to production: sign resources when generated and verify before the next step consumes them, use commit signing, use artifact signing and verification tooling, and detect configuration drift.

SLSA turns this into levels for the build track. Level 1 means provenance exists showing how the package was built. Level 2 means signed provenance generated by a hosted build platform, which protects against tampering after the build. Level 3 means a hardened build platform that protects against tampering during the build. SLSA says provenance describes what entity built the artifact, what process they used and what the inputs were.

Logging closes the loop (CICD-SEC-10). If you cannot reconstruct who ran what, you cannot investigate.

How to check or apply this

1. Draw the pipeline from commit to production, and mark every place a secret or deploy permission appears.
2. Split untrusted from trusted work: pull requests from forks and unreviewed branches run with no secrets, on isolated runners.
3. Require review for changes to pipeline configuration.
4. Replace long-lived credentials with short-lived ones, each scoped to one job.
5. Inventory every identity that touches the pipeline, human and machine, and remove unused ones.
6. Generate provenance and sign artifacts. Verify signatures before deploy.
7. Send pipeline and source control logs somewhere an attacker with runner access cannot edit.
8. Test a malicious pull request on a copy of your pipeline, and see what it can reach.

Quick check

Sources

• OWASP Top 10 CI/CD Security Risks
• OWASP CICD-SEC-2: Inadequate Identity and Access Management
• OWASP CICD-SEC-4: Poisoned Pipeline Execution
• OWASP CICD-SEC-6: Insufficient Credential Hygiene
• OWASP CICD-SEC-9: Improper Artifact Integrity Validation
• SLSA specification v1.0: levels

Last reviewed: 18 October 2026.