Every security domain has a number that tells you how much of it is under control. Identity has MFA adoption. Patching has mean time to remediate. Exposure has open critical issues. Each one answers a simple question at a glance. Cloud infrastructure should have an equivalent metric, and Infrastructure-as-Code (IaC) coverage is a strong candidate.
IaC is how the modern cloud gets built, and for good reason. Code can be reviewed before it ships, governed by policy, and rebuilt the same way every time. How much of your cloud runs through code, your IaC coverage, is a direct measure of how much of it you can secure by design.
But unlike other domains, coverage in the cloud isn't binary. A resource can be half-covered: deployed through a pipeline yet impossible to trace back to the code that defined it. The useful version of IaC coverage isn't a single percentage, it's a funnel. From the infrastructure that could be in code, to what an IaC tool actually tracks, to what you can open and fix in a repo today.
That funnel is how cloud security and DevOps teams should think about IaC coverage: not as a percentage to report, but as a roadmap for bringing more of the cloud under governance.
The IaC Coverage Funnel: Tracing Supported, Deployed, and Declared
Even in the most cloud-native enterprises, some resources are still provisioned outside of code. They’re either created via ClickOps, launched by a script, or spun up by an engineer solving a problem at 2 a.m. That unmanaged infrastructure is where risk concentrates because a resource that isn't in code never passes through a pipeline check. No policy-as-code evaluates it, and no static analysis flags it before it ships. If the resource drifts, nothing reconciles it. And when something goes wrong, there's no module, file, or author to trace it back to.
Therefore, coverage is a security measure, not just a DevOps hygiene stat. But a single percentage can't tell you where, along the path from cloud to code, your infrastructure stops being governable. Instead, we think about it as a funnel across three stages:
IaC-supportable: Every cloud resource that could be defined in code. A database instance, a service account a VPC subnet. This is the full set and the widest part of the funnel, and it's the honest baseline for any coverage number. For resources that make it no further through the funnel, the gap is clear. Consider a new virtual machine that's spun up in the console during an incident and never imported to IaC. No state file tracks it, nothing will ever flag it as drifted, and it won't be considered when the infrastructure needs to be re-provisioned.
Tracked by IaC: The resource appears in a state file, or its equivalent. It's been created through a form of IaC. Drift can be detected, and the resource can be considered semi-governed. Here, the gap is subtler: a database instance that's in state but was created by a module since deleted or refactored out of the repo. IaC governs it, but no one can trace or fix the code that defines it.
Mapped to a declaration in code: An IaC resource's definition in state resolves to an actual module, file, and line in a repo you can open today. Now the source can be scanned before deploy, fixes can ship as pull requests, and the resource can be rebuilt from code. Resources that reach this stage should be considered governed, and traceable.
Each stage that narrows is a coverage gap with a specific action attached. Resources that fall out at stage one need to be brought under IaC. Resources that stall at stage two need to be reconnected to their source code. In other words, the funnel turns a vague percentage into a prioritized backlog.
IaC Coverage Enables Traceability, Resilience, and Compliance
Coverage matters because of what depends on it. Fixing risk at its source, rebuilding cleanly after an incident, and proving infrastructure was checked before it shipped only becomes possible for the share of your cloud that lives in code. For example:
Traceability: When a misconfiguration shows up on a live resource, coverage decides whether you fix the symptom in the console or the cause in code. A resource mapped to its module gets a targeted pull request and the right owner. An unmapped one gets a manual change that drifts again next week.
Resilience: You cannot rebuild from code that doesn't exist. The infrastructure that was never codified is exactly the infrastructure you can't recreate under pressure, which makes coverage the precondition for recovering an environment, not just redeploying part of one.
Compliance: Infrastructure governed by code passes through pipeline checks before it ships. Coverage tells you how much of your estate is validated at the source, versus caught after it's already in production, if it's caught at all.
How Wiz Measures IaC Coverage
Wiz Code scans the modules and pipelines that define your infrastructure, and Wiz Cloud sees what's actually running. The IaC Inventory, now Generally Available, reconciles them, connecting every module to every deployment it created and every live resource it manages. The result is the funnel you've already seen, showing exactly where resources fall out of IaC governance.
Because Wiz sees both code and cloud, it can act on the gaps the funnel reveals. A finding on a live resource maps back to the exact module that declared it, with the owner attached, so the fix ships as a pull request instead of a manual console change.
The same rules run as pipeline controls in development and as cloud controls at runtime, so DevOps teams catch misconfigurations early using the policies Cloud Security teams enforce in production. New infrastructure is checked before it ships rather than caught after.
The Security Metric Cloud Teams Have Been Missing
Measuring coverage is the foundation. Acting on it is what matters now, because the window to act has collapsed. AI models can find a flaw and produce a working exploit in hours, so remediation has to keep pace with machine-speed attacks.
In the era of AI Threat Readiness, machine-speed remediation has a hard prerequisite, and it's stage three of the funnel: the resource has to map back to code. An autonomous agent can open a pull request, fix a misconfiguration at its root, and preserve intended behavior only when it can see the module, the deployment, and the live resource together. The Wiz Green Agent does exactly that, but only across the share of your estate that coverage reaches. The higher your coverage, the more of your cloud you can defend at machine speed.
You already measure identity, patching, and exposure. IaC coverage is the missing number that tells you whether your cloud was built right in the first place, and it belongs on the same dashboard.
Existing Wiz Code customers can connect their repositories and IaC platforms and start exploring the IaC Inventory today. For a deep dive into how it works, visit the documentation (login required).
New to Wiz? Book a demo to see how the Security Graph connects your IaC estate to your runtime environment.
Verizon's latest DBIR highlights how attackers are exploiting familiar weaknesses at increasing speed and scale. Here's what Wiz research reveals about vulnerabilities, trust relationships, and AI in modern cloud environments.