Posted inSecurity

Nipping Cloud Vulnerabilities in the Bud with Checkov

Security tutorial - IT technology blog
Security tutorial - IT technology blog

The Nightmare of “Infrastructure Vulnerabilities”

Having personally participated in security audits for over 10 projects of various sizes, I’ve realized a harsh truth: most serious vulnerabilities don’t reside in the application code. Once, I was stunned to find an S3 bucket containing 500GB of customer ID photos set to Public. In another instance, a Kubernetes cluster allowed Pods to run with root privileges, leaving the door wide open for hackers to take control of the entire node.

These mistakes often stem from Infrastructure as Code (IaC) configuration files. When managing infrastructure with Terraform or CloudFormation, a single line of bad code can replicate errors across hundreds of cloud resources in seconds.

Why Waiting Until After Deployment to Scan for Security is a Mistake

According to Gartner, by 2025, over 95% of cloud security incidents will be caused by user misconfigurations. The traditional workflow—Write code -> Deploy -> Runtime security scan—is both costly and leaves the system exposed during the waiting period.

Three biggest barriers to IaC security being ignored:

  • Release pressure: Prioritizing functionality over security.
  • Defaults aren’t always secure: Many Cloud services have loose default configurations to make them more accessible to users.
  • Massive configuration files: When a Terraform file exceeds 2,000 lines, manual review is like finding a needle in a haystack.

If you find a bug after deployment, you have to waste time rolling back and fixing it. Worse, sensitive data could be leaked during those few minutes of exposure.

Three Common Approaches to IaC Security

Currently, DevOps teams usually choose one of three options:

  1. Manual Review: Thorough but slow and prone to human error.
  2. External Audits: Expensive and usually done quarterly or annually, failing to keep up with CI/CD speed.
  3. Static Analysis: The optimal choice. Tools scan IaC files as soon as you finish coding, stopping risks before resources are even created.

Checkov: A Powerful Ally for DevOps

In the world of Static Analysis, Checkov has emerged as the gold standard. It is an open-source tool developed by Bridgecrew (now part of Palo Alto Networks). It provides comprehensive support for everything from Terraform, CloudFormation, and Kubernetes to Dockerfiles and Helm charts.

Checkov boasts a library of over 1,000 security policies based on CIS Benchmarks. It doesn’t just report errors; it points to the exact line of violating code and provides links to detailed remediation guides.

Quick 30-Second Installation

You can install Checkov via pip very quickly. I usually install it locally to check my code before committing.

pip install checkov

If you prefer to avoid a manual installation, Docker is the cleanest solution:

docker pull bridgecrew/checkov
docker run -v /path/to/your/code:/tf bridgecrew/checkov -d /tf

Hands-on 1: Scanning Terraform for Errors

Let’s look at the main.tf file below. It looks normal at first glance, but it contains a “time bomb.”

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  
  # Unencrypted hard drive
  ebs_block_device {
    device_name = "/dev/sda1"
    volume_size = 20
  }
}

Run the scan command in the directory:

checkov -d .

Checkov will immediately report **FAILED** with error code CKV_AWS_3. The message will require you to encrypt the EBS volume to protect data in case the server is compromised.

Hands-on 2: Checking Kubernetes Configurations

With Kubernetes, Checkov is extremely sensitive to privilege escalation issues. Try scanning this pod.yaml file:

spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true # Extremely serious error

Checkov will “scream” because the privileged: true flag allows the container to interact deeply with the host machine’s kernel. You will be prompted to disable this flag or use Pod Security Standards.

Tips for Suppressing Warnings

Sometimes you might accept a risk in a Dev environment to save costs (e.g., no need for disk encryption on a test volume). To prevent Checkov from breaking your pipeline, add a comment directly to the code:

resource "aws_instance" "web_server" {
  # checkov:skip=CKV_AWS_3: Temporarily skip for sandbox environment
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Integrating Checkov into GitHub Actions Pipelines

For true peace of mind, you should integrate Checkov into your CI/CD. If a High-level error is detected, the pipeline will automatically stop, preventing code from being merged into the main branch.

name: Checkov Security Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          soft_fail: false # Break the pipeline if errors are found

Conclusion

Infrastructure security isn’t a one-time task; it’s a coding habit. Checkov won’t protect your system against 100% of sophisticated attacks, but it will certainly eliminate 90% of common, silly mistakes.

My advice: Don’t wait until you get a warning email from AWS or see your data for sale online. Install Checkov today. You’ll be surprised at how “exposed” your repo actually is.

Share:
Tags: