DevSecOps tools expose the identity gap in code-to-cloud security

At a glance

What this is: Cycode argues that DevSecOps tooling now spans code, cloud, and secrets controls, but the real gap is governed identity inside CI/CD workflows.

Why it matters: This matters because IAM, NHI, and PAM teams need to treat pipeline tokens, service accounts, and secrets as first-class controls, not hidden implementation details.

By the numbers:

• The worldwide DevSecOps market size is anticipated to reach USD 26.21 billion by 2032, growing at a CAGR of 14.6%.
• Cycode says left-shifted methods can reduce mean time to remediation of vulnerabilities by up to 85%.

Context

DevSecOps is the practice of embedding security checks into the software delivery lifecycle so teams can detect weaknesses before release. In this article, the governance problem is not whether tools exist, but whether the identities, tokens, and permissions used by pipelines, scanners, and automation are actually controlled as part of the security model.

Cycode frames the issue around code-to-cloud security, where scanning, posture management, and secrets handling are stitched together across development workflows. That framing is useful because CI/CD security often fails at the identity layer first, especially where service credentials and access scope are treated as temporary plumbing rather than governed non-human identities.

Key questions

Q: Why do DevSecOps pipelines create identity risk if access is not tightly scoped?

A: Because delivery systems rely on accounts and tokens that can approve, modify, and push changes without human involvement. If those privileges persist or overlap, a compromise in one stage can cascade into the next. The risk is not just code tampering, but trust propagation across build, release, and production systems.

Q: Why do pipeline secrets create such high downstream risk?

A: Pipeline secrets are effective because they are already trusted by deployment systems, cloud providers, and registries. When attackers capture them, they bypass authentication rather than cracking it. This is especially dangerous when secrets are long-lived or duplicated across environments, because one compromise can expose many systems at once.

Q: What are the signs that CI/CD security controls are not working well enough?

A: Common warning signs include secrets appearing in code or adjacent collaboration tools, policy violations that remain unresolved, weak visibility across the pipeline, and scanners that miss misconfigurations until late. If teams rely on manual review, struggle to trace findings back to owners, or cannot prioritize issues by impact, the control set is probably too fragmented to be effective.

Q: How do security teams decide which DevSecOps control to prioritise first?

A: Prioritise the control that prevents the most common and most damaging failure in your delivery flow. For many teams that means secrets detection, dependency governance, or CI gating before more advanced automation. The right first move is the one that reduces exposure while still fitting developer workflow and ownership.

Technical breakdown

Why CI/CD pipelines become identity systems

A modern CI/CD pipeline is not just a build path. It is an execution environment that authenticates humans, service accounts, bots, scanners, cloud providers, and deployment tools to one another. That means the pipeline has its own identity plane, with secrets, tokens, certificates, and permissions deciding what each step can reach. When teams focus only on code scanning or IaC scanning, they miss the fact that the pipeline itself is a privileged actor capable of writing to repositories, pulling packages, deploying workloads, and exposing secrets. In practice, the attack surface is often the trust boundary between jobs, runners, and external integrations.

Practical implication: Treat pipeline authentication and authorization as a governed identity domain, not a DevOps implementation detail.

How secrets management reduces exposure but not trust abuse

Secrets management systems lower exposure by storing credentials centrally, encrypting them, and rotating them automatically. That solves part of the problem, but it does not remove the trust relationship that allows a workflow to request and use a secret in the first place. If a pipeline job is over-scoped, compromised, or reused across environments, the secret is still reachable through legitimate access paths. The harder issue is lifecycle control: who can mint the credential, where it can be used, how long it remains valid, and whether it is bound to a specific workload or environment. Without those controls, secret management becomes storage hygiene rather than access governance.

Practical implication: Pair secret vaulting with strict issuance scope, environment binding, and rotation governance.

Why code-to-cloud visibility needs privilege context

Code-to-cloud platforms try to correlate source, dependencies, pipelines, and cloud resources so teams can prioritise what matters most. That correlation is useful only when privilege context is attached to the finding. A low-severity code issue can become critical if the vulnerable component sits in a pipeline with cloud deployment rights, while a noisy code finding may be less urgent if it cannot touch production assets. The key mechanism is blast-radius analysis, where access scope, ownership, runtime exposure, and deployment reach determine business risk. This is why the identity layer is central: privilege makes the difference between a code defect and an exploitable path.

Practical implication: Prioritise findings by access scope and deployment reach, not by scanner output alone.

Threat narrative

Attacker objective: The attacker wants to turn trusted DevOps automation into a conduit for secret theft, code tampering, or downstream production compromise.

