How do you scan Infrastructure as Code (IaC) files with Trivy?

Scanning Infrastructure as Code with Trivy is like having a building code inspector review your architectural drawings before construction starts. Instead of discovering that a wall lacks fire-resistant material after the building is finished (deployed to production), the inspector catches it during the design phase when corrections cost almost nothing. Trivy's IaC scanning catches security misconfigurations in your infrastructure definitions before they become running resources.

The trivy config command scans directories containing IaC files for security misconfigurations. Trivy supports a wide range of IaC formats: Terraform HCL and plan files, Kubernetes YAML manifests, Dockerfiles, AWS CloudFormation templates (JSON and YAML), Helm charts, and Docker Compose files. When you run trivy config on a directory, Trivy automatically detects the file types and applies the relevant security policies. For example, scanning the Terraform directory for your payments-api infrastructure might flag an S3 bucket without encryption enabled, a security group with port 22 open to the world, or an RDS instance without backup retention configured.

The misconfiguration checks are powered by built-in policies written in Rego, the policy language used by Open Policy Agent (OPA). Trivy ships with hundreds of pre-built checks organized by cloud provider and service. For AWS, checks cover IAM policies, security groups, S3 bucket configurations, RDS settings, and more. For Kubernetes, checks cover pod security contexts, resource limits, network policies, and RBAC configurations. Each check has a severity level (CRITICAL, HIGH, MEDIUM, LOW), a description of the issue, a recommended fix, and links to relevant compliance frameworks like CIS Benchmarks, NIST, and PCI-DSS. Teams can also write custom Rego policies for organization-specific requirements, like ensuring all Kubernetes deployments for checkout-service include specific labels or annotations.

In production, teams integrate trivy config into their CI pipelines alongside terraform plan and kubectl diff. For a typical workflow managing infrastructure for order-processing-service, the pipeline runs terraform plan to generate a plan file, then trivy config scans the Terraform directory to catch misconfigurations before terraform apply executes. This prevents insecure infrastructure from ever being provisioned. Some teams go further by scanning Helm chart values files before deploying to Kubernetes, ensuring that security contexts, resource limits, and network policies are correctly configured for services like user-auth-service and inventory-sync. The --exit-code flag works the same as with image scanning, allowing teams to fail the pipeline when misconfigurations exceed their risk tolerance.

A beginner mistake is confusing IaC scanning with vulnerability scanning. Trivy's config scanner looks for misconfigurations in how infrastructure is defined, not for CVEs in software packages. A Terraform file might have a perfectly valid syntax but define an IAM role with wildcard permissions, which is a misconfiguration that trivy config would catch. Conversely, trivy config will not tell you if the Terraform provider plugin itself has a known vulnerability. For comprehensive security, teams run both trivy config on IaC files and trivy image on the container images those IaC files deploy.