DevOps vs devsecops in the IaC era: what changes for identity

At a glance

What this is: This is a ControlMonkey analysis of how IaC changes the DevOps versus DevSecOps split by making identity, secrets, drift and policy part of the delivery model.

Why it matters: It matters because IAM, PAM and NHI controls increasingly have to operate inside automated delivery pipelines rather than as separate manual checkpoints.

Context

Infrastructure-as-Code changes the control point for identity governance because access, secrets and environment state are defined in code rather than assembled by hand. That makes delivery faster, but it also means identity controls must be embedded in the same automation that builds and changes the cloud environment.

The DevOps versus DevSecOps distinction in this article is less about organisational labels and more about whether security, compliance and drift detection are codified into the workflow. In practice, that shifts IAM and NHI governance from periodic review to continuous enforcement within the pipeline.

For identity teams, the key question is not whether DevOps or DevSecOps is the better operating model. It is how to keep machine access, secrets and policy aligned when infrastructure changes at code speed.

Key questions

Q: What breaks when access control is kept outside IaC pipelines?

A: Access control becomes disconnected from the system that actually changes cloud state, so permissions, secrets and policy can drift apart from the deployed environment. The result is slower review, weaker traceability and more unmanaged exceptions. For identity teams, the failure is structural: manual governance cannot keep up with code-driven change at delivery speed.

Q: Why do CI/CD pipelines create non-human identity risk?

A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

Q: How can organisations tell whether DevSecOps controls are actually working?

A: Look for fewer late-stage exceptions, faster remediation of found issues, and clear ownership for secrets, certificates, and pipeline permissions. If the team still depends on manual approvals or emergency fixes before deployment, security is still reactive. Effective DevSecOps produces traceable controls that keep pace with release frequency.

Q: What is the difference between DevOps and DevSecOps for identity governance?

A: DevOps focuses on speed, repeatability and deployment quality, while DevSecOps adds security, compliance and policy enforcement into the same automation. For identity governance, that means DevSecOps treats access, secrets and drift as part of the delivery design rather than separate review steps. The practical difference is where the control lives: in workflow code, not only in oversight.

Technical breakdown

How IaC changes access governance in delivery pipelines

Infrastructure-as-Code turns cloud configuration into versioned code, which means access patterns, environment settings and deployment behaviour can be reviewed before they are executed. In a DevOps model, that primarily supports speed and repeatability. In a DevSecOps model, the same code path is also used to enforce policy, validate compliance and flag risky changes before deployment. The governance implication is that access to deploy, modify and promote infrastructure becomes a machine-mediated control surface, not just a human approval process.

Practical implication: Treat pipeline permissions, deployment roles and template changes as governed identity surfaces, not engineering convenience.

Why secrets and machine credentials become delivery controls

When infrastructure is provisioned through code, the pipeline needs credentials, tokens and access scopes to act on behalf of teams and services. That makes secrets management part of the delivery system itself. If those secrets are reused, overly broad or embedded in tooling workflows, the deployment process becomes a trust boundary with weak accountability. DevSecOps adds policy checks and compliance gates, but those controls only work when the machine identities used by the pipeline are explicitly governed across creation, use and revocation.

Practical implication: Inventory every deployment credential and align its scope, lifecycle and revocation path with the pipeline it serves.

How drift detection exposes identity and configuration divergence

Drift detection compares the declared IaC state with the actual deployed environment and flags divergence. In identity terms, drift can reveal changed permissions, unmanaged resources or policy exceptions that were introduced outside the code path. That matters because the article’s DevSecOps model assumes security and compliance stay attached to the same source of truth as delivery. Once infrastructure drifts, the organisation no longer has a reliable link between intended control and actual runtime state.

Practical implication: Use drift detection not only for infrastructure changes but also for permission and policy divergence in managed environments.

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

