A Terraform module defines an S3 bucket without server-side encryption enabled. Snyk IaC flags it as a misconfiguration the moment the pull request is opened — before a single resource exists in AWS. That finding is useful, but it's incomplete: is this bucket actually deployed? Is it internet-facing? Does it hold production data, or is it a throwaway resource in a sandbox account that gets destroyed nightly?
Snyk answers that question through a capability it calls Cloud Context, built on technology it acquired from Fugue in October 2022. Rather than treating static code analysis and live cloud inventory as two separate problems, Snyk connects to a customer's AWS, Azure, or GCP accounts via read-only API access and reconciles what's running against what's written in Terraform, CloudFormation, or Kubernetes manifests. This piece explains, mechanically, how that correlation works, what data it depends on, and where its limits are — as a standalone look at a widely deployed IaC security pattern, not a comparison to any other vendor.
What problem does IaC-to-cloud correlation actually solve?
It solves the gap between "this configuration is wrong" and "this configuration is exposed." Static IaC scanning checks a Terraform, CloudFormation, or Kubernetes file against a policy set — Snyk IaC evaluates infrastructure code against rules covering categories like public access, encryption, logging, and IAM permissions across AWS, Azure, GCP, and Kubernetes resource types. That check runs entirely against source text; it has no way of knowing whether the resource it's describing was ever applied, whether it was later modified out-of-band, or whether ten other misconfigured resources point at the same subnet. Fugue's original product was built specifically around this gap: continuously evaluating cloud environments against policy and mapping violations back to the IaC source that created them, which is the lineage Snyk folded into Snyk Cloud after the acquisition.
How does Snyk map a specific line of Terraform to a specific live resource?
It matches on resource identity, not just resource type or naming similarity. When Terraform applies a configuration, the resulting state file (or Terraform Cloud/Enterprise state) contains a resource address (for example, aws_s3_bucket.logs) paired with the cloud provider's own identifier for that resource — an ARN in AWS, a resource ID in Azure, a self-link in GCP. Snyk's cloud connectors ingest both the IaC source and, where available, the state data or a live inventory snapshot pulled directly from the provider's APIs, then join the two data sets on that identifier. This is the same reconciliation model CSPM tools have used for years: code declares desired state, the provider API reports actual state, and the identifier is the join key. The practical result is that a misconfiguration surfaced in a .tf file during a PR check can be traced to the exact bucket, security group, or IAM role running in a specific account and region, rather than a generic "some resource matching this pattern might exist somewhere."
What access does Snyk need to a cloud account to build this correlation?
It needs read-only, account-level visibility into resource configuration and metadata — not write access, and not access to the data stored inside those resources. In AWS this is typically implemented via a cross-account IAM role with a read-only policy scope (mirroring how Fugue's original CSPM product connected); in Azure and GCP the equivalent is a service principal or service account with read permissions over resource configuration APIs. Snyk uses this access to enumerate resources, tags, network attachments, and IAM bindings across connected accounts, refreshing the inventory on a recurring schedule so the "actual state" side of the comparison doesn't go stale between scans. Without this connection, Snyk IaC still works as a pure static scanner against the code; Cloud Context is an additive layer that requires the customer to explicitly onboard a cloud account.
How does drift detection fit into this correlation model?
Drift detection is the direct byproduct of comparing IaC-declared state to live state on a recurring basis — any mismatch between the two is drift by definition. A security group that Terraform defines as allowing traffic only from a corporate CIDR block, but which someone opened to 0.0.0.0/0 directly through the AWS console during an incident, no longer matches its own source of truth. Because Snyk already holds both the declared configuration and the live configuration keyed to the same resource identifier, it can flag that divergence as its own finding category rather than requiring a separate terraform plan diff. This is useful specifically because manual console changes, break-glass fixes, and other IaC tools operating on the same account are common sources of configuration that no longer has a matching commit anywhere.
How does correlation change which findings get prioritized?
It re-ranks findings by whether they're live and reachable, not just whether they violate a policy. A misconfigured resource that exists only in an unmerged feature branch, or in a Terraform module that's never actually applied, carries no runtime risk regardless of severity in the code. A misconfigured resource confirmed live in a production account, attached to a public subnet, and reachable from the internet is a different problem entirely. By joining IaC findings to live cloud inventory, Snyk can attach that "is this deployed and exposed" context to a misconfiguration, which is the mechanism vendors in this space generally point to when they talk about reducing noise from IaC scanning — the count of raw policy violations in a repository is a poor proxy for the count of resources actually worth fixing first.
Where does this correlation approach break down?
It breaks down anywhere the join key is missing, stale, or ambiguous. Resources created through ClickOps (manually in the console) have no IaC counterpart to correlate against — Cloud Context can flag them as unmanaged, but it can't tie them to a commit or a PR because none exists. Resources provisioned through tooling Snyk doesn't ingest (a legacy CloudFormation stack never connected, a Pulumi or CDK deployment outside the supported integration surface, an in-house provisioning script) sit outside the comparison entirely. And because the live-inventory side depends on a connected, sufficiently-permissioned account with a refresh cadence, there's an inherent lag between something changing in the cloud and that change being reflected in the correlated view — the comparison is only as current as the last sync. None of this is a flaw specific to Snyk; it's a structural property of any system that reconciles declarative code against imperative cloud state after the fact rather than intercepting changes as they happen.
How Safeguard Helps
Understanding how IaC-to-cloud correlation works matters regardless of which scanner produces the finding, because the same structural gap — misconfigurations in code versus what's actually running — exists across every IaC pipeline. Safeguard focuses on the software supply chain layer that sits upstream and downstream of that gap: verifying that the Terraform modules, container images, and CI/CD pipelines producing your infrastructure haven't been tampered with before they ever reach a cloud account, and maintaining provenance and SBOM data so that when a live resource is flagged, teams can trace it back to the exact commit, build, and dependency set that produced it. Correlating a misconfiguration to a live resource answers "is this exposed." Safeguard's focus is answering the adjacent question — "can we trust what built this in the first place" — through artifact signing, build provenance attestation, and continuous verification across the pipeline that generates your infrastructure code and deploys it. Together, these give security teams both sides of the picture: confidence in the pipeline that shipped the resource, and visibility into what that resource actually looks like once it's live.