DEV Community: Kiara Holly Zapana Murillo

SQL seguro con IA: cómo construir un asistente que valida las consultas antes de ejecutarlas

Kiara Holly Zapana Murillo — Sun, 05 Jul 2026 06:33:44 +0000

Introducción

Escribir SQL a mano es una de esas habilidades que, sin querer, deja fuera a mucha gente del mundo de los datos. Product managers, agentes de soporte e incluso desarrolladores junior muchas veces saben exactamente qué quieren preguntarle a una base de datos, pero no siempre saben cómo expresarlo sintácticamente en SQL.

Los sistemas Text-to-SQL intentan resolver justamente ese problema: convertir una pregunta en lenguaje natural en una consulta real, devolviendo los datos sin fricción.

Sin embargo, generar SQL automáticamente no es el final del problema, es apenas el principio. Un modelo de lenguaje (LLM) puede producir una consulta sintácticamente correcta y aun así completamente equivocada a nivel semántico: un join mal hecho, un filtro incorrecto, o —en el peor de los casos— un intento de modificar datos que solo debían leerse.

En este artículo construyo un asistente de IA para SQL que no solo genera consultas, sino que las valida de forma determinista antes de ejecutarlas. Para ello utilizo smolagents de Hugging Face como capa de razonamiento, y una capa de seguridad propia (un SQL Guard) como filtro final antes de que cualquier consulta toque la base de datos.

El código fuente completo de este proyecto está disponible en el repositorio público enlazado al final del artículo.

¿Por qué no basta con pedirle SQL a un LLM?

El pipeline más simple de Text-to-SQL se ve así:

Enviar el esquema de la base de datos y la pregunta del usuario a un LLM.
Pedirle al LLM que devuelva una consulta SQL.
Ejecutar esa consulta a ciegas y mostrar el resultado.

Esto funciona… hasta que deja de funcionar. El problema radica en que una sola llamada al LLM es frágil: el modelo puede generar una consulta válida en sintaxis pero incorrecta en significado, y el sistema la ejecutará igual, sin ningún mecanismo para detectar el error.

Peor aún, en un entorno real nada impide que el modelo intente inyectar un DELETE o un UPDATE si no se le prohíbe explícitamente a nivel de sistema. Decírselo únicamente en el prompt no es una garantía de seguridad, es una sugerencia que el modelo puede ignorar. Ese es exactamente el vacío arquitectónico que este proyecto busca cerrar.

¿Qué es smolagents y por qué es relevante aquí?

smolagents es un framework de agentes ligero de Hugging Face, descrito por sus propios creadores como "una librería minimalista para agentes que piensan en código". En lugar de forzar al modelo a producir llamadas a herramientas en un JSON rígido, un CodeAgent escribe y ejecuta código Python real como parte de su ciclo iterativo de razonamiento:

Pensar: el modelo razona sobre qué hacer a continuación.
Actuar: escribe código Python que invoca una herramienta (en nuestro caso, un motor SQL).
Observar: el resultado de esa herramienta vuelve al contexto del modelo.
Repetir o responder: el agente decide si necesita ajustar la consulta (por ejemplo, si hubo un error de sintaxis) o si ya puede entregar la respuesta final.

Ese ciclo es extremadamente útil, pero no es suficiente por sí solo. Un agente puede autocorregirse ante resultados sospechosos, pero no sabe, por diseño, qué acciones son destructivas para tu lógica de negocio. Esa responsabilidad la debe asumir una capa adicional y determinista: el validador.

Arquitectura de la solución

En lugar de ejecutar directamente cualquier SQL que el modelo proponga, diseñamos un sistema con el siguiente flujo:

El usuario hace una pregunta en lenguaje natural.
El agente de IA propone una consulta SQL tras razonar sobre el esquema.
Un validador estricto intercepta y revisa esa consulta.
Solo se ejecutan consultas SELECT catalogadas como seguras.
El resultado se procesa y se devuelve al usuario.

Ese paso adicional —la validación— es lo que eleva una simple demostración técnica a un asistente que realmente podrías conectar a datos reales en producción.

Usuario ──▶ Agente (smolagents) ──▶ SQL Guard ──▶ Base de datos
                 │                       │
             razona y                rechaza si
             propone SQL             no es seguro

Construyendo el proyecto: base de datos de ventas

Para mantener el ejemplo reproducible, utilizo una base de datos SQLite con dos tablas sencillas: customers y sales.

1. Definiendo el esquema

