CI/CD pipeline security best practices for verified code integrity

At a glance

What this is: This is a practitioner-focused analysis of CI/CD pipeline security that argues identity, device trust, and code integrity must be enforced throughout development.

Why it matters: It matters to IAM and NHI practitioners because developer accounts, service identities, and automated build systems all become part of the trust boundary in modern software delivery.

👉 Read Beyond Identity's blog on CI/CD pipeline security best practices

Context

CI/CD pipeline security is the problem of protecting code, credentials, and build integrity across the software delivery chain. In modern DevOps environments, the control gap is not just in production access but in the identities, devices, and automation that can alter code before it ships. That makes CI/CD a direct NHI governance concern, because bots, build systems, signing keys, and service accounts all influence the final trust outcome.

The article frames this as a security gap created by speed and automation, and that framing is accurate. Teams that treat pipeline controls as a late-stage compliance check are already behind, because the attack surface begins when code is committed and continues through build, test, signing, and deployment. For teams looking to anchor this work in broader NHI practice, the Ultimate Guide to NHIs is the clearest baseline reference.

Key questions

Q: How should teams secure CI/CD pipelines against identity-based attacks?

A: Teams should secure CI/CD pipelines by treating every developer account, service account, build runner, and signing key as a governed identity with explicit scope. That means least privilege, verified commit provenance, managed-device checks, and continuous integrity validation across build and release stages, not just final approval.

Q: Why is commit identity important in software supply chain security?

A: Commit identity matters because it binds a change to a verified principal and reduces the chance that unauthorized code enters the pipeline under a trusted account. It is not sufficient by itself, but it creates accountability and supports provenance controls that can stop malicious changes earlier.

Q: What is the difference between code signing and code provenance?

A: Code signing proves an artifact was signed by a key, while code provenance explains who changed the code, from where, and under what controls before signing. Provenance is stronger for supply chain defense because it helps detect tampering earlier in the pipeline, not only at the end.

Q: When does device trust matter for CI/CD access decisions?

A: Device trust matters whenever a person or automation can write code, approve changes, or access secrets from endpoints that can influence the pipeline. If the device is unmanaged or compromised, the identity behind it may still be legitimate, but the access path is no longer trustworthy.

Technical breakdown

Why CI/CD pipelines become an identity problem

CI/CD pipelines are not just engineering workflows. They are identity-rich control planes where developers, service accounts, build runners, signing keys, and automated approvals can all change software state. When those identities are weakly governed, the pipeline can accept code from a legitimate account that should not have had that level of access. The failure mode is not always theft of a password. It is often trusted execution by the wrong principal, which is why NHI controls matter as much as source code review.

Practical implication: map every non-human identity in the pipeline and classify which ones can write, approve, sign, or deploy.

How device trust affects code repository access

Device-based access control adds a second dimension to identity verification. A user may be legitimate, but if the access occurs from an unmanaged or compromised device, the risk to source code and build artifacts rises sharply. In DevOps, that matters because developers often clone repositories, sign commits, or access secrets from endpoints that are outside traditional corporate control. Device posture, corporate identity, and repository authorization need to be evaluated together, not separately.

Practical implication: require managed-device checks before granting repository write access or access to protected build actions.

Source code integrity and tamper detection in the pipeline

Integrity protection must cover the full lifecycle, not only the final release artifact. If an attacker can modify source, dependencies, build definitions, or signing inputs before the last checkpoint, a signed release can still be malicious. That is the core lesson of modern supply chain attacks: the trust decision happened too early, or too narrowly. Verified commit identity, dependency integrity, and change provenance are the technical controls that reduce this risk.

Practical implication: verify provenance at commit, dependency, and release stages instead of relying on final-stage signing alone.

Threat narrative

Attacker objective: The attacker wants to inject malicious code into a trusted software release and use the organization’s own signing and delivery process to spread it.

1. Entry occurs when an attacker or insider reaches a development pipeline through a trusted repository, build system, or weakly controlled identity.
2. Escalation happens when that principal can alter source code, dependencies, or build logic without triggering integrity checks before release.
3. Impact follows when a malicious but signed update is distributed downstream as trusted software.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD pipeline security is now NHI governance, not just DevOps hygiene. Every automated build step depends on identities, tokens, keys, and approvals that behave like non-human identities. If those principals are not governed, the pipeline becomes a privilege amplification system for attackers. Practitioners should treat CI/CD controls as part of the identity program, not a separate engineering concern.

