Under the Hood: How Bandit SAST Analyzes Your Python Code

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 16:10:54 +0000

Abstract
While many developers use security scanners, few understand how they actually "read" code. This article explains the inner workings of Bandit, focusing on its use of the Abstract Syntax Tree (AST) to identify security patterns without ever executing a single line of code.

1. The Core Engine: AST (Abstract Syntax Tree)
Unlike a simple text search (which might give many false positives), Bandit doesn't just look for words like "password". It converts your Python code into an AST.

What is AST? It is a tree representation of the abstract syntactic structure of your source code.

Why it matters: By building a tree, Bandit understands the context. It knows if a string is just a comment or if it's actually being assigned to a sensitive variable or passed to a dangerous function like eval().

2. How the "Scanning" Happens
Bandit works through a set of plugins. Each plugin is designed to look for a specific type of vulnerability:
Blacklist Plugins: These look for the use of insecure modules (like pickle or telnetlib).
Function Call Plugins: These trigger when they see dangerous calls (like subprocess.shell=True).
Hardcoded Secret Plugins: These use heuristics to identify strings that look like passwords or API keys.

3. Severity and Confidence levels
One of Bandit's best features is its scoring system:
Severity: How bad is the bug? (Low, Medium, High).
Confidence: How sure is Bandit that this is actually a bug and not a mistake?

Why use it in the CI/CD?
The main advantage is speed. Because it doesn't need to compile or run the code, it can scan thousands of lines in seconds. Integrating it into GitHub Actions (as shown in my previous post) ensures that no "illegal" AST patterns make it into the main branch.

Conclusion
Bandit isn't just a linter; it's a security-focused parser. By understanding the structure of Python, it provides a robust first line of defense for any backend developer.

Implementing SAST in Your Infrastructure: Detecting Vulnerabilities with Checkov and GitHub Actions

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 03:50:44 +0000

Abstract
This article explores the implementation of Static Application Security Testing (SAST) for Infrastructure as Code (IaC) using Checkov. We demonstrate how to identify common security misconfigurations, such as publicly accessible S3 buckets, and seamlessly integrate the scanning process into a CI/CD pipeline using GitHub Actions.

What is Checkov?
Checkov is an open-source static analysis tool (maintained by Bridgecrew / Prisma Cloud) designed specifically for Infrastructure as Code.

Unlike tools aimed at application code (like Bandit for Python), Checkov scans configuration files for misconfigurations that could lead to security vulnerabilities or compliance issues.

Why use Checkov?

Built-in policies: It comes with hundreds of out-of-the-box policies covering AWS, Azure, and GCP best practices.
Multi-framework: Supports Terraform, CloudFormation, Kubernetes, Dockerfiles, Serverless, and more.
Easy integration: Runs from the command line or directly in your CI/CD pipelines.

The Scenario: Vulnerable Infrastructure

Imagine you have a Terraform file (main.tf) where you define an S3 bucket. By mistake (or for a quick test), you configure it to have public read access:

# main.tf resource "aws_s3_bucket" "my_vulnerable_bucket" { bucket = "my-dev-test-bucket" acl = "public-read" # ❌ Security risk! }

If we deploy this, anyone on the internet could access our data. Let's make our repository catch this error before it gets merged into the main branch.

Automating with GitHub Actions
The real magic happens when we integrate Checkov into our CI/CD workflow. This way, every time someone pushes code or opens a Pull Request, Checkov will analyze the infrastructure automatically.

In your repository, create a file at .github/workflows/checkov.yml and add the following:

What exactly does this workflow do?

1. Checkout: Clones your code into the GitHub Actions virtual environment.
2. Run Checkov: Uses the official Bridgecrew action. The directory: . parameter tells it to look for infrastructure files throughout the repository.
3. soft_fail: false: This is the key to DevSecOps. If Checkov finds a failing policy (like our public bucket), the pipeline will fail, preventing vulnerable code from being integrated.

Conclusion
Shifting security to the left (Shift-Left Security) by implementing SAST in your Infrastructure as Code is no longer optional. With tools like Checkov and GitHub Actions, it's a fast and highly effective process. With just a few lines of code, you can ensure your team doesn't accidentally deploy insecure configurations.

Forem: RODRIGO SIDNEY COLQUE QUISPE

Under the Hood: How Bandit SAST Analyzes Your Python Code

Implementing SAST in Your Infrastructure: Detecting Vulnerabilities with Checkov and GitHub Actions