CREATE TABLE customers (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    city TEXT NOT NULL
);

CREATE TABLE sales (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER,
    order_date TEXT,
    total_amount REAL,
    FOREIGN KEY (customer_id) REFERENCES customers(id)
);

2. Cargando datos de ejemplo (semilla)

INSERT INTO customers (id, name, city) VALUES
(1, 'Alan Payne', 'Lima'),
(2, 'Marta Lopez', 'Arequipa');

INSERT INTO sales (id, customer_id, order_date, total_amount) VALUES
(1, 1, '2026-07-01', 120.50),
(2, 2, '2026-07-02', 89.99);

3. Conexión en Python

import sqlite3

def get_connection():
    conn = sqlite3.connect("safe_sql_demo.db")
    return conn

La pieza clave: el validador de SQL (SQL Guard)

Esta es la parte fundamental del proyecto y lo que marca la diferencia frente a un Text-to-SQL básico. Antes de ejecutar cualquier consulta generada por el agente, la instrucción debe sortear este filtro en Python:

BLOCKED = ["DROP", "DELETE", "UPDATE", "INSERT", "ALTER"]

def is_safe_sql(query: str) -> bool:
    q = query.strip().upper()

    # Prevenir ataques de inyección encadenada
    if ";" in q[:-1]:
        return False

    # Exigir explícitamente operaciones de solo lectura
    if not q.startswith("SELECT"):
        return False

    # Bloquear palabras clave destructivas, incluso en subconsultas
    return not any(word in q for word in BLOCKED)

Este validador aplica tres reglas deterministas innegociables:

Solo se permite SELECT.
No se permiten múltiples sentencias encadenadas.
Se bloquean palabras destructivas en cualquier parte de la cadena, incluso dentro de subconsultas.

Integrando el agente con el validador

El flujo de ejecución intercepta la petición del agente de esta forma:

from db import get_connection
from validator import is_safe_sql

def ask_database(question: str, generated_sql: str) -> str:
    # Capa de seguridad
    if not is_safe_sql(generated_sql):
        return "Consulta bloqueada por el validador: operación no permitida."

    # Ejecución aprobada
    try:
        with get_connection() as conn:
            rows = conn.execute(generated_sql).fetchall()
        return str(rows)
    except Exception as e:
        return f"Error SQL: {e}"

Aquí radica la diferencia arquitectónica: el modelo LLM puede alucinar, o el usuario puede intentar inyectar código malicioso a través del prompt, pero la aplicación retiene la autoridad final de decidir si esa sugerencia llega a ejecutarse. El agente asiste; el sistema controla.

Ejemplo de uso

Si un usuario pregunta de buena fe:

¿Cuál es el total de ventas por mes?

El agente generará algo como:

SELECT strftime('%Y-%m', order_date) AS month,
       SUM(total_amount) AS total
FROM sales
GROUP BY month
ORDER BY month;

El validador revisa que sea un SELECT seguro, la aprueba y el sistema devuelve el resultado real.

¿Qué pasa ante un ataque o una alucinación del modelo?

Si el agente, o el usuario a través del prompt, intentara ejecutar DELETE FROM sales WHERE total_amount > 100;, el validador lo rechazaría en milisegundos, devolviendo la alerta de seguridad sin llegar siquiera a tocar el motor de base de datos.

Prompt directo al LLM vs. agente con validación

Criterio	LLM directo (zero-shot)	Agente + validador
Generación	Un solo intento, sin retroalimentación	Iterativa, con capacidad de corrección
Manejo de errores	Devuelve respuestas erróneas en silencio	Se detiene y bloquea ante operaciones dudosas
Seguridad	Depende de la "buena voluntad" del prompt	Aplicada estrictamente a nivel de código
Auditabilidad	Consulta oculta en la respuesta	Consulta explícita y lista para hacer log
Confiabilidad en producción	Baja	Considerablemente más alta

La conclusión es clara: un validador no elimina el riesgo inherente de la IA, pero lo mitiga, transformando una decisión implícita del modelo en una regla explícita del sistema.

Seguridad: consideraciones adicionales para producción

Además del SQL Guard propuesto, cualquier solución real a nivel corporativo debe contemplar:

