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

At a glance

What this is: This is a CI/CD security checklist focused on securing access, secrets, build integrity, testing, deployment, and logging across the software delivery pipeline.

Why it matters: It matters to IAM, PAM, and security teams because CI/CD pipelines increasingly depend on human and non-human identities, short-lived tokens, and least-privilege access that can be abused if lifecycle and authorization controls are weak.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Appknox's CI/CD security checklist for engineering managers

Context

CI/CD security is no longer just a build hygiene issue. In modern delivery pipelines, access tokens, service accounts, runners, and deployment credentials can all become pathways from code change to production impact, especially when identity and secrets governance is inconsistent.

The article's core concern is that speed pressures often outrun control design, leaving exposed secrets, weak branch protection, and broad deployment access as routine risk factors. For identity teams, the intersection is clear: CI/CD pipelines rely on non-human identities and privileged automation, so lifecycle, rotation, and least-privilege controls matter as much here as they do in cloud or IAM programmes.

This is a typical enterprise pattern rather than an edge case. The controls named in the checklist reflect the most common failure modes in software delivery environments, where convenience often outranks durable identity governance.

Key questions

Q: How should security teams implement CI/CD security without slowing delivery down?

A: Build security into the pipeline itself instead of adding late-stage manual gates. Enforce branch protection, secrets management, dependency scanning, and deployment approval in automated workflows so developers get fast feedback and risky changes are blocked before production. The goal is to reduce rework, not add friction after release windows are already committed.

Q: Why do exposed secrets in CI/CD pipelines create such a large blast radius?

A: CI/CD systems often hold cloud credentials, deployment tokens, and repository access in the same execution context. When malicious code runs there, it can collect secrets from environment variables, files, and process memory, then reuse them across cloud and source control. The more privileged the runner, the larger the downstream impact.

Q: What breaks when CI/CD runners are reused across jobs?

A: Reusable runners can retain tokens, cached dependencies, logs, and state from previous executions. That persistence creates a contamination risk because one compromised job may influence later jobs or leak material that should have been destroyed at the end of the build. Ephemeral runners reduce that blast radius by making each execution disposable.

Q: What should teams do when a CI/CD credential is exposed?

A: Revoke the token, validate the affected pipeline and artifact chain, and confirm whether the credential was used for deployment or build access. Then rotate any related secrets, review recent pipeline changes, and verify that protected environments and approvals still block unauthorized release activity.

Technical breakdown

How CI/CD identity trust breaks down in pipelines

CI/CD systems depend on identities that are rarely human but still act with high privilege. These include service accounts, runner credentials, OIDC tokens, and repository-integrated secrets. The security problem is not just theft of a secret, but the trust chain around it: if a pipeline credential can write code, trigger builds, or deploy artifacts, it becomes a production-grade identity. In practice, attackers exploit weak authentication, reused tokens, and stale permissions to move from source control into build and release systems. The control gap is lifecycle governance, not just secret storage.

Practical implication: treat CI/CD credentials as governed identities with ownership, expiry, and revocation, not static configuration values.

Why build-stage security needs dependency and runner isolation

The build stage is where untrusted code, third-party dependencies, and execution environments intersect. Software composition analysis, SBOM generation, and ephemeral runners reduce the chance that a malicious dependency or compromised job persists beyond a single execution. Persistent runners are especially risky because state, tokens, and artifacts can survive across jobs. That creates a cross-build contamination path that is hard to detect after the fact. SBOMs add traceability, but only if teams can connect them to artifact integrity and release provenance. The technical issue is not the scan itself, but whether build state is isolated enough to prevent reuse.

Practical implication: isolate runners, block risky dependencies, and make artifact provenance part of release approval.

How deployment permissions and OIDC change privilege exposure

Deployment is where CI/CD privilege becomes operationally dangerous. Long-lived cloud keys create standing access that can be replayed outside the pipeline, while OIDC-based short-lived credentials reduce that exposure window and bind access to the job context. Protected environments and manual approvals add policy checkpoints before production changes are allowed through. Least privilege matters here because deployment identities often accumulate broad permissions for convenience. The architecture works only when the deploy identity can do exactly one job, in one environment, for one session, and nothing else.

Practical implication: replace persistent deploy keys with short-lived job-based credentials and narrow environment-specific permissions.

NHI Mgmt Group analysis

CI/CD pipelines are now identity-bearing production systems, not just engineering tooling. The article correctly treats access, secrets, and deployment permissions as first-class security controls because these pipelines can ship code directly into production. That makes their service accounts, tokens, and runners part of the identity estate, even if they are managed by engineering teams rather than IAM teams. The governance implication is straightforward: if a pipeline can deploy, it needs the same lifecycle, audit, and privilege discipline as any other high-risk identity domain.

Secret sprawl is the defining CI/CD failure mode. The checklist repeatedly returns to secrets in code, environment variables, and pipeline files because that is where convenience turns into exposure. This is the same pattern NHIs expose across the enterprise: credentials are created for speed, then reused long after their original purpose. Secret sprawl: the accumulation of credentials across repositories, CI jobs, and automation layers without a coherent lifecycle model. Practitioners should treat sprawl reduction as a governance objective, not an implementation detail.

Short-lived credentials are necessary, but they do not solve governance on their own. Replacing static keys with OIDC-based access is a strong control move, yet it still depends on correct issuer trust, scoped claims, and environment enforcement. In other words, the access model improves only when identity policy and pipeline policy are aligned. For NHI and IAM teams, this is a reminder that token format matters less than the controls around issuance, validation, and revocation.

CI/CD security exposes the same lifecycle gap that weak NHI programmes already struggle with. The article's advice on removing inactive accounts, rotating credentials, and centralising logging aligns closely with the broader NHI problem: identities are created faster than they are retired. That is why pipeline security should be measured not just by scan coverage, but by how quickly teams can revoke, replace, and trace automation identities after a change. Practitioners should use CI/CD as a forcing function for stronger identity lifecycle governance.

What this signals

CI/CD security will increasingly be judged as an identity governance problem, not just a software delivery problem. As deployment automation expands, teams will need tighter ownership for service accounts, better token issuance policies, and more disciplined revocation paths when pipelines change.

Pipeline trust gap: the real issue is not whether a build passed, but whether the identities behind that build were scoped, observable, and disposable enough to withstand abuse. That is where stronger lifecycle control and evidence-based access review will matter most.

For teams aligning controls, the most useful external reference point is NIST Cybersecurity Framework 2.0, because CI/CD security spans governance, protection, detection, response, and recovery across the delivery chain.

For practitioners

• Harden pipeline identity controls Require MFA for source control, CI platforms, and artifact repositories, then apply RBAC to remove unused accounts and narrow who can change pipeline definitions. Map every build and deploy identity to an owner and review its permissions on a fixed schedule.
• Move secrets out of code paths Block repositories, YAML files, and plaintext environment variables from holding credentials, and force all privileged values into external secret managers. Add revocation and rotation steps so exposed secrets can be invalidated quickly across build and deploy workflows.
• Make build environments disposable Use ephemeral runners, prevent state persistence across jobs, and generate SBOMs for every build so a compromised job cannot contaminate later releases. Tie scan results to artifact provenance before promotion to production.
• Replace standing deploy access Use OIDC-based short-lived credentials for deployments, limit them to protected environments, and require manual approval for production changes. This reduces the replay value of deploy tokens and keeps privilege tied to the job session.
• Centralise pipeline telemetry Aggregate CI/CD logs, alert on pipeline configuration changes, runner updates, permission changes, and secret rotations, and keep a runbook for token revocation and artifact validation. Use those records to reconstruct who changed what and when.

Key takeaways

• CI/CD pipelines become security-critical when their credentials can reach production, because then identity control and release control are the same problem.
• The biggest practical failures are secret sprawl, runner persistence, and broad deploy access, all of which extend attacker dwell time and blast radius.
• Teams that want durable CI/CD security need disposable build environments, short-lived deploy credentials, and audit trails that support rapid revocation and reconstruction.

Key terms

• Continuous Integration And Continuous Delivery: Continuous integration and continuous delivery, or CI/CD, are automated software release practices that merge, test, and deploy changes frequently. They create speed and consistency, but also concentrate risk because the same pipelines often handle code, secrets, certificates, and production permissions.
• 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.
• Protected environment: A protected environment is a deployment target that requires extra governance, such as reviewer approval, before a workflow can act on it. It is a key control for CI/CD because it separates ordinary build execution from production release authority and makes access more accountable.

What's in the full article

Appknox's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step CI/CD checklist for access control, branch protection, and secrets handling across GitHub, GitLab, and Bitbucket.
• Concrete examples of SAST, DAST, and IaC scanning inside build pipelines, including tool choices and configuration patterns.
• Deployment-stage guidance on OIDC-based credentials, protected environments, and least-privilege permissions for production releases.
• Incident response steps for token revocation, pipeline shutdown, artifact validation, and post-incident rechecks.

👉 The full Appknox article includes pipeline examples, deployment controls, and incident response details for engineering teams.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is a practical fit for teams that need to govern automation identities across engineering and security programmes.