IaC / Terraform Scanning
Infrastructure-as-Code Security Scanning
Catch cloud misconfigurations in 15+ Infrastructure-as-Code formats *before* they ship — and keep tracking them *after* they ship.
A native HCL2 engine reads a real HashiCorp syntax tree (not whitespace-brittle regex), with compliance-mapped typed rules, auto-fix snippets and CIS mapping across AWS, GCP and Azure. Additional engines run alongside it, taking total coverage past 1,000 checks and reaching the long-tail formats most scanners skip. On overlap the native typed rules win, so basics are never double-reported.
Two surfaces:
- Shift-left CI/CD gate — block a risky
terraform applyin your pipeline, with a pass/fail verdict. - In-platform posture — IaC findings land on your Findings dashboard.
The differentiator — code-to-cloud correlation. Unlike a CLI-only scanner, every IaC misconfiguration is matched to your live cloud asset graph: you see whether the bad config is *actually deployed*, and whether that asset is internet-facing or holds sensitive data. A hypothetical issue becomes a confirmed live exposure that outranks purely-static findings — the link pure scanners cannot make.
How it fits together
POST /api/v1/scan/iac (Bearer ek_…). Verdict blocks a bad terraform apply before deploy.The CI/CD gate
Your pipeline sends changed IaC files to a per-tenant, authenticated scan endpoint. Every engine runs, findings are correlated to your live cloud asset graph, and the response carries a gate verdict your build step acts on.
| Verdict | Triggered by | Pipeline |
|---|---|---|
| FAIL | ≥ 1 CRITICAL finding | ⛔ build fails |
| WARN | ≥ 1 HIGH (no critical) | ⚠️ reported, doesn't block |
| PASS | only medium/low, or clean | ✅ build passes |
By default only CRITICAL fails the gate; you can also block on HIGH, or run report-only.
Every finding carries a severity, a stable per-cloud rule ID (TF-/GCP-/AZ-), the resource and file:line, a description and remediation, a ready-to-paste auto-fix HCL snippet, a CIS benchmark reference, and SOC 2 / HIPAA / PCI-DSS / GDPR compliance mapping.
In-platform posture
Your Terraform is also scanned during your regular Tier-1 scan; findings land on your Findings dashboard tagged *IaC Misconfiguration*, sitting next to the live cloud finding for the same resource: "public in the *code* and confirmed public in the *running account*."
Coverage
| Cloud | Native-rule examples |
|---|---|
| AWS | public S3 ACL/PAB, unencrypted RDS/EBS, open security groups, IAM wildcard admin, IMDSv2 not enforced |
| GCP | public Storage/IAM, open firewall (SSH/RDP), public Cloud SQL, GKE legacy ABAC |
| Azure | public Storage/weak TLS, open NSG, public SQL + firewall, Key Vault purge-protection |
| + CloudFormation & Kubernetes | S3/RDS, privileged containers, hostPath, :latest, missing limits/probes |
Formats (15+): Terraform (.tf/.tfvars, real HCL2), CloudFormation (YAML/JSON), Kubernetes, Helm, Dockerfile, Azure ARM, Ansible, Pulumi, Google Deployment Manager, Crossplane, OpenAPI/Swagger, Knative, gRPC, CI/CD pipelines, Docker Compose and serverless.
Known limitations
- Read-only — it parses files and never touches your cloud.
- Your code is not stored. The CI endpoint is stateless — files are parsed in memory and discarded; only the findings come back. The in-platform surface stores findings, not source.
- Up to 100 files / 5 MB per request.
- No self-serve repo connect yet — the Terraform we scan is configured with your team during onboarding; a "Connect repository / upload Terraform" experience is on the near-term roadmap.
- The API key is tenant-scoped — scans and findings stay isolated to your workspace.
Next step
On a call we'll cover CI wiring for your stack, the thresholds you want enforced, and how correlation lands against your accounts. Talk to us about deployment
Related: API Reference · Scanning Tiers · Compliance