Mínimo privilegio (DB roles): conectar a la base de datos usando un rol restringido que físicamente solo tenga permisos de SELECT, jamás como administrador.
Vistas en lugar de tablas crudas: exponer a la IA únicamente views curadas, ocultando columnas con contraseñas o datos personales sensibles (PII).
Límites inyectados (LIMIT): forzar programáticamente un LIMIT 50 al final de cada consulta válida para evitar que un modelo escanee accidentalmente millones de filas.
Registro (logging): guardar cada pregunta, la consulta generada y su latencia, para poder auditar el uso de la herramienta con el tiempo.

Casos de uso reales

Dashboards dinámicos — dejar que los usuarios de negocio generen agregaciones seguras sobre la marcha, sin depender del equipo de ingeniería.
Plataformas de soporte — permitir a los agentes buscar datos operativos de clientes mediante lenguaje natural, bajo políticas de lectura estricta.
Proyectos académicos y de investigación — fomentar el uso de bases de datos relacionales eliminando la fricción de la sintaxis SQL, sin comprometer la integridad de los datos.

Conclusión

El uso de arquitecturas Text-to-SQL demuestra que delegar tareas a modelos fundacionales requiere de ingeniería de software defensiva. La diferencia entre un prompt llamativo y un sistema validado es, en última instancia, la diferencia entre una demo y un sistema productivo.

El enfoque basado en código de smolagents vuelve el razonamiento del LLM transparente y auditable. Si le sumamos una capa de validación SQL, logramos trasladar la seguridad del prompt volátil a una regla de infraestructura confiable, que no depende de que el modelo se comporte bien.

Repositorio público:
El código funcional completo de este proyecto (base de datos, validador, orquestación y demostración) está disponible en mi cuenta de GitHub:
🔗 https://github.com/KiaaraZM/safe-sql-ai

Referencias

Postman + Newman: How to Build a Practical API Testing Workflow with Real Code

Kiara Holly Zapana Murillo — Tue, 30 Jun 2026 03:57:58 +0000

Abstract

API testing is one of the fastest ways to verify that a system works the way it should. A well-designed API test does not only check whether a request returns a response; it also validates status codes, response bodies, headers, environment variables, and end-to-end behavior across several requests. In this article, I use Postman to design and organize an API test collection and Newman to run those tests from the command line as part of a repeatable workflow. The example focuses on a small real-world style API for users and tasks, with requests that create data, read it back, and validate the results. I also show how the same collection can be executed locally and inside a CI/CD pipeline. The purpose is to demonstrate that API testing can be practical, readable, and automation-friendly without becoming overly complex.

Introduction

Modern applications depend heavily on APIs. Frontend applications consume them, mobile apps rely on them, and microservices use them to exchange data. Because of that, API testing is no longer optional. If an endpoint returns the wrong status code, exposes an unexpected field, or fails under a basic workflow, the problem can reach users very quickly.

A good API testing strategy should cover more than one request. It should verify that the API accepts the right inputs, returns the correct outputs, and behaves consistently across a sequence of actions. Postman is useful for this because it lets you create requests, add assertions, organize them into collections, and run them in different environments.

Newman complements Postman by making those same collections runnable from the terminal. That is important because once the tests live in a command-line workflow, they can be placed inside CI/CD jobs, scheduled runs, or simple local scripts.

In this article, I will show how to apply both tools to a small API workflow so the process feels realistic instead of theoretical.

Why Postman and Newman

Postman is a strong choice for API testing because it is easy to understand and it supports the full cycle of request creation, test scripting, environment handling, and collection organization. A collection can group related requests, which makes it ideal for scenarios like creating a user, reading the same user back, updating it, and checking the final state.

Newman is the execution layer. It allows the same Postman collection to be run from the command line instead of only inside the app. That means the tests can be automated and repeated in a consistent way. In practice, this is what transforms a manual checklist into a reusable testing workflow.

This combination is attractive because it separates concerns cleanly: Postman is where you design and validate the test logic, and Newman is where you automate it.

The API scenario

For the article, I use a simple fictional API that manages users and tasks. The API exposes a few endpoints:

POST /users to create a user.
GET /users/{id} to retrieve that user.
POST /tasks to create a task for the user.
GET /tasks/{id} to verify task details.

This kind of flow works well because it lets us test both isolated requests and a full sequence. It also reflects what teams often do in real projects: create data, reuse returned values, and assert that the system behaves correctly from one step to the next.

Setting up the collection

A Postman collection can hold all related requests in one place. In this example, the collection could be called User and Task API. It would include an environment with variables such as:

base_url = http://localhost:3000
user_id = 
user_name = Kiara
user_email = kiara@example.com
task_id = 
task_title = Review API tests

