DEV Community: FABRICIO FARID EDMILSON RAMOS ATAHUACHI

How to Talk to Any Database Using AI: Building a Text-to-SQL App

FABRICIO FARID EDMILSON RAMOS ATAHUACHI — Sat, 27 Jun 2026 04:37:09 +0000

In today’s data-driven world, getting information out of a database usually requires knowing SQL. But what if you could just ask your database a question in plain English and get the answer instantly? Thanks to Large Language Models (LLMs) and Artificial Intelligence, this is no longer science fiction.

In this article, I will show you a real-world example of how to build a Text-to-SQL Query Generator using Python, Streamlit, and Hugging Face.

The Magic of Text-to-SQL
Text-to-SQL is a natural language processing (NLP) task where an AI model translates a human-readable question into a structured SQL query. This bridges the gap between non-technical users (like business analysts or managers) and complex databases.

Instead of writing:
SELECT Salary FROM employees WHERE Name = 'Bob';

A user can simply ask: "What is the salary of Bob?"

Building the App (Code Example)
To demonstrate this, I have created a lightweight web application. We will use Streamlit for the frontend, SQLite for a temporary local database, and the Hugging Face Inference API to access an open-source Text-to-SQL model (t5-base-finetuned-wikiSQL).

1. Setting up the Database
First, we create a temporary in-memory database using sqlite3 and populate it with some dummy employee data. (You can check the full source code in my GitHub repository linked below).

2. The Hugging Face Connection
We use a simple HTTP POST request to send our natural language question to the Hugging Face API. The model processes the text and returns the SQL equivalent.

API_URL = "https://api-inference.huggingface.co/models/mrm8488/t5-base-finetuned-wikiSQL"

def generate_sql(question):
    payload = {"inputs": f"translate English to SQL: {question}"}
    response = requests.post(API_URL, json=payload)
    return response.json()[0]['generated_text']

3. The Streamlit Interface
With Streamlit, creating the UI takes just a few lines of code. We take the user's input, pass it to our generate_sql function, display the generated SQL on the screen, and then immediately execute that query against our SQLite database to show the results in a table!

Try it Yourself!
The integration of AI into database management is transforming how we interact with data, democratizing data access across entire organizations.

You can find the complete, runnable code in my public repository here: https://github.com/FabricioRams/Research-Team-Work-N-01-SQL-AI-Database-Solutions.git

Clone it, run pip install -r requirements.txt, and start talking to your database today!

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.