Notifications
Clear all
Topic starter
12/06/2026 12:37 am
TL;DR: Traditional CI/CD is effective for stateless application delivery, but it breaks down for live cloud infrastructure where state, dependencies, drift, and rollback risk make small changes harder to control, according to ControlMonkey. The governance problem is not pipeline speed, but whether teams can safely manage infrastructure changes with traceability and policy.
NHIMG editorial — based on content published by ControlMonkey: Software Is Stateless. Infrastructure Is Not
Questions worth separating out
Q: How should teams govern infrastructure changes when CI/CD is not enough?
A: Use a delivery model that treats infrastructure as a governed stateful asset, not as disposable application code.
Q: Why do cloud infrastructure changes create more risk than software deployments?
A: Cloud infrastructure changes can alter live access paths, routing, and compliance state immediately, so the impact is broader than a code artifact swap.
Q: What should security teams measure to know whether infra delivery is under control?
A: Measure drift frequency, unowned resources, policy exceptions, and the time it takes to explain a live change from code to production.
Practitioner guidance
- Map infrastructure to accountable stack units Define a governed stack for each live infrastructure boundary so code, ownership, drift state, and compliance status are visible together.
- Block changes when live state no longer matches intent Add drift detection to release gates so teams stop shipping against an unknown environment.
- Replace manual approvals with policy-backed reviews Move approval logic into policy checks that can evaluate environment, ownership, and risk before deployment.
What's in the full article
ControlMonkey's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific stack-based delivery workflow the vendor uses to map code to live cloud resources.
- The governance checks for ownership, compliance, and drift that sit inside the delivery model.
- The practical change-control questions teams should ask before shifting infrastructure delivery processes.
- The operational trade-offs the vendor says appear as cloud estates grow across teams and environments.
👉 Read ControlMonkey's analysis of why CI/CD breaks down for cloud infrastructure →
CI/CD for cloud infrastructure: where the delivery model fails?
Explore further
12/06/2026 10:00 am
CI/CD assumes infrastructure is disposable, and that assumption fails the moment state matters. Application delivery can often tolerate rollback as a normal safety valve. Cloud infrastructure cannot, because permissions, routes, and dependencies already exist in production when a change lands. The implication is that infrastructure governance must be built around live state, not artifact replacement.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- 84% of organisations report at least one unresolved identity governance gap across machine or AI workloads, according to the Ultimate Guide to NHIs , Standards.
A question worth separating out:
Q: Who should own governance when infrastructure delivery spans engineering and security?
A: Engineering should own the code path, while security and platform teams should own the policy boundaries and audit expectations. The important point is that ownership must be explicit at the stack level, because unclear accountability is what allows drift and unsafe change to accumulate.
👉 Read our full editorial: Infrastructure is not stateless, and CI/CD breaks down
