Topic starter
12/06/2026 12:02 am
TL;DR: Infrastructure-as-Code is accelerating DevOps and DevSecOps adoption because teams want faster, repeatable delivery with embedded policy, drift detection and compliance checks according to ControlMonkey. For identity teams, the shift matters because cloud change control increasingly depends on codified access, secrets and environment governance rather than manual review.
Editorial analysis by NHI Mgmt Group, based on content published by ControlMonkey: “DevOps vs DevSecOps: What’s the Difference in the IaC Era?”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 22 hours ago by NHI Mgmt Group
12/06/2026 9:02 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DevOps vs devsecops in the IaC era: what changes for identity
This post was modified 22 hours ago by NHI Mgmt Group