Using Checkov to Scan Terraform for Insecure Infrastructure Configurations

Your Terraform Can Be Insecure: A Practical Look at Checkov

Infrastructure as Code makes cloud deployment faster and more consistent, but it also makes mistakes repeatable. A single insecure setting can be deployed again and again if nobody catches it early. When developers think about bugs, they usually imagine broken features, failed requests, or unexpected behavior in application code. But infrastructure can also have bugs, especially when it is defined with tools like Terraform. That matters because a Terraform file can be valid and still be unsafe. A resource may deploy correctly, but if it exposes data, opens unnecessary access, or skips important security controls, the real problem is not syntax — it is configuration. In this article, the focus is on a practical question: how can developers detect insecure infrastructure definitions before deployment? A useful answer is Checkov, a static analysis tool that scans Infrastructure as Code and helps identify cloud misconfigurations early. Why infrastructure can also have “bugs” When infrastructure is written as code, it becomes part of the software lifecycle. It is reviewed, versioned, reused, and deployed automatically, just like backend or frontend code. That also means it can include mistakes such as: public storage buckets, overly permissive security groups, databases exposed to the internet, missing encryption, or excessive IAM permissions. These issues are dangerous because they often do not break deployment. Terraform may apply the configuration successfully, but the cloud environment can still be insecure. This is why infrastructure bugs are different from application bugs. They do not always crash the system — sometimes they quietly create risk. Why static analysis matters for Terraform Static Application Security Testing, or SAST, means analyzing code without executing it. OWASP explains that source code analysis tools help identify possible vulnerabilities before software is released. That idea also applies to Infrastructure as Code. Terraform files are still source files, and they describe how systems will be provisioned, connected, and exposed. If a bad practice is written into the code, the same bad practice can be reproduced every time the infrastructure is deployed. This is one of the reasons DevSecOps promotes shift-left security. Instead of waiting for an audit or a production incident, teams detect problems while building the infrastructure. In simple terms: if application code deserves early security checks, infrastructure code does too. Why Checkov is a practical choice Checkov is a static analysis tool focused on Infrastructure as Code. Its goal is to detect misconfigurations and policy violations before cloud resources are created. One reason it is attractive for the community is that it is practical. It gives direct feedback about what is wrong, where it appears, and why it matters. That makes it useful not only for security specialists, but also for developers and students who are learning how to build safer cloud environments. Another advantage is that it fits modern workflows. It can be executed locally while coding or integrated into CI/CD pipelines so every infrastructure change is scanned automatically. That turns security into part of the development process instead of leaving it for the end. A simple example: valid Terraform, insecure result Consider this Terraform snippet: resource "aws_s3_bucket" "assets" { bucket = "project-assets-demo" acl = "public-read" } From Terraform’s perspective, this is valid. The bucket can be created without syntax errors, and the deployment may succeed [web:50][web:58]. But from a security perspective, public-read may expose files that should not be accessible to everyone. This is the kind of issue a tool like Checkov is meant to detect early, before the infrastructure reaches production. This example shows a very important lesson: Valid code is not always secure code. Successful deployment is not always safe deployment. That is exactly why static analysis matters. What Checkov helps you discover When Checkov scans Terraform files, it typically reports: the file where the issue appears, the rule that was triggered, and the reason the configuration may be risky. This kind of feedback is valuable because it is actionable. Instead of a vague warning, developers get concrete information they can use immediately to improve the infrastructure. That is especially useful in real projects where teams work fast and small mistakes can spread across multiple environments. For example, if the same Terraform module is reused in development, testing, and production, a single insecure pattern can be repeated several times. Static scanning helps catch that before it scales into a larger problem. Why this matters in DevOps and CI/CD In many teams, infrastructure changes are deployed through automated pipelines. That means risky configurations can move from repository to cloud very quickly if there is no security validation in the workflow. Running Checkov in CI/CD helps teams review infrastructure before merge or deployment. This supports a shift-left model, where issues are fixed earlier, faster, and usually at lower cost. A practical workflow would look like this: A developer writes or updates Terraform code. Checkov scans the files locally or in a pull request pipeline. The tool reports risky configurations. The team fixes the findings before deployment. This is a simple but effective way to reduce avoidable cloud exposure. It is helpful, but not magical Static analysis is powerful, but it is not perfect. It cannot fully understand runtime behavior, business logic, or every relationship between services. It can also produce false positives, especially in complex environments. Because of that, Checkov should be treated as one layer of security, not the only layer. The strongest approach combines: static analysis, code review, least privilege, secure defaults, runtime monitoring, and broader security validation. Security works better when multiple layers support each other. Why developers should care This is not only a topic for security teams. Anyone who writes Terraform is also making security decisions, even if that is not always obvious. Learning to scan IaC early helps developers build better habits. It creates awareness about permissions, exposure, encryption, and cloud design from the beginning of the project rather than at the end. That habit matters because secure infrastructure is not created by accident. It is created by reviewing code carefully and validating it before deployment. Final thoughts Terraform is powerful because it makes infrastructure repeatable. But that same strength can also repeat insecure configurations if they are not caught in time. Using Checkov helps detect those risks before deployment. It does not replace human review, but it does provide an early warning system that improves security where it matters most: in the code itself. If the cloud is built from code, then cloud security must also begin in code.

