Every cloud leader I speak with says security is a priority–who wouldn’t? But when I ask what metrics they’re using to measure their IaC Security posture, the answers get hazier…
Compliance scores. CVE dashboards. Tool-specific coverage stats. These are all common answers, and they’re important. But they’re also diffuse: some metrics live with cloud teams, some fall to security teams. There’s no single, unifying view that gives you a sense of overall maximum potential risk.
Lately, I’ve started pitching a new metric in these conversations. A metric I’m increasingly convinced is foundational for security, and almost no one is talking about it:
Infrastructure as Code (IaC) Coverage
For years, cloud teams have embraced IaC as a way to standardize, automate, and scale delivery. But even within some of the most advanced orgs, only a portion of cloud infra is actually managed in code. The rest lives in consoles, scripts, and tribal knowledge, aka: “unmanaged resources.” Even teams who think their IaC coverage is high often find they have lots of unmanaged resources when they do the analysis. And those unmanaged resources are where security risks live.
So, while IaC coverage is often seen as an operational concern, security leaders should value it, too. Because unmanaged infrastructure isn’t just a cloud team problem—it’s a threat surface blind spot. That makes coverage not just something to monitor, but something to proactively own.
That’s why IaC coverage is a security metric.
Why IaC Coverage Matters
Most conversations about IaC coverage focus on operational consistency and disaster recovery. That makes sense: a high coverage percentage means fewer manual changes, faster remediation, and recoverable infra. But, it turns out, in addition to all those benefits:
IaC coverage is also a great metric for forecasting IaC Security
When ControlMonkey does initial assessments across large-scale environments, one fact continues to appear over and over: Unmanaged resources carry twice the security risk of those governed by IaC.
Why? Because unmanaged resources are invisible to almost all proactive controls. When someone changes something manually in a cloud console, there’s no policy enforcement pipeline; there’s no automated validation; and when issues are detected, remediation is usually slow and manual.
I see four main reasons why low IaC coverage translates to increased security risk:
- No proactive validation
Unmanaged resources bypass CI/CD guardrails. There’s no static analysis, no policy-as-code, no preventative controls. Risks slip through unnoticed. - Slower, riskier remediation
Fixing a misconfiguration manually is slow and riddled with errors. Without code ownership, accountability gets fuzzy and remediation cycles drag. - Lack of reusable security
If it’s not in code, it’s not in your modules. That means no reusable guardrails, no consistent patterns, and no built-in policy enforcement. - Security gaps compound over time
As your Terraform evolves and modules get updated, unmanaged resources don’t. They get left behind, further misaligned with your latest best practices and exposing drift and compliance gaps.
That’s why IaC coverage isn’t just a hygiene metric—it’s a forward-looking indicator of risk. The question is, how do we make it actionable for cloud and security teams?
The Path Forward: Measuring Risk by Coverage
ControlMonkey is introducing the IaC Risk Index—a simple framework that correlates IaC coverage with infrastructure risk levels. It highlights common symptoms and risk patterns associated with different coverage thresholds, and incorporates the severity of your vulnerabilities relative to coverage to provide
a more tailored view of overall risk. The goal—especially in production—is green. Anything less is a vulnerability waiting to surface.
| Coverage | Status | Symptoms | |
| 🔴 | <50% IaC coverage | High risk. Most infrastructure is unmanaged and ungoverned. | Frequent ClickOpsInconsistent delivery methods across teamsAutomation pipelines bypassed/unusedSlow, error-prone deploymentsReactivity to misconfigsNo visibility into who changed what, or when |
| 🟠 | 50–80% IaC coverage | Medium risk. Governance exists, but gaps remain. | Partial IaC adoption across teams/environmentsLegacy stacks managed manuallyInconsistent tagging, naming, and access controlChange velocity varies based on team or stackPolicy enforcement varies by environment |
| 🟡 | 80–90% IaC coverage | Low risk. Strong coverage, but still not total. | Some workloads still outside policy enforcementOccasional drift due to out-of-band changesSlow or manual onboarding for new projectsLimited reuse of standardized modulesPockets of exception-based governanceNot all changes are tied to auditable code reviews |
| 🟢 | 90–100% IaC coverage | Full control. Infrastructure is governed by code, by policy, by design. | Minimal ClickOps activityFast, consistent onboarding for new engineers and servicesShift-left policies enforced by defaultProactive risk mitigation via automationClear audit trails and full change accountabilityAll infra passes through policy engines-as-code gates |
IaC coverage is a shared accountability metric
Normally, security teams find the risk, and cloud teams get the ticket. And then? it sits. Or bounces. Or escalates. Not because security isn’t important, but because they have different priorities… the very definition of org friction.
IaC coverage gives both sides a metric they can act on. Security teams see what’s governed and where blind spots exist. Cloud teams know exactly what to fix. The result? Faster action, fewer dropped handoffs, and better outcomes across the board.
Think of IaC coverage as the missing link between DevOps and Security. It translates complexity into action. And it turns finger-pointing into shared responsibility. I’ve seen it first-hand. And it works great.
What Cloud and Security Leaders Should Do Next
- Audit your current IaC coverage
Most orgs don’t know how much of their cloud is managed by code. Start by finding out. - Make coverage a core metric
Put it on your dashboards. Track it alongside vulnerability and compliance data. Use it to guide remediation and investment. - Treat unmanaged resources as unmonitored risk
If a resource isn’t governed by code, your security tooling likely can’t see it, scan it, or enforce policy on it. Include IaC coverage in your posture reviews and remediation plans. - Close the gap
Move fast to bring unmanaged resources under code. The tooling exists. The benefits compound. - Shift the conversation
If you want to unify cloud and security teams, give them a shared KPI. IaC coverage is measurable, actionable, and improves everything it touches—especially security.
Final Thought on IaC as security metric
Infrastructure used to be “just plumbing.” Today, it’s the foundation for everything your business needs to move fast and stay secure. And while it may now be cliche to mention AI–yes, AI means more teams will need more infra faster, which will only make secure delivery harder.
IaC coverage isn’t just an engineering best practice.
It’s a security metric. And it belongs on your dashboard.
Author