Using variables keeps the requests reusable. If the same collection needs to run in development, staging, or production, only the environment values change.

Request 1: Create a user

The first request creates a user and stores the returned identifier in an environment variable.

POST {{base_url}}/users
Content-Type: application/json

{
  "name": "{{user_name}}",
  "email": "{{user_email}}"
}

The test script checks that the response is valid and extracts the ID:

pm.test("User created successfully", function () {
  pm.response.to.have.status(201);
  pm.response.to.be.withBody;
});

const jsonData = pm.response.json();
pm.environment.set("user_id", jsonData.id);

This is a common Postman pattern: send a request, validate the response, and store data for the next step.

Request 2: Read the user

Once the user exists, the second request verifies that the API can retrieve the same resource.

GET {{base_url}}/users/{{user_id}}

A simple test script might look like this:

pm.test("Get user returns 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Response contains user email", function () {
  const body = pm.response.json();
  pm.expect(body.email).to.eql(pm.environment.get("user_email"));
});

This step is important because it checks that the data created in one request can be read back correctly in another request.

Request 3: Create a task

After confirming the user exists, the collection can create a task linked to that user.

POST {{base_url}}/tasks
Content-Type: application/json

{
  "title": "{{task_title}}",
  "userId": "{{user_id}}"
}

The test script can verify both the response and the business logic:

pm.test("Task created successfully", function () {
  pm.response.to.have.status(201);
});

const taskData = pm.response.json();
pm.environment.set("task_id", taskData.id);
pm.expect(taskData.userId).to.eql(pm.environment.get("user_id"));

This is where Postman becomes more than a request sender. It becomes a workflow tester because it can connect one response to the next request.

Request 4: Read the task

The final request confirms that the task was stored correctly and is associated with the right user.

GET {{base_url}}/tasks/{{task_id}}

A validation script may include checks like these:

pm.test("Task returns 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Task belongs to the right user", function () {
  const body = pm.response.json();
  pm.expect(body.userId).to.eql(pm.environment.get("user_id"));
  pm.expect(body.title).to.eql(pm.environment.get("task_title"));
});

At this point, the collection has tested an end-to-end flow: create user, read user, create task, and verify task. That is a small but realistic example of how API testing can validate behavior across several endpoints.

Running the collection with Newman

Once the collection works in Postman, the same tests can be executed with Newman from the command line. That is useful when you want to automate the run or include it in a build pipeline.

A typical command looks like this:

newman run user-task-api.postman_collection.json \
  -e local.postman_environment.json \
  --reporters cli

If the collection and environment are stored in Postman cloud, Newman can also run them through the Postman API in a CI environment.

That matters because it allows the same tests to run every time the code is pushed, instead of depending on someone to open Postman manually.

Newman in CI/CD

Newman becomes especially useful when combined with automation. In a CI/CD pipeline, the test suite can run after code changes, before deployment, or on a schedule.

A simple pipeline could follow this logic:

Install Node.js and Newman.
Download or load the Postman collection.
Load the environment file.
Run the API tests.
Fail the pipeline if any assertion fails.

A minimal GitHub Actions example could be:

name: API Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Newman
        run: npm install -g newman

      - name: Run collection
        run: newman run user-task-api.postman_collection.json -e local.postman_environment.json

This turns API testing into a repeatable quality gate rather than a manual afterthought.

What makes this approach practical

The combination of Postman and Newman is practical because it covers both design and execution. Postman makes it easy to model requests and assertions, while Newman makes the same checks runnable from the terminal.

Another advantage is readability. A new team member can inspect the collection and understand the expected flow without needing to read a large testing framework immediately. That is especially helpful in small and medium-sized projects where clarity matters just as much as coverage.

Finally, the approach scales. A collection can start with four requests and later grow into a larger suite with authentication, pagination, error handling, and role-based checks.

Limitations

This approach is helpful, but it is not perfect. Postman and Newman are excellent for API-level validation, but they do not replace every kind of test.

They do not fully cover:

Performance behavior under heavy load.
Deep security testing.
Complex backend logic that requires unit testing.
Database internals or service implementation details.

For that reason, API tests should be part of a broader testing strategy that includes unit tests, integration tests, and sometimes performance or security checks.

Final thoughts

API testing becomes much more powerful when it moves from manual checking to a repeatable workflow. Postman gives you the structure to define requests, environments, and assertions. Newman gives you the ability to run that work from the command line and automate it in CI/CD.