10 hours ago

Applying Checkov SAST to Detect Security Issues in Terraform Infrastructure as Code

Introduction Security issues in cloud infrastructure often start as small configuration mistakes. A public network rule, a missing encryption setting, or an overly permissive policy can create serious risk when infrastructure is deployed. This demo project shows how to use Checkov as a Static Application Security Testing tool for Terraform Infrastructure as Code. The goal is academic and practical: detect insecure Terraform configuration before deploying anything to the cloud. What is Infrastructure as Code? Infrastructure as Code, or IaC, is the practice of defining infrastructure using code. Instead of manually creating cloud resources through a web console, teams describe resources in files that can be versioned, reviewed, tested, and automated. Terraform is one of the most popular IaC tools. It allows teams to define providers, networks, storage, compute resources, permissions, and other infrastructure components using declarative configuration files. What is SAST for IaC? Static Application Security Testing normally means analyzing source code without running it. For IaC, the same idea applies to infrastructure definitions. A scanner can inspect Terraform files and identify risky patterns before the infrastructure is created. This is useful because security feedback arrives earlier in the development lifecycle. Developers and DevOps teams can fix misconfigurations before they become real cloud exposure. Why Checkov? Checkov is a static analysis tool designed for Infrastructure as Code. It supports Terraform and can detect issues such as public access, missing encryption, weak network rules, and insecure cloud service configuration. For this project, Checkov is a good fit because it is simple to run locally, easy to integrate into GitHub Actions, and focused on IaC security scanning. Vulnerable Terraform demo The vulnerable Terraform file defines an AWS provider, a security group, and an S3 bucket. The file is intentionally insecure for demonstration purposes only. One important issue is SSH exposed to the entire internet: ingress { description = "Insecure SSH access from anywhere" from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } SSH open to 0.0.0.0/0 is insecure because any public IP address can attempt to connect. This increases the attack surface and can expose servers to brute-force attacks, credential attacks, and unauthorized access attempts. The vulnerable version also includes fully open outbound traffic: egress { description = "Overly permissive outbound access" from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } Fully open egress is too permissive because it allows outbound traffic to any destination, using any protocol and port. In a real environment, this can make data exfiltration or unauthorized external communication easier. The S3 bucket is also basic and does not define extra protections such as public access blocking or explicit encryption: resource "aws_s3_bucket" "vulnerable_bucket" { bucket = "checkov-sast-demo-vulnerable-bucket" } Running Checkov locally Checkov can be installed and executed with Python: python -m pip install checkov checkov -d . --framework terraform --skip-path venv checkov -d . --framework terraform --skip-path venv -o cli > checkov-report.txt The -d . option tells Checkov to scan the current directory. The -o cli option prints the report in command-line format, and the final command stores the output in a text report. Explaining findings Checkov analyzes the Terraform files and compares them with security policies. In this demo, it should identify risky patterns such as public SSH exposure, missing S3 security controls, and overly permissive network configuration. These findings matter because infrastructure misconfigurations can become real vulnerabilities after deployment. Detecting them statically helps reduce risk before cloud resources exist. Secure Terraform version The secure Terraform version restricts SSH to a trusted example IP address: ingress { description = "SSH access from a trusted example IP" from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["203.0.113.10/32"] } The 203.0.113.10/32 address is documentation-only example IP space. In a real project, this should be replaced with an approved corporate VPN, bastion host, or administrative IP range. The secure file also restricts egress to HTTPS: egress { description = "HTTPS outbound access only" from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } For S3, the secure version enables public access blocking: resource "aws_s3_bucket_public_access_block" "secure_bucket_public_access" { bucket = aws_s3_bucket.secure_bucket.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true } Blocking public access helps prevent accidental exposure of data. This is especially important because S3 buckets are commonly used to store sensitive application, backup, log, or user data. The secure version also enables server-side encryption: resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket_encryption" { bucket = aws_s3_bucket.secure_bucket.id rule { apply_server_side_encryption_by_default { sse_algorithm = "AES256" } } } S3 encryption is a good practice because it protects stored objects at rest. Even when access controls are also required, encryption adds another layer of defense. GitHub Actions automation The project includes a GitHub Actions workflow that runs Checkov automatically on pushes and pull requests to the main branch: name: Checkov IaC SAST Scan on: push: branches: - main pull_request: branches: - main jobs: checkov: name: Run Checkov runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Run Checkov Terraform scan uses: bridgecrewio/checkov-action@master with: directory: . framework: terraform output_format: cli soft_fail: true Integrating Checkov into GitHub Actions improves the DevSecOps workflow because every change can be scanned automatically before it is merged. This helps teams detect insecure Terraform code during code review instead of after deployment. In this academic demo, soft_fail: true is used because the repository intentionally contains vulnerable Terraform code. This setting keeps the pipeline successful while still displaying the security findings in the workflow logs. Conclusion This project demonstrates how Checkov can be used to detect security issues in Terraform Infrastructure as Code. The vulnerable version shows common cloud misconfigurations, while the secure version demonstrates safer alternatives. By combining local scanning with GitHub Actions automation, teams can introduce security checks early and continuously in the CI/CD process. GitHub repository link placeholder GitHub repository: https://github.com/Abel-GG-777/checkov-terraform-sast-demo.git

21 hours ago