Demystifying SAST for IaC: How Does Checkov Actually Work Under the Hood?

FABRICIO FARID EDMILSON RAMOS ATAHUACHI — Tue, 21 Apr 2026 05:42:19 +0000

Abstract
This article dives deep into the internal architecture of Static Application Security Testing (SAST) tools focused on Infrastructure as Code (IaC). We break down step-by-step how Checkov parses source code, builds dependency graphs, and evaluates security policies to detect complex vulnerabilities before deployment.

In previous articles, we explored how to integrate tools like Checkov into our CI/CD pipelines using GitHub Actions. We know that if we feed it a Terraform or Kubernetes file, it magically returns a list of vulnerabilities.

But as engineers, we don't like magic. How exactly does Checkov know that an S3 bucket is misconfigured? Does it just look for the string "public-read" using Regular Expressions (Regex)?

The short answer is: no. Using Regex to analyze infrastructure would be a complete disaster due to the complex relationships between resources. Let's look at how modern Static Analysis actually works under the hood.

The Static Analysis Process (Step-by-Step)
The engine powering Checkov (and most advanced SAST tools) is written in Python and operates in three main phases: Parsing, Graph Construction, and Policy Evaluation.

1. Parsing and the AST (Abstract Syntax Tree)
Checkov's first challenge is that Infrastructure as Code comes in many "flavors": HCL (Terraform), YAML (Kubernetes/CloudFormation), JSON, etc.

Checkov takes your source code and uses language-specific parsers. The goal of this parser is not to look for errors just yet, but to transform your plain text code into a standardized data structure in memory—typically a Python dictionary or an Abstract Syntax Tree (AST).

# Original Terraform Code resource "aws_s3_bucket" "my_bucket" { bucket = "sensitive-data" acl = "public-read" }
2. Resource Graph Construction (Graph Database)
This is where the tool truly shines. In the cloud, resources are almost never isolated. A Security Group connects to an EC2 instance, and that instance connects to a Database.

If Checkov evaluated files line by line, it would lose all this context. To solve this, it uses a Python library called NetworkX to build a directed graph in memory.

Nodes: Represent the resources (e.g., the S3 bucket, the IAM user).

Edges: Represent the relationships between them (e.g., "User X has permissions on Bucket Y").

3. Policy Evaluation
Once the code has been converted into a comprehensible graph, Checkov begins running its "Policies" against it.

Policies in Checkov are small scripts written in Python (or defined in YAML). These rules scan the node attributes in the graph looking for specific risk patterns.

For example, the internal logic of a Checkov policy for AWS S3 would conceptually look like this:

The Graph-Based Engine: Why is it crucial?
Imagine a complex scenario: You have an S3 bucket that is set to private, but in a completely different file in your project, you create an IAM policy that grants public access to that specific bucket.

If Checkov used Regex or read files in isolation, it would report the bucket as secure. However, because it built a graph connecting the IAM policy to the Bucket via cross-references, the analysis engine can traverse the nodes and detect the compounded vulnerability.

Conclusion
SAST tools like Checkov are much more than simple linters looking for keywords. They are fully-fledged code analysis engines that build relational models of our infrastructure in memory to apply logical rules.

Understanding this workflow doesn't just help you appreciate the engineering behind DevSecOps tools; it opens the door to the next level: writing your own custom Python policies to audit specific business rules your team needs to enforce.

Implementing SAST in Python: Detecting Vulnerabilities with Bandit

FABRICIO FARID EDMILSON RAMOS ATAHUACHI — Mon, 20 Apr 2026 18:21:07 +0000

Abstract

This article explores the implementation of Static Application Security Testing (SAST) using Bandit for Python applications. We demonstrate how to identify common security flaws like hardcoded passwords and insecure function usage, integrating the tool into a CI/CD pipeline using GitHub Actions.

Why Bandit?

Since I needed a lightweight and fast tool for Python without the complexity of enterprise platforms, Bandit was the perfect choice. It’s an open-source tool designed to find common security issues in Python code by analyzing the AST (Abstract Syntax Tree).

The Vulnerable Code

I created a sample script app.py with intentional flaws:

Hardcoded secrets: Storing passwords in plain text.
Insecure Deserialization: Using functions that could lead to Remote Code Execution (RCE).

Local Execution

To run it locally, I used:

pip install bandit
bandit app.py

The image below demonstrates the local execution of Bandit. As shown, the tool scanned 6 lines of code and identified 3 security issues: two of Low severity (importing the pickle module and a hardcoded password string) and one of Medium severity (using pickle.loads for deserialization). This immediate feedback allows developers to fix vulnerabilities during the development phase, long before the code is merged.
"Figure 1: Local Bandit Scan Results"

Automation with GitHub Actions
To comply with modern DevSecOps practices, I automated the scan. Every time I push code, GitHub Actions runs Bandit.

YAML
My workflow configuration

"Figure 2: Yml configuration"

This image displays the output of the automated security pipeline. By integrating Bandit into GitHub Actions, the scan runs automatically on every 'push'. As observed in the logs, the process completed with an exit code 1, effectively breaking the build. This is a crucial security gate: it prevents code with known vulnerabilities (like the insecure yaml.load call shown in line 13) from moving forward in the development lifecycle. The report highlights a Medium severity issue with High confidence, providing the exact CWE reference for remediation.

"Figure 3: Automated SAST Scan via GitHub Actions"

Conclusion
Using SAST tools like Bandit is a fundamental step in the SDLC to catch "low-hanging fruit" vulnerabilities before they reach production.

DEV Community: FABRICIO FARID EDMILSON RAMOS ATAHUACHI

Demystifying SAST for IaC: How Does Checkov Actually Work Under the Hood?

Implementing SAST in Python: Detecting Vulnerabilities with Bandit