In practice, that means better consistency, faster feedback, and fewer surprises before deployment. For real-world projects, especially team-based ones, that combination is one of the most accessible ways to build a practical API testing framework.

Bandit in a File Automation Script: Security Risks Hidden in Small Python Tools

Kiara Holly Zapana Murillo — Mon, 29 Jun 2026 21:04:56 +0000

Small Python scripts are often treated as low-risk tools because they are short, local, and built to solve a very specific task. However, a script that manipulates files, interprets input, or launches operating-system commands can still introduce serious security problems if it is written carelessly. Bandit is a static analysis tool for Python that helps detect insecure coding patterns before the script is executed. In this article, I use Bandit to review a simple file automation script that generates directory summaries.

The script looks useful at first glance, but it includes unsafe command construction, shell=True, and eval(). After identifying those risks, I rewrite the script using safer Python patterns. This example shows that even small automation tools deserve a security review and that SAST can provide useful feedback early in development.

Introduction

Many Python scripts are written quickly to automate repetitive work: list files, rename documents, generate reports, clean directories, or move content from one place to another. Because these tools are usually short and practical, it is easy to assume they are harmless.

That assumption can be misleading. A script does not need to be part of a large web platform to become risky. If it reads user input, builds shell commands, or writes files without enough care, it can expose the system to avoidable problems.

This is why Static Application Security Testing, or SAST, is still relevant for small programs. OWASP includes Bandit among its source code analysis tools, and Bandit is specifically designed to detect common security issues in Python code without executing the program.

In this article, I apply Bandit to a small file automation script. The goal is not to create a dramatic vulnerability demo, but to show how common coding habits in local utilities can still produce unsafe behavior.

Why this topic matters

When security is discussed in software projects, the attention usually goes to APIs, authentication, databases, or cloud infrastructure. Those areas are important, but smaller tools also deserve attention. In many teams, simple scripts become part of the daily workflow and are reused over time.

For example, a script that summarizes a directory for reporting purposes may later be integrated into a scheduled task, shared with another teammate, or adapted into a larger internal tool. If the original script contains unsafe patterns, those patterns can spread just as easily as bugs in any other part of the system.

That is one reason static analysis matters. It helps developers notice risky decisions before those decisions are normalized in future versions of the code.

Why Bandit is a practical choice

Bandit is a practical choice for Python because it focuses on source code scanning and looks for patterns that are often associated with vulnerabilities. According to the Bandit documentation, the tool parses Python files, builds an abstract syntax tree, applies security checks, and generates a report with the issues it detects.

This makes it useful in two ways. First, it gives fast feedback during development. Second, it can be integrated into automated workflows such as GitHub-based scanning through the official Bandit Action, which helps security checks happen consistently instead of relying only on memory.

The example script

For this experiment, I created a simple Python script that receives a folder path and generates a basic summary of its content. This is the type of utility many students or developers might actually write during a project.

At first glance, the script seems functional. It lists files, saves a report, and includes a helper function to process a user-provided expression. But several implementation choices make it unsafe.

import os
import subprocess


def summarize(folder):
    command = "ls " + folder
    output = subprocess.check_output(command, shell=True)
    return output.decode()


def save_report(name, content):
    file = open(name, "w")
    file.write(content)
    file.close()


def run_expression(value):
    return eval(value)

This script contains at least three important concerns:

It builds an operating-system command by concatenating user input.
It executes that command with shell=True.
It evaluates arbitrary input with eval().

None of these choices prevent the script from working. That is exactly what makes them useful for a SAST exercise: the code appears valid, but the implementation includes risky behavior.

Why the code is risky

The summarize() function is the most obvious problem. It constructs a shell command by joining ls with the value of folder, then passes that string to subprocess.check_output(..., shell=True). Bandit documents this pattern as dangerous because shell-based subprocess execution can be vulnerable to injection attacks, especially when the command string is built dynamically.

The use of eval() is also problematic. Even though it may look convenient for converting or calculating values, it can execute arbitrary Python expressions if it receives untrusted input. In a small utility script, that kind of flexibility is usually unnecessary.

The file-writing logic is less dramatic, but still worth improving. Using a context manager is safer and more maintainable because it ensures proper file handling and makes the code clearer.

Running Bandit

After saving the file as automation_tool.py, the scan command is straightforward:

python -m bandit automation_tool.py

If the code were part of a larger project, Bandit could also scan directories recursively:

python -m bandit -r .