1. Entry typically begins when an exposed secret, bot token, or over-permissioned service account is reachable through a development workflow or pipeline integration.
2. Credential access then allows the attacker to invoke trusted automation, read repositories, or alter build and deployment steps as if they were a legitimate pipeline principal.
3. Escalation occurs when the compromised identity can reach cloud resources, production secrets, or privileged CI/CD functions that expand the blast radius.
4. Impact is achieved through code theft, secret exfiltration, poisoned builds, or unauthorized deployment activity that undermines software supply chain integrity.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

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 is becoming an identity control plane, not just a delivery pipeline. Once build systems authenticate to clouds, repositories, scanners, and deployment targets, the real control surface is who and what is allowed to act inside the workflow. Security programmes that stop at code quality or vulnerability scanning are missing the governance layer that determines whether automation can be trusted at all. Practitioners should manage pipeline identities with the same discipline they apply to privileged human access.

Secrets management remains necessary, but it is not sufficient. Central storage and rotation reduce exposure, yet the article's own examples and tooling discussion show that access scope still decides exploitability. A secret that can be fetched by too many jobs, reused across environments, or embedded in shared automation is still an access problem, not merely a storage problem. Teams need lifecycle governance, not just vaulting.

Code-to-cloud security needs privilege-aware prioritisation. The most important gap is not finding every issue, but understanding which identity paths can turn a code issue into production impact. That makes blast-radius analysis, workload scoping, and environment separation core governance requirements. The practitioner conclusion is simple: risk scoring is incomplete until identity context is part of the scoring model.

DevSecOps and NHI governance are converging around the same failure mode. Pipeline tokens, build credentials, and deployment service accounts are non-human identities, even when teams do not label them that way. The governance problem is the same as in broader NHI programmes: inventory, ownership, privilege scope, and revocation all matter more than tool count. Security leaders should stop treating CI/CD credentials as temporary implementation details and start treating them as managed identities.

Continuous compliance only works when controls are machine-readable. The article points to SSDF, SOC 2, and ISO alignment, but the operational lesson is that audit evidence is strongest when identity controls are embedded in the pipeline itself. That means proofs of rotation, access limitation, and segregation of duties should be generated from the workflow, not reconstructed after the fact. Practitioners should design compliance evidence around control telemetry, not manual collection.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity governance is now part of DevSecOps architecture. Once pipelines, scanners, and deployment systems exchange credentials, access reviews must cover service accounts and automation roles alongside human users. The practical change for teams is that CI/CD identity inventory and revocation discipline become release controls, not back-office hygiene.

Secret leakage remains the easiest path from developer workflow to production compromise. The article's developer-behaviour gap aligns with a broader control problem: if developers do not consistently follow secrets practices, the pipeline will continue to accumulate reusable credentials in places that are hard to govern. Security leaders should treat secret exposure as a workflow design flaw, not only a user training issue.

Blast-radius control is the decisive metric for code-to-cloud security. When tools can correlate code ownership, runtime exposure, and cloud reach, the question stops being whether a vulnerability exists and becomes whether the attached identity can make it dangerous. Teams should measure whether pipeline credentials can cross environment boundaries, not just whether they are stored in a vault.

For practitioners

• Map every pipeline principal Inventory service accounts, bot tokens, deployment roles, and integration credentials used across build, test, and release stages, then assign a business owner and environment scope to each one.
• Bind secrets to workload context Use environment-specific credentials, short-lived tokens, and workload-bound permissions so a secret issued for one job cannot be reused by another pipeline or cloud target.
• Audit CI/CD privilege paths Review which jobs can read secrets, trigger deployments, modify workflow definitions, or write to cloud resources, then remove access that is not needed for the exact task.
• Prioritise findings by blast radius Combine scanner output with ownership, deployment reach, and runtime exposure so issues in privileged pipelines outrank low-impact code findings.
• Generate compliance evidence from the pipeline Capture rotation events, access approvals, and segregation checks directly from CI/CD telemetry so audit evidence reflects how controls actually operated.

Key takeaways

• DevSecOps tooling reduces friction across scanning, posture management, and secrets handling, but the underlying security problem is still who or what can act inside the pipeline.
• The most important control gap is not visibility alone. It is whether machine identities in CI/CD have bounded scope, short-lived access, and clear ownership.
• Practitioners should evaluate DevSecOps programmes by blast radius, because the same code flaw becomes far more dangerous when a pipeline identity can reach production and secrets.

Key terms

• DevSecOps: A software development approach that integrates security practices, including NHI governance, secrets scanning, and secure credential handling, throughout the CI/CD pipeline rather than treating security as a post-deployment activity.
• CI/CD Identity: CI/CD identity is the set of credentials and permissions used by build, test, and deployment systems to act in software delivery pipelines. It includes service accounts, tokens, keys, and certificates that let automation access code, artifacts, cloud resources, and deployment targets. Strong governance limits exposure, scope, and lifetime.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.

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. It helps security, IAM, and platform teams apply identity discipline to automation and release workflows.