When a Terraform plan or CloudFormation template gets flagged in a CI pipeline, the alert usually comes with a rule ID, a severity, and a one-line description — but rarely an explanation of where that rule came from or why it matters to an auditor. Snyk IaC ships with a library of 400+ static analysis rules covering Terraform, CloudFormation, Kubernetes manifests, Helm charts, and ARM/Bicep templates, and a meaningful share of that library exists specifically to encode controls from published hardening standards like the CIS AWS Foundations Benchmark, CIS Azure Foundations Benchmark, CIS Google Cloud Platform Foundation Benchmark, and CIS Kubernetes Benchmark. Understanding how a misconfiguration check in a Terraform file traces back to a numbered CIS control — and where that mapping breaks down — matters for any team trying to use IaC scanning as evidence of compliance rather than just a lint pass. This piece walks through the mechanics publicly documented by Snyk.
What is actually in Snyk IaC's rule library?
The library is a set of individually versioned static analysis checks, each one written to detect a specific misconfiguration pattern in a specific resource type — an S3 bucket without encryption, a security group open to 0.0.0.0/0 on port 22, a Kubernetes pod running as root, an Azure storage account allowing public blob access. Snyk's documentation groups these checks by cloud provider and IaC framework (Terraform for AWS/Azure/GCP, CloudFormation, Kubernetes YAML, Helm, ARM templates, Bicep, and Dockerfile), and each check carries metadata: a unique rule identifier, a severity rating (critical, high, medium, low), a plain-language title, a remediation snippet showing the corrected configuration, and — where applicable — one or more compliance framework references. That last field is what lets a single rule, such as "S3 bucket has server-side encryption disabled," show up simultaneously as evidence toward CIS AWS Foundations, PCI DSS, HIPAA, and SOC 2 requirements, because those frameworks independently require encryption at rest even though they word the requirement differently.
A meaningful part of this engine's lineage traces to Snyk's August 2022 acquisition of Fugue, a cloud security posture and IaC scanning vendor. Fugue's engine was built on Open Policy Agent (OPA) and Rego, and its open-source component, Regula, is still available on GitHub as a standalone policy library. Snyk absorbed that policy-as-code approach and rule set into what is now marketed as Snyk IaC and Snyk Cloud, which is why compliance-framework tagging is a first-class, structured attribute of the rule metadata rather than a bolt-on report generated after the fact.
How does an individual rule map to a specific CIS control?
Each rule's metadata contains a direct reference to the control number in the relevant CIS benchmark document, not just a category label. For example, a check for whether CloudTrail is enabled across all AWS regions maps to CIS AWS Foundations Benchmark control 3.1 ("Ensure CloudTrail is enabled in all regions"), and a check for MFA on the root account maps to control 1.5. Because CIS benchmarks are written as prescriptive, numbered recommendations with explicit rationale and audit/remediation procedures, they translate well into discrete, machine-checkable assertions — which is exactly the format a static analysis rule needs. When Snyk's scanner parses a Terraform or CloudFormation resource and evaluates it against a rule's logic, a failed evaluation is reported with that CIS control reference attached, so a finding in the CLI or UI can be traced back to "this violates CIS AWS Foundations Benchmark v1.4/v1.5, section 2.1.1" rather than just "encryption is off." This is what lets compliance and security teams generate a framework-oriented report — for example, "current CIS AWS coverage: 87 of 110 applicable controls passing" — directly from IaC scan results instead of manually cross-referencing a spreadsheet.
Which benchmarks and standards does the library actually cover?
Snyk's documentation lists CIS benchmarks for AWS, Azure, GCP, and Kubernetes as the primary mapped framework, alongside PCI DSS, HIPAA, ISO 27001, SOC 2, and NIST 800-53 as secondary framework tags on the same underlying rules. Coverage is not uniform across clouds: AWS and Kubernetes have the deepest rule coverage because Terraform and CloudFormation usage for AWS resources, and raw manifests for Kubernetes, are the most common IaC formats Snyk customers scan, so those rule sets have had the most iteration. CIS benchmarks themselves are versioned and periodically revised by the Center for Internet Security — the CIS AWS Foundations Benchmark has gone through major revisions (v1.2, v1.4, v1.5, v2.0, v3.0) since 2016, each adding, retiring, or renumbering controls as AWS services and default configurations change. Snyk's rule-to-control mapping has to track whichever benchmark version it targets, since a control numbered 2.1.1 in v1.4 is not guaranteed to be numbered or worded identically in v3.0.
How does Snyk keep the rule library current as benchmarks change?
Snyk updates the rule library on an ongoing basis as new IaC resource types, cloud provider features, and benchmark revisions are published, delivered transparently through Snyk's public release notes and changelog rather than as a single scheduled recompile. Because CIS benchmarks are revised roughly every one to two years per cloud provider, and cloud providers themselves ship new services and default settings continuously, a rule library mapped to a fixed benchmark snapshot will drift out of date if it isn't actively maintained — a new AWS service with a public-by-default setting, for instance, has no corresponding CIS control until CIS publishes one, and no Snyk rule until Snyk's rule authors write one. This is a structural limitation of any benchmark-driven rule library: it lags the pace of cloud provider feature releases by design, since the benchmark itself has to be drafted, reviewed, and published by CIS's community working groups before a vendor can map a rule to it.
Can teams add or customize rules beyond the standard library?
Yes — Snyk IaC supports custom rules authored in Rego, the same policy language OPA and Regula use, allowing teams to codify internal standards that aren't covered by a public CIS control at all, such as mandatory tagging schemes, approved instance types, or organization-specific network segmentation requirements. Custom rules are packaged as a rules bundle and loaded alongside the standard library during a scan, and they follow the same metadata structure — severity, title, remediation guidance — so they surface in the same reporting surface as built-in CIS-mapped checks. This matters because CIS benchmarks are deliberately generic; they're written to apply across any organization using a given cloud provider, so they can't encode a specific company's naming conventions, approved AMI list, or internal segmentation policy. Custom rules are the mechanism for closing that gap without waiting on Snyk or CIS to publish something more specific.
What are the practical limits of benchmark-mapped IaC scanning?
The main limit is that IaC scanning checks what's written in configuration files, not what's actually deployed, so a benchmark "pass" on a Terraform plan doesn't guarantee the live environment matches it — manual console changes, drift from unmanaged resources, or modules pulled from untrusted registries can all produce a running environment that no longer reflects the scanned source. CIS benchmark mapping also only covers what CIS has chosen to standardize; a benchmark control is the lowest common denominator that a broad community working group agreed on, which means passing 100% of mapped CIS controls is a meaningful baseline but not equivalent to a full risk assessment. Teams that treat a green CIS-mapped scan as the finish line rather than a floor tend to miss configuration and dependency risks that fall outside the benchmark's scope entirely, including supply chain issues in the modules and container images the IaC references.
How Safeguard Helps
Benchmark-mapped IaC scanning tells you whether the configuration you're about to deploy matches a published hardening standard — it doesn't tell you whether the Terraform module, Helm chart, or base image that configuration pulls in can be trusted, or whether what actually got deployed still matches what was scanned. Safeguard extends that picture by tracking software supply chain provenance across the artifacts your IaC depends on: verifying that third-party modules and container images referenced in your infrastructure code come from expected sources, generating and monitoring SBOMs for the components that end up in production, and flagging drift between a signed, scanned build artifact and what's actually running. For teams already using CIS-mapped IaC scanning to satisfy compliance evidence requirements, Safeguard adds the artifact-integrity layer underneath it — so the encryption setting, network rule, or IAM policy you validated pre-deploy is backed by verified provenance on every component that shipped it, not just a passing static scan.