CI/CD security gaps are still exposing build secrets and deploy access

At a glance

What this is: Appknox says CI/CD pipelines are still exposing build secrets and deployment access because teams leave too much trust in secrets, runners, and release permissions.

Why it matters: This matters to IAM and NHI practitioners because CI/CD systems rely on machine identities, tokens, and short-lived deployment trust, so weak governance can turn source access into production compromise.

Context

CI/CD security is the problem of controlling who and what can change code, build artifacts, and deployment targets without widening the blast radius. In practice, that means access control, secrets handling, runner isolation, and release permissions have to work as one control surface, not as separate team checklists.

The identity angle is central because pipelines depend on service accounts, tokens, OIDC-based credentials, and privileged automation paths. When those controls are static, overly broad, or stored in the wrong place, the delivery system becomes an identity-security problem as much as an application-security one.

Key questions

Q: Why do security controls often fail in fast-moving CI/CD environments?

A: They usually fail because they arrive too late or ask for manual work at the point where teams are optimising for speed. If a control is hard to understand, slow to approve, or detached from the developer’s context, it will be bypassed, deferred, or applied inconsistently. Good controls reduce friction instead of adding it.

Q: Why do weak pipeline controls create production risk so quickly?

A: Because CI/CD systems concentrate privileged actions into a small number of automated jobs. If a runner, token, or deploy account is compromised, the attacker does not need to break application logic to cause damage. They can use the pipeline’s own authority to move malicious code, leak secrets, or push an unapproved release into production.

Q: What signs show that CI/CD identities are being overused?

A: Common signals include the same credential being reused across jobs, build machines retaining state between runs, secrets appearing in configuration files, and deploy permissions that are broader than the release task requires. Those patterns indicate that pipeline identity has become durable rather than task-scoped, which is where compromise becomes easier to repeat.

Q: How should teams balance delivery speed with pipeline security?

A: By moving controls earlier and automating them. Teams should verify access, secrets, dependencies, and artifact integrity during the build and pre-deploy stages so security checks do not depend on manual review after the fact. The goal is to make safe delivery the default path, not an extra approval layer added at the end.

Technical breakdown

Why CI/CD pipelines become a trust boundary

A CI/CD pipeline is not just a build tool. It is a chain of authenticated actions that moves code from source control into tested, signed, and deployed artifacts. The security issue is that every stage inherits trust from the previous stage, so a weak approval rule, leaked secret, or reused runner can propagate compromise forward. In identity terms, the pipeline acts like a machine-to-machine delegation system, which means the real control point is not the final deploy step but the authenticity and scope of each upstream credential and job execution context.

Practical implication: Treat the pipeline as a production trust boundary and govern each stage with explicit identity and permission checks.

Secrets, runners, and build artifacts as attack surfaces

Build systems expose three recurring failure points: secrets stored in code or logs, runners that persist state between jobs, and unsigned artifacts that are hard to verify later. Secrets leakage gives attackers immediate authentication material. Persistent runners can preserve malicious changes or residual tokens across builds. Unsigned artifacts weaken provenance because downstream deployment trusts something that was never cryptographically anchored. The technical pattern is familiar across software supply chain incidents: once an attacker controls the build environment or its credentials, the pipeline can become a distribution mechanism for compromise.

Practical implication: Minimise secret exposure, use ephemeral runners, and require artifact integrity checks before release.

Deployment permissions need identity-aware least privilege

Deployment security is about more than approval buttons. Production deploy jobs often have the broadest permissions in the pipeline, which makes them attractive targets if the job token, service account, or environment binding is abused. Identity-aware deployment means replacing long-lived cloud keys with short-lived credentials, constraining permissions to the exact release action, and separating build identities from deploy identities. That separation matters because a build system should not automatically inherit production authority just because it produced a package.

Practical implication: Separate build and deploy identities, and restrict production access to the minimum scope needed for release.

Threat narrative

Attacker objective: The attacker wants trusted pipeline access that can be turned into code execution, secret theft, or production compromise without having to attack the application directly.