IaC turns identity governance into a deployment problem: when the environment is created and changed through code, the boundary between infrastructure management and access governance disappears. That does not make identity less important, it makes it operational. Teams that keep IAM, secrets and policy outside the delivery workflow will miss the moment when the control state changes. The practitioner implication is that identity governance has to move into the same release system that changes the cloud estate.

DevSecOps is the point where compliance becomes executable: the article shows that security is no longer a review layer after development, but an automated condition inside the pipeline. That matters because policy-as-code only works if the policy is attached to the same artefact that provisions access and infrastructure. Manual exceptions can still exist, but they become exceptions to a codified baseline rather than the baseline itself. Practitioners should expect compliance evidence to come from automation, not separate attestations.

Identity blast radius is now defined by pipeline scope: once build and deployment tooling can change infrastructure, the permissions assigned to those workflows determine how far a compromise or mistake can spread. The important question is no longer only who can log in, but which workflow can create, alter or destroy cloud state. That makes least privilege a delivery design requirement, not a downstream audit control. Identity teams should map every automation path to its maximum possible change authority.

Managed and unmanaged IaC is a governance fault line: the article’s emphasis on what is managed versus unmanaged through IaC points to a structural gap in cloud control. Anything outside the codified path escapes the policy checks, drift monitoring and compliance logic that DevSecOps depends on. That is not just a tooling issue, it is a governance boundary. The practitioner implication is to treat unmanaged change as a control failure, not an acceptable shortcut.

Secrets management best practice is the centre of the developer behaviour gap: only 44% of developers are reported to follow security best practices for secrets management, which means delivery automation still depends on uneven human behaviour. That gap is not solved by better intent; it is solved by removing avoidable secret handling from manual workflows. The practical conclusion is to assume secrets discipline is inconsistent unless it is enforced by the pipeline itself.

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

IaC makes delivery pipelines the new control plane for identity, which means the mature operating model is no longer separate review but embedded governance. Teams that still rely on manual checkpoints will struggle to keep access, secrets and policy in sync with cloud change.

Managed IaC boundary: the split between managed and unmanaged infrastructure is becoming a governance line, not a tooling preference. Anything outside the codified path bypasses drift detection and policy enforcement, so identity teams should treat unmanaged change as an exception that needs explicit scrutiny.

Secrets handling remains a weak point in the developer workflow, with only 44% of developers reported to follow security best practices for secrets management, according to the State of Secrets in AppSec. That gap matters because delivery automation only stays trustworthy when secret handling is governed at the same pace as deployment.

For practitioners

• Map pipeline identities to deployment authority List every CI/CD and IaC workflow that can create, modify or destroy cloud resources, then document the exact permissions each one uses.
• Move secrets governance into release automation Ensure tokens, keys and certificates used by delivery tooling are inventoried, scoped to the minimum required privilege and tied to explicit revocation paths.
• Enforce policy checks before deployment Apply codified approval, compliance and misconfiguration checks to IaC templates so risky changes are stopped before they reach runtime.
• Track drift as an identity signal Treat unmanaged changes in permissions, templates or cloud state as evidence that the intended control model has diverged from reality.

Key takeaways

• Infrastructure-as-Code moves identity governance into the same workflow that provisions cloud resources, so access and policy can no longer be treated as separate administrative layers.
• The main operational risk is not automation itself, but unmanaged pipeline authority, exposed secrets and drift between intended and actual state.
• Identity teams should focus on making deployment permissions, secret lifecycles and policy checks visible inside the delivery process.

Key terms

• Infrastructure-as-Code Validation: Infrastructure-as-code validation checks whether deployment files are complete, consistent, and ready to apply before a push reaches production. In security terms, it reduces broken automation, prevents silent misconfiguration, and creates a control point where missing dependencies can be rejected early.
• 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.
• Drift Monitoring: Drift monitoring tracks whether inputs, embeddings, or outputs are changing over time in ways that can degrade model performance. It is an early-warning control that helps teams spot behaviour shifts before they become visible business or security failures.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.