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