IaC risk scoring shows where Terraform coverage leaves security gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on ControlMonkey's announcement: ControlMonkey's new IaC Risk Index scores Terraform coverage against cloud security exposure, highlighting where unmanaged or drifted infrastructure creates gaps.

Why it matters: Cloud and IAM teams need a shared view of infrastructure governance because unmanaged delivery paths create risk that code review and posture tools often miss.

Context

Infrastructure as code risk scoring is a governance problem as much as a cloud security problem. If teams cannot tell which assets were created through Terraform, which drifted, and which remain unmanaged, they cannot reason accurately about exposure or remediation priority.

ControlMonkey’s article frames the issue around Terraform coverage, delivery method, and vulnerability mapping. For practitioners, the practical question is not whether they have policy on paper, but whether infrastructure actually enters the environment through governed pipelines and stays in sync with code.

Key questions

Q: What breaks when infrastructure is deployed outside Terraform governance?

A: When infrastructure is deployed outside Terraform, security loses the governed lifecycle that makes change review, policy enforcement, and remediation repeatable. The result is not just less visibility. It is a control failure where assets can persist outside the system that teams use to assess, patch, and certify them.

Q: Why do unmanaged infrastructure resources create more security risk than governed ones?

A: Unmanaged resources bypass the code path that makes change review, policy enforcement, and remediation repeatable. That means vulnerabilities can appear without a reliable source of truth, and fixes may be applied inconsistently or too late. The risk is not only exposure, but loss of accountability across the delivery lifecycle.

Q: How can teams tell whether Terraform coverage is actually improving?

A: Teams should look for fewer unmanaged resources, less drift, and a shrinking gap between planned and live state. Coverage is improving only when assets are entering through the governed pipeline and staying aligned with code, not when the dashboard simply reports more declared infrastructure.

Q: Should cloud teams treat IaC risk scoring as a security control or a reporting tool?

A: Cloud teams should treat IaC risk scoring as a control input, not just reporting. If the score does not drive ownership, drift remediation, and import of unmanaged assets into Terraform, it is only describing exposure instead of changing the condition that created it.

How it works in practice

Terraform coverage as a governance signal

Terraform coverage is a proxy for how much of the cloud estate is created, changed, and remediated through controlled infrastructure code. When coverage is incomplete, the organisation loses deterministic change history, consistent policy enforcement, and a clean path from finding to fix. That makes the governance gap larger than a simple visibility problem because the resource may exist outside the workflow that security and DevOps teams inspect. The article’s scoring bands translate that into operational thresholds, with sub-50% coverage representing a high unmanaged-risk state.

Practical implication: Measure coverage by resource class and environment, then treat low-coverage zones as governance gaps, not just inventory gaps.

Drift, unmanaged resources, and remediation flow

The article separates unmanaged resources, drifted resources, and managed in-sync resources because each requires a different control response. Drift means the code no longer matches the live resource, so the change path and the security state have diverged. Unmanaged infrastructure is worse because it never entered the governed path at all, so remediation must start by importing the resource into Terraform or recreating it from compliant code. This is why the source ties risk to delivery method rather than to cloud location alone.

Practical implication: Build separate response paths for drift and unmanaged assets so remediation starts from the actual delivery state.

Shared cloud and security dashboards change accountability

A shared dashboard matters because infrastructure risk is created upstream in delivery and consumed downstream in security. If DevOps sees only release success and Security sees only vulnerability output, neither team can explain why a resource remains exposed. The article’s model links code, pipeline, and posture into one operational view, which is the right shape for governance conversations. The core value is not the dashboard itself; it is the shared accountability model that it enables across build and security functions.

Practical implication: Align DevOps and Security on one coverage and exposure view so ownership follows the delivery path, not siloed tooling.

NHI Mgmt Group analysis

Terraform coverage is becoming a governance control, not a reporting metric. Once cloud infrastructure can be created outside Terraform or drift away from it, coverage becomes the boundary between governed and ungoverned change. That is a structural identity governance issue for cloud estates because the control is no longer whether a team has policies, but whether the asset ever entered a managed lifecycle. Practitioners should treat coverage as an operational control surface, not a dashboard number.

Coverage gaps create hidden risk because delivery state determines security state. A resource that bypasses the secure pipeline is not just harder to observe, it is harder to remediate in a repeatable way. The article’s distinction between unmanaged, drifted, and in-sync resources is useful because each state implies a different failure mode in governance. Teams should stop collapsing those states into one generic exception bucket.

Shared visibility between DevOps and Security is now a prerequisite for measurable cloud governance. Security cannot govern what DevOps creates without policy, and DevOps cannot close risk if Security only sees the outcome after deployment. That makes the delivery path the unit of accountability, which is where cloud governance programmes need to mature. The practitioner conclusion is simple: ownership must attach to the path that creates the resource.

IaC risk scoring is best understood as an identity and control-plane alignment problem. Cloud governance fails when code, pipeline, and live state stop describing the same resource. In practice, that means the organisation has multiple versions of truth, and only one of them is enforceable. Practitioners should re-centre governance on synchronised state rather than after-the-fact findings.

What this signals

Coverage gaps are the real cloud governance boundary: when resources can be created or modified outside Terraform, policy no longer tracks the live estate. That means practitioners should prioritise lifecycle alignment between provisioning, drift detection, and remediation rather than treating posture as a downstream audit artifact.

The most useful shift is to separate unmanaged, drifted, and in-sync assets into different governance paths. Once those states are collapsed into one inventory view, teams lose the ability to assign ownership or choose the correct control response.

Cloud programmes that want measurable improvement need one shared view of delivery state and security state. Without that, DevOps optimises deployment while Security chases exposure after the fact.

For practitioners

• Define coverage thresholds by environment Set explicit Terraform coverage targets for production, staging, and exception zones, then review anything below target as unmanaged exposure rather than a routine exception.
• Separate drift from unmanaged state Create different remediation playbooks for drifted resources and resources that never entered Terraform, because the governance failure and the fix are not the same.
• Map vulnerabilities to delivery path Track whether each exposed resource was created manually, drifted after deployment, or remains fully governed so remediation starts at the right control point.
• Use a shared coverage-and-risk view Give DevOps and security teams the same dashboard for coverage, drift, and exposure so accountability follows the infrastructure lifecycle end to end.
• Prioritise unmanaged infrastructure first Triage resources outside Terraform ahead of routine patch work because ungoverned assets are the fastest route to silent exposure.

Key takeaways

• IaC risk scoring matters because cloud exposure often starts where infrastructure escapes the governed delivery path.
• Terraform coverage, drift, and unmanaged assets are distinct governance states and need distinct response paths.
• The practical fix is to tie ownership, remediation, and reporting to the pipeline that creates the resource.

Key terms

• Infrastructure as Code coverage: The share of infrastructure that is created, changed, and governed through code rather than manual console actions. In practice, it measures how much of the environment can be reviewed, reproduced, and remediated through a controlled delivery path instead of ad hoc operator behaviour.
• Infrastructure Drift: Infrastructure drift is the gap between the configuration a team thinks is deployed and the state that actually exists in cloud. In identity terms, drift weakens governance because policy, ownership, and remediation no longer map cleanly to live assets.
• Unmanaged infrastructure: Resources that exist outside the organisation's code-based governance process, often because they were created manually or bypassed the normal pipeline. These resources are harder to review, harder to fix consistently, and more likely to accumulate hidden exposure over time.
• Distribution Path Governance: The controls that determine how software moves from build to registry to CDN and end user. It matters because trust can be lost at any hop, and compromised packages can persist through mirrors and caches even after the original source is removed.

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.