IaC risk scoring shows where Terraform coverage leaves security gaps

At a glance

What this is: This is a product announcement about an IaC Risk Index that maps Terraform coverage to cloud security exposure and surfaces unmanaged, drifted, and in-sync infrastructure.

Why it matters: It matters because IAM, platform security, and cloud governance teams need a shared way to see where code-based control ends and unmanaged infrastructure risk begins.

By the numbers:

• Actual coverage is typically 30% to 40% lower than teams assume.

👉 Read ControlMonkey's announcement on the IaC Risk Index for cloud governance

Context

IaC risk scoring is a way to compare how much infrastructure is actually governed by code against the security exposure created when resources are created outside that control path. For cloud and identity teams, the problem is not just drift. It is the gap between what is deployed, what is covered by Terraform, and what still sits outside a controlled lifecycle.

ControlMonkey's IaC Risk Index is aimed at closing that gap by making unmanaged, drifted, and fully governed resources visible in one view. For practitioners, the important shift is organisational rather than cosmetic. Security decisions become easier to argue when delivery method, coverage, and exposure are measured together instead of debated separately.

Key questions

Q: How should security teams measure whether infrastructure is actually governed by IaC?

A: Start by measuring coverage, drift, and exception volume together. A single coverage percentage is not enough if unmanaged resources still exist or if live infrastructure has drifted from Terraform. The practical test is whether every production resource can be traced back to code, policy, and an approved delivery path.

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: What breaks when drifted infrastructure is patched before it is reconciled?

A: The patch may not match the actual live configuration, which means the underlying exposure can remain even after the code is updated. Drift has to be resolved first because otherwise the organisation is repairing an abstraction, not the deployed resource. This is a common failure point in cloud governance workflows.

Q: Who should own IaC risk governance when DevOps and security share the same environment?

A: Ownership should sit with the team that controls the delivery path, but security must define the policy boundaries and escalation rules. If ownership is split without a shared view of coverage and exceptions, no one can prove whether a resource is governed, drifted, or unmanaged.

How it works in practice

IaC-aware risk scoring and coverage thresholds

The index uses coverage bands to translate infrastructure governance into an operational risk signal. In the model described by ControlMonkey, red means less than 50% coverage, orange means 50% to 80%, yellow means 80% to 90%, and green means 90% to 100%. The mechanism matters because IaC coverage is not a vanity metric. It indicates how much of the environment can be governed through code, policy, and pipeline rather than manual change. That makes the score a proxy for control consistency, not just automation maturity.

Practical implication: set coverage thresholds as governance gates, not dashboard colour preferences.

Delivery-method mapping and drift handling

The index separates unmanaged resources, managed-but-drifted resources, and managed-and-in-sync resources because each condition requires a different control response. Unmanaged resources must first be imported into Terraform so they can enter a governed lifecycle. Drifted resources require reconciliation before any security fix is reliable, because the code and the live resource no longer match. In-sync resources can be patched in Terraform and kept compliant through policy enforcement. This is a delivery-path problem as much as a security problem.

Practical implication: route remediation based on delivery state, not on vulnerability severity alone.

Shared cloud and security dashboarding

A shared dashboard is not just a reporting convenience. It is a governance mechanism that lets platform teams and security teams work from the same source of truth about coverage and exposure. When both groups see unmanaged infrastructure, drift, and vulnerability correlations in the same view, ownership arguments become less important than remediation sequencing. That changes the operating model from periodic reporting to continuous infrastructure control. The value is in reducing translation loss between DevOps language and security language.

Practical implication: use a common dashboard to align remediation ownership before exceptions become normalised.

NHI Mgmt Group analysis

IaC coverage has become a governance boundary, not a tooling preference. Once infrastructure is created outside Terraform, the organisation loses a consistent control plane for review, remediation, and policy enforcement. That is why unmanaged infrastructure carries a different risk profile from governed infrastructure. The practitioner takeaway is to treat IaC coverage as a control boundary that defines whether security can reason about the environment at all.