Identity binding at commit time is the minimum viable control, not the end state. Tying commits to verified identities helps, but it does not solve dependency poisoning, build runner compromise, or signing key abuse. That is why pipeline security has to extend into runtime provenance, not stop at authentication. The right control model is end-to-end assurance, and teams should design for that now.

Device trust is an overlooked enforcement point in software supply chain risk. If source code can be copied, changed, or reviewed from unmanaged endpoints, access control is weaker than most teams assume. Device posture is part of the trust decision for repositories, secrets, and release workflows. Practitioners should align endpoint policy with code access policy or accept a permanently widened attack surface.

Supply chain attacks expose an identity blast radius that many organisations still underestimate. Once a build or signing identity is compromised, the attacker may inherit the organisation’s trust chain rather than having to evade it. That changes the security question from whether code is signed to whether the right entity was allowed to sign it in the first place. Teams should design controls around provenance, least privilege, and short-lived access.

Verified identity only works when paired with continuous integrity checks. Authentication without change detection creates a false sense of safety, especially in fast-moving pipelines. The practical standard is to verify who changed what, from where, and under which device posture before code advances. Practitioners should use identity as one layer inside a broader provenance model, not as a substitute for it.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Guide to the Secret Sprawl Challenge shows how secret sprawl becomes a pipeline problem long before production exposure.

What this signals

Secret sprawl is the practical marker that CI/CD governance is failing. When secrets live in code, config, and automation paths, the security team cannot assume the pipeline is controlled simply because it is automated. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, the operating assumption should be that exposure is already present.

Identity governance for pipelines will increasingly converge with Zero Trust Architecture. The issue is not whether a commit was authenticated once. It is whether the principal, device, workflow, and artifact remain trustworthy as the change moves forward. Teams that already use NIST Cybersecurity Framework 2.0 should map CI/CD controls to govern, protect, detect, and respond functions rather than treating build security as a niche engineering problem.

For practitioners

• Inventory pipeline identities and privileges Map developers, service accounts, build runners, signing roles, and automation tokens across every repository and environment. Remove broad write access, separate approval from execution, and document which non-human identities can change production-bound code.
• Enforce managed-device access for source control Require corporate device posture before allowing repository write access, secret retrieval, or protected branch changes. Pair endpoint checks with conditional access so untrusted machines cannot participate in high-risk code paths.
• Verify commit provenance before release Require signed commits from verified identities and check provenance again at build and release time. Do not rely on a single final signing step, because attackers often compromise the chain earlier than the last gate.
• Protect build secrets and signing keys as NHI assets Store pipeline secrets in controlled systems, rotate them on a schedule, and revoke them quickly when workflows change. Treat signing keys as high-value NHI credentials with monitoring, scope limits, and access review.
• Add integrity monitoring for dependencies and build logic Detect unexpected changes to dependencies, build definitions, and release scripts before deployment. Focus on tamper evidence, because a clean authentication event does not guarantee the artifact remained unchanged.

Key takeaways

• CI/CD security fails when teams treat automation as proof of trust instead of a control path that needs identity governance.
• The main risk is not just malicious code, but trusted code changing hands through weakly governed identities and devices.
• Practitioners should enforce provenance, endpoint trust, and secret control together or accept a persistent supply chain exposure.

Key terms

• CI/CD Pipeline Identity: The collection of human and non-human identities that can change code, trigger builds, approve releases, or sign artifacts in a delivery pipeline. In practice, these identities define who or what can influence software before it reaches production, making them a core governance boundary.
• Code Provenance: Code provenance is the record of who changed software, what changed, where it changed, and which controls were in place before release. It extends beyond signature validation by linking software artifacts to trusted identities, devices, and workflows across the development chain.
• Identity Blast Radius: Identity blast radius describes how far an attacker can move once a single identity is compromised. In CI/CD environments, a compromised token or signing key can affect repositories, build systems, and downstream releases, so the blast radius can be much larger than the initial foothold.
• Secret Sprawl: Secret sprawl is the uncontrolled distribution of credentials across code, configuration files, build systems, chat tools, and other operational surfaces. It creates hidden exposure because secrets become harder to inventory, rotate, and revoke, especially in fast-moving CI/CD environments.

Deepen your knowledge

CI/CD pipeline identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising controls for build systems, signing keys, and automation identities, it is worth exploring.

This post draws on content published by Beyond Identity: CI/CD Pipeline Security Best Practices. Read the original.