1. Entry begins when attackers obtain source control access, a leaked token, or another foothold in the delivery workflow. Credential access then lets them reach build systems, CI runners, or deployment jobs that were never meant to expose production authority.
2. Escalation happens when those credentials are overprivileged, long-lived, or reusable across jobs, allowing the attacker to alter pipeline logic, read secrets, or poison dependencies and artifacts.
3. Impact follows when compromised pipelines publish malicious builds, leak deploy secrets, or push unauthorised changes into production systems and downstream environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD security is now identity security by another name: the pipeline only stays trustworthy when machine identities, secrets, and deployment permissions are continuously governed. Appknox’s checklist reinforces a basic reality that many teams still underweight, which is that build systems now hold production-grade authority. Practitioners should treat pipeline trust as an IAM and NHI governance problem, not just a developer workflow issue.

Standing pipeline credentials create a hidden persistence layer: when runners, service accounts, and deploy tokens live longer than the jobs they support, they become reusable attack paths. That is the same governance failure pattern seen in many NHI incidents, where access outlives the task it was meant to serve. The practical conclusion is simple: if a credential can be reused after the job ends, it is already too durable for modern delivery chains.

Secret sprawl in CI/CD is a control failure, not a housekeeping issue: storing credentials in repositories, YAML files, or plain environment variables turns convenience into exposure. This is a classic NHI-02 and NHI-07 problem in software delivery form, because the secret is both discoverable and persistent. Security teams should read that as a signal to move control to issuance time, not detection time.

Production deployment should be treated as a privileged workflow, not a routine build step: the broader market lesson is that delivery platforms are converging with privileged access control. That means engineering managers, IAM teams, and security architects need shared ownership of release identities, approval boundaries, and artifact trust. The organisations that will reduce risk fastest are the ones that stop allowing build success to imply production authority.

Delivery-chain blast radius: the article’s core concept is that compromise scales through the pipeline, not just inside the application. Once one credential, runner, or dependency is trusted too broadly, the effect is systemic rather than local. Practitioners should design controls that narrow the blast radius at each stage, especially where non-human identities can reach production systems.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Delivery-chain blast radius is the right concept for CI/CD governance: a weakness in one job or token can propagate through build, test, and release because the pipeline reuses trust across stages. That means the control model has to focus on how authority is issued, scoped, and revoked, not just on whether tests passed.

Pipeline security programmes should now be measured by how quickly they can eliminate standing secrets, reduce runner persistence, and constrain deploy permissions. If those three conditions are still present, the environment is still exposing production to machine identity risk even when the build dashboard looks healthy.

For practitioners

• Enforce MFA and RBAC across pipeline consoles Require MFA on source control, CI platforms, and artifact repositories, then remove inactive accounts and review role assignments against current delivery responsibilities.
• Move all pipeline secrets into external managers Keep credentials out of repositories, CI/CD YAML files, and plaintext environment variables, and issue them only through managed secret stores or short-lived identity flows.
• Use ephemeral runners for build isolation Avoid reusing build machines so each job starts from a clean state and cannot inherit tokens, cached material, or malicious residue from earlier runs.
• Separate build identities from deploy identities Grant production deploy jobs only the permissions required for release, then keep build jobs from inheriting cloud or infrastructure authority.
• Require integrity checks before promotion Sign artifacts, generate SBOMs, and gate release promotion on verification of the build output rather than on build completion alone.

Key takeaways

• CI/CD compromise is often an identity and secrets problem first, and a code problem second.
• The strongest controls reduce reuse by narrowing credential scope, runner persistence, and deploy authority.
• Teams that move verification earlier in the pipeline shrink the blast radius before malicious changes can reach production.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• Ephemeral Runner: A disposable build executor that exists only for a single job or short-lived task. Ephemeral runners reduce the chance that credentials, state, or malicious changes persist across builds, which makes them a key control for pipeline isolation and supply chain resilience.
• Developer Token: A developer token is a reusable secret that authorises access to code registries, publishing systems, or automation pipelines. In security terms, it behaves like a non-human identity because it can carry scope, privilege, and persistence across machines and workflows.
• Artifact Integrity Check: An artifact integrity check compares an image’s expected fingerprint with the actual file or layer hash observed in the environment. The goal is to detect tampering, replacement, or unexpected modification before trust is assigned. In cloud security, integrity validation is a core control for unverified public images and other deployed artifacts.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and engineering teams align delivery workflows with identity controls that reduce pipeline risk.