Coverage gaps expose a delivery-path failure mode that security teams often miss. The problem is not only that a resource is vulnerable. It is that the resource bypassed the normal pipeline that would have made the vulnerability visible, attributable, and fixable in code. This is the kind of failure mode that turns cloud security into a documentation exercise after the fact. Teams should reframe unmanaged infrastructure as a lifecycle failure, not just a remediation backlog.

Shared IaC and security reporting is becoming essential for cross-functional governance. The article points to a broader operating model in which DevOps and security no longer argue over whether infrastructure is compliant. They work from the same coverage and exposure signal. That aligns with cloud governance patterns in NIST Cybersecurity Framework 2.0 and zero trust thinking, where visibility and policy enforcement must be continuous. Practitioners should align control ownership around the delivery path, not around the ticket queue.

Identity blast radius: infrastructure that is not governed by code expands the range of changes, credentials, and permissions that can exist outside review. In cloud environments, that blast radius grows when manual provisioning, drift, and disconnected remediation all coexist. The result is not simply more risk, but less explainable risk. Teams should define where code governance ends and where exception handling begins.

ControlMonkey's framing reflects a wider shift from point-in-time security checks to continuous infrastructure governance. The market is moving toward models that tie exposure to delivery method because static assessments do not catch what is created between reviews. That does not eliminate the need for vulnerability management. It changes the question from whether a resource is patched to whether the resource was ever under the right control process in the first place. Practitioners should expect IaC coverage to become a board-level governance signal.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader identity control baseline, see NIST Cybersecurity Framework 2.0 and map infrastructure governance to continuous identify, protect, detect, respond, and recover practices.

What this signals

IaC coverage will increasingly function as an identity-adjacent control signal. As cloud environments grow more dynamic, teams will need to know not only what is deployed but which changes can be attributed to a governed delivery path. That is why coverage, drift, and exception handling will matter more in audit and incident response than raw infrastructure counts.

The next governance step is to connect infrastructure risk scoring to lifecycle control. When unmanaged resources can be imported, remediated, and then governed in code, the organisation moves from periodic clean-up to continuous control of cloud change. Practitioners should expect this to converge with zero trust and policy-as-code reporting.

For practitioners

• Define IaC coverage thresholds as policy gates Set explicit coverage bands for production environments and require exceptions when resources fall below agreed thresholds. Tie those thresholds to change approval, not just to reporting, so unmanaged infrastructure cannot quietly accumulate outside review.
• Separate unmanaged, drifted, and in-sync remediation paths Do not treat every vulnerable resource the same. First import unmanaged assets into Terraform, then reconcile drift, then apply security fixes in code so the live environment and the source of truth stay aligned.
• Build one operating view for cloud and security teams Use a shared dashboard for coverage, drift, and exposure so platform owners and security leads are resolving the same facts. Include exception tracking and ownership assignment to prevent gaps from becoming permanent.
• Audit where delivery bypasses governance Look for manual provisioning, direct console changes, and pipeline exceptions that create infrastructure outside code control. Those paths should be treated as control failures, not just process noise, because they break reproducibility and accountability.

Key takeaways

• IaC governance fails when infrastructure can be created or changed outside the code path that security relies on.
• The key signal is not just exposure, but how much of the environment remains outside Terraform control or has drifted from it.
• Teams should align remediation, ownership, and reporting around delivery state so unmanaged infrastructure does not become permanent shadow cloud.

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.
• Configuration drift: A state where the live infrastructure no longer matches the declared configuration in code. Drift matters because security fixes applied to the source of truth may not reflect what is actually running, which weakens governance, auditability, and incident response.
• 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.

Deepen your knowledge

IaC risk scoring, delivery-path governance, and drift remediation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a cloud governance programme from the same starting point, it is worth exploring.

This post draws on content published by ControlMonkey: the launch of the IaC Risk Index. Read the original.