Bandit typically reports subprocess-related issues when external commands are used in unsafe ways, and its documentation includes a specific rule for shell=True in subprocess calls.

A simplified example of the kind of result Bandit may produce is the following:

>> Issue: [B602] subprocess call with shell=True identified
   Severity: High   Confidence: High

>> Issue: [B404] Consider possible security implications associated with subprocess
   Severity: Low    Confidence: High

The exact output may vary depending on the Bandit version, but the important point is that the report helps connect each warning to a concrete coding pattern.

What the findings mean

One useful aspect of Bandit is that it does not just say that the script is “bad.” It points to specific practices that deserve review.

In this example, the most important finding is the shell-based subprocess execution. Bandit explains that calls using shell=True are risky because they may allow shell injection if input is not carefully controlled.

A practical example makes this easier to understand. Imagine that a teammate runs the script with a folder name that contains shell metacharacters or unexpected concatenated content. Even if the input is not intentionally malicious, command construction through string concatenation creates unnecessary exposure.

In other words, the script is not dangerous because it lists files; it becomes dangerous because of how it chooses to do that.

A safer rewrite

The same goal can be achieved with safer Python features and without invoking the system shell.

from pathlib import Path


def summarize(folder):
    target = Path(folder)
    if not target.is_dir():
        raise ValueError("Invalid folder")
    files = [p.name for p in target.iterdir() if p.is_file()]
    return "\n".join(files)


def save_report(name, content):
    path = Path(name)
    with path.open("w", encoding="utf-8") as file:
        file.write(content)


def parse_number(value):
    return int(value)

This new version changes the design in several important ways:

It uses Path objects instead of building shell commands.
It validates that the provided path is actually a directory.
It writes files using a context manager.
It replaces eval() with a specific conversion function.

The script still solves the same task, but it does so with a more controlled and predictable approach.

A practical comparison

The contrast between both versions is useful because it shows how insecure code is not always complex code. In the first version, the script depends on system command execution for something Python can do directly. In the second version, the logic stays inside the language and becomes easier to reason about.

That difference matters in real development work. The more a script relies on raw command strings or flexible execution features, the harder it becomes to guarantee safe behavior.

How this applies in real projects

This example may look small, but the pattern is common. A developer creates a quick utility, another person reuses it, and then the script becomes part of a shared workflow.

For instance, imagine an internal tool that generates nightly summaries of uploaded files. If the original implementation trusts input too much or depends on shell execution, the risk can remain hidden for a long time because the script “works.” Bandit helps uncover those kinds of problems before the code becomes permanent.

That is also why CI/CD integration can be valuable. The official PyCQA Bandit Action allows teams to run scans automatically in GitHub-based workflows, reducing the chance that insecure patterns are introduced silently during future changes.

A minimal workflow example is:

name: Bandit Scan
on: [push, pull_request]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Perform Bandit Analysis
        uses: PyCQA/bandit-action@v1

Limitations

Although Bandit is useful, it is not enough by itself. It focuses on Python source code and mainly detects patterns that are already known to be risky. That means it cannot fully understand business logic problems, misuse of permissions, or every contextual issue in a script.

It may also produce warnings that require human judgment. For example, some subprocess usage may be intentional and controlled, but still deserves review because process execution is a sensitive action.

For that reason, Bandit works best as one layer in a broader secure development process that also includes code review, input validation, safer defaults, and runtime testing.

Final thoughts

This exercise reinforced an important idea for me: a script does not need to be large to deserve security analysis. In fact, small automation tools are often trusted too quickly because they look simple.

Bandit is helpful precisely because it slows that assumption down. By scanning the source code before execution, it helps reveal insecure choices that are easy to overlook during normal development.

The most useful lesson was not only that Bandit can flag a dangerous pattern like shell=True, but that it encourages a better question while writing Python utilities: not just “does this work?”, but also “is this the safest way to solve the task?”

Your Terraform Can Be Insecure: A Practical Look at Checkov

Kiara Holly Zapana Murillo — Sat, 27 Jun 2026 16:19:01 +0000

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.

This article focuses on a practical question: how can developers detect insecure infrastructure definitions before deployment? One 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.
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 developers 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 learning 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. But from a security perspective, public-read may expose files that should not be accessible to everyone. Checkov includes Terraform policies for public S3 access and is designed to detect this kind of issue before infrastructure reaches production.

This example shows an 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.

That 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.

This 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.

A stronger approach combines:

Static analysis.
Code review.
Least privilege.
Secure defaults.
Runtime monitoring.
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.