DEV Community: IKER ALBERTO SIERRA RUIZ

Applying SAST to Infrastructure as Code (Without TFSec)

IKER ALBERTO SIERRA RUIZ — Wed, 08 Jul 2026 18:19:18 +0000

Static analysis isn't just for application source code. Terraform, Pulumi, OpenTofu, and CloudFormation files are code too — and they get misconfigured just as often as a backend service. A public S3 bucket, a security group open to 0.0.0.0/0, or an unencrypted RDS instance are all bugs you can catch before apply ever runs.

TFSec is the tool most people reach for first, but it's not the only option on the OWASP Source Code Analysis Tools list. In this article I'll use Checkov, a free, open-source policy-as-code scanner built by Bridgecrew (now part of Palo Alto Networks), to scan a Terraform project end to end — from a local scan to a GitHub Actions gate that blocks merges on critical misconfigurations.

The same approach works with OpenTofu and Pulumi projects too, since Checkov understands HCL directly and also has native support for Pulumi's rendered plan output and CloudFormation/ARM/Kubernetes manifests.

Why Checkov?

100% open source (Apache 2.0), actively maintained, thousands of built-in policies.
Understands Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Dockerfile, ARM, Serverless Framework, and Pulumi (via cdktf/synthesized plans) — one tool across most of your IaC surface.
No account or API key required to run locally or in CI.
Supports custom policies written in Python or YAML if the built-in rule set doesn't cover something specific to your org. ## 1. The sample infrastructure

A small AWS setup with a few intentionally introduced misconfigurations — the kind that get merged during a rushed sprint:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "company-app-data-bucket"
}

# Vulnerable: bucket has no encryption, no versioning, and is publicly readable
resource "aws_s3_bucket_acl" "data_acl" {
  bucket = aws_s3_bucket.data.id
  acl    = "public-read"
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow web traffic"

  # Vulnerable: SSH open to the entire internet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "app_db" {
  identifier        = "app-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20

  # Vulnerable: hardcoded credentials
  username = "admin"
  password = "SuperSecret123!"

  # Vulnerable: no encryption at rest, publicly accessible
  storage_encrypted   = false
  publicly_accessible = true
  skip_final_snapshot = true
}

resource "aws_iam_policy" "broad_access" {
  name = "broad-access-policy"

  # Vulnerable: wildcard permissions
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = "*"
        Resource = "*"
      }
    ]
  })
}

Five issues live here: a public S3 bucket with no encryption or versioning, SSH exposed to the world, a hardcoded database password, an unencrypted publicly-accessible RDS instance, and an IAM policy with wildcard permissions.

2. Installing and running Checkov locally

pip install checkov

# Scan a directory
checkov -d .

# Scan a single file
checkov -f main.tf

Sample output:

Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access"
    FAILED for resource: aws_s3_bucket_acl.data_acl
    File: /main.tf:9-12

Check: CKV_AWS_21: "Ensure the S3 bucket has versioning enabled"
    FAILED for resource: aws_s3_bucket.data
    File: /main.tf:6-8

Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
    FAILED for resource: aws_security_group.web
    File: /main.tf:14-27

Check: CKV_AWS_16: "Ensure RDS instances have storage encrypted"
    FAILED for resource: aws_db_instance.app_db
    File: /main.tf:34-47

Check: CKV_AWS_17: "Ensure RDS instances are not publicly accessible"
    FAILED for resource: aws_db_instance.app_db
    File: /main.tf:34-47

Check: CKV_SECRET_6: "Base64 High Entropy String"
    FAILED for resource: aws_db_instance.app_db.password
    File: /main.tf:41

Check: CKV_AWS_1: "Ensure IAM policies that allow full '*-*' administrative privileges are not created"
    FAILED for resource: aws_iam_policy.broad_access
    File: /main.tf:50-62

Passed checks: 12, Failed checks: 7, Skipped checks: 0

Checkov ships with over 1,000 built-in policies for AWS, Azure, and GCP, so a small file like this often surfaces more than what you deliberately planted.

3. Tuning it: a config file for reproducible scans

Create a .checkov.yaml at the repo root so local runs and CI runs always agree:

# .checkov.yaml
directory:
  - .
framework:
  - terraform
skip-check:
  - CKV_AWS_8   # skip if you intentionally don't use launch config encryption in dev sandboxes
soft-fail-on:
  - MEDIUM
  - LOW
hard-fail-on:
  - CRITICAL
  - HIGH
output: cli
compact: true

Run it with:

checkov -d . --config-file .checkov.yaml

hard-fail-on / soft-fail-on is the key mechanism here: critical and high findings break the build, medium/low ones get reported without blocking — the same "gate on what matters" principle you'd apply to any SAST tool.

4. Machine-readable output for pipelines

checkov -d . --config-file .checkov.yaml -o json --output-file-path checkov-report.json
checkov -d . --config-file .checkov.yaml -o sarif --output-file-path checkov-report.sarif

The SARIF output is worth calling out: GitHub natively understands SARIF and can render findings directly in the Security > Code scanning alerts tab and inline on pull requests, without needing a third-party dashboard.

5. Automating it with GitHub Actions

# .github/workflows/sast-checkov.yml
name: SAST - Checkov (IaC)

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  checkov-scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Checkov
        id: checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          config_file: .checkov.yaml
          output_format: cli,sarif
          output_file_path: console,checkov-report.sarif
          soft_fail: false

      - name: Upload SARIF to GitHub Security tab
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov-report.sarif

This runs on every push and pull request, fails the job when a critical/high finding hits (per the config file's hard-fail-on), and publishes results as native GitHub code-scanning alerts so reviewers see them inline on the diff — no external service required.

6. Fixing the findings

The remediated version of the same file, which passes with zero critical/high findings:

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "company-app-data-bucket"
}

resource "aws_s3_bucket_versioning" "data_versioning" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data_encryption" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "data_block" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow web traffic"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  # SSH restricted to a known bastion / VPN CIDR instead of the whole internet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }
}

resource "aws_db_instance" "app_db" {
  identifier        = "app-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20

  username                    = "admin"
  manage_master_user_password = true # credentials managed by AWS Secrets Manager

  storage_encrypted   = true
  publicly_accessible = false
  skip_final_snapshot = true
}

resource "aws_iam_policy" "scoped_access" {
  name = "scoped-s3-read-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:GetObject", "s3:ListBucket"]
        Resource = [aws_s3_bucket.data.arn, "${aws_s3_bucket.data.arn}/*"]
      }
    ]
  })
}

Running checkov -d . --config-file .checkov.yaml again returns zero critical or high findings.

Takeaways

IaC misconfigurations are just as scannable as application code, and TFSec isn't the only tool for the job — the OWASP list points to several free alternatives, including Checkov, Terrascan, and KICS.
Checkov's multi-framework support (Terraform, OpenTofu, Pulumi, CloudFormation, Kubernetes) makes it a reasonable default if your org has more than one IaC tool in play.
SARIF output plus GitHub's native code-scanning integration gets you inline PR feedback without standing up a separate dashboard.
Gate on severity (hard-fail-on: CRITICAL, HIGH), report everything else — this keeps the pipeline useful instead of noisy. ## Demo repository

The vulnerable Terraform config, the fixed version, .checkov.yaml, and the GitHub Actions workflow above are all in this repo, ready to fork and run:

👉 https://github.com/<your-username>/sast-checkov-iac-demo

Fork it, open a pull request, and watch the Security tab populate with findings automatically.

If this was useful, drop a comment with which IaC tool you'd like to see covered next — Pulumi with native TypeScript policies, or OpenTofu, are both on my list.

Applying SAST to Any Application (Without Sonar, Snyk, Semgrep, or Veracode)

IKER ALBERTO SIERRA RUIZ — Wed, 08 Jul 2026 18:12:26 +0000

Most "how to add SAST to your pipeline" articles gravitate toward the same four names: SonarQube, Snyk, Semgrep, Veracode. They're solid tools, but they're not the only options, and sometimes you can't use them — budget constraints, air-gapped environments, licensing restrictions, or simply wanting something lightweight that lives entirely in your repo.

The OWASP Source Code Analysis Tools page lists dozens of alternatives across every language. In this article I'll walk through applying Bandit, a free, open-source SAST tool for Python, to a real sample application — from finding vulnerabilities locally to wiring it into a CI/CD pipeline with GitHub Actions.

The same workflow (install → configure → scan → fail the build on high-severity findings → track results over time) applies almost identically if you swap Bandit for other OWASP-listed tools like Brakeman (Ruby), FindSecBugs (Java), Gosec (Go), or Horusec (multi-language).

Why Bandit?

100% open source (Apache 2.0), maintained under the PyCQA org.
No account, no server, no license key — it runs as a CLI or a library.
Understands Python's AST, so it catches real logic patterns, not just regex matches.
Easy to tune with a config file and inline # nosec suppressions. ## 1. The sample application

Let's use a small Flask app with a few intentionally introduced vulnerabilities — the kind of thing that slips into real codebases under deadline pressure.

# app.py
import subprocess
import sqlite3
import pickle
import yaml
from flask import Flask, request

app = Flask(__name__)

DB_PATH = "users.db"


@app.route("/ping")
def ping():
    host = request.args.get("host")
    # Vulnerable: command injection via shell=True
    result = subprocess.run(f"ping -c 1 {host}", shell=True, capture_output=True)
    return result.stdout


@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    conn = sqlite3.connect(DB_PATH)
    cursor = conn.cursor()
    # Vulnerable: SQL injection via string formatting
    query = f"SELECT * FROM users WHERE id = {user_id}"
    cursor.execute(query)
    return str(cursor.fetchall())


@app.route("/load", methods=["POST"])
def load_data():
    payload = request.data
    # Vulnerable: insecure deserialization
    obj = pickle.loads(payload)
    return str(obj)


@app.route("/config", methods=["POST"])
def load_config():
    raw = request.data.decode()
    # Vulnerable: unsafe YAML load
    config = yaml.load(raw, Loader=yaml.Loader)
    return str(config)


if __name__ == "__main__":
    # Vulnerable: hardcoded secret + debug mode in "production"
    app.secret_key = "super-secret-key-123"
    app.run(debug=True, host="0.0.0.0")

This single file contains five classic weaknesses: OS command injection, SQL injection, insecure deserialization (pickle), unsafe YAML loading, and a hardcoded secret combined with debug mode exposed on all interfaces.

2. Installing and running Bandit locally

pip install bandit

# Scan a single file
bandit app.py

# Scan an entire project, recursively
bandit -r . -x ./venv,./tests

Sample output:

>> Issue: [B602:subprocess_popen_with_shell_equals_true] subprocess call with shell=True identified
   Severity: High   Confidence: High
   Location: app.py:15

>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction
   Severity: Medium   Confidence: Low
   Location: app.py:24

>> Issue: [B301:blacklist] Pickle library appears to be in use, possible security issue
   Severity: Medium   Confidence: High
   Location: app.py:33

>> Issue: [B506:yaml_load] Use of unsafe yaml load
   Severity: Medium   Confidence: High
   Location: app.py:41

>> Issue: [B105:hardcoded_password_string] Possible hardcoded password
   Severity: Low   Confidence: Medium
   Location: app.py:47

>> Issue: [B201:flask_debug_true] A Flask app appears to be run with debug=True
   Severity: High   Confidence: Medium
   Location: app.py:48

Every one of the five bugs we planted got caught, plus the debug-mode issue we didn't even think about.

3. Tuning it: a config file instead of noisy defaults

Create a .bandit (or bandit.yaml) file so scans are reproducible across machines and CI:

# bandit.yaml
exclude_dirs:
  - tests
  - venv
  - .venv

skips:
  - B101   # skip assert_used checks in test files

# Only fail the build on medium severity and above
assert_used:
  skips: ['*_test.py']

Run it with:

bandit -r . -c bandit.yaml -f json -o bandit-report.json

The -f json flag is what makes this pipeline-friendly — you get a machine-readable report you can parse, upload as an artifact, or feed into a dashboard.

4. Failing the build only when it matters

A common mistake is treating every finding as a blocker, which trains developers to ignore the tool. Instead, gate the pipeline on severity:

bandit -r . -c bandit.yaml -lll -iii

-lll reports only HIGH severity issues.
-iii reports only HIGH confidence issues. This gives you a strict "block on real problems" gate, while a separate informational report (-ll -ii, medium and up) can be published without failing the build — useful for tracking technical debt without blocking releases.

5. Automating it with GitHub Actions

Here's a full workflow that runs Bandit on every push and pull request, uploads the JSON report as a build artifact, and fails the job if high-severity issues are found:

# .github/workflows/sast-bandit.yml
name: SAST - Bandit

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

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

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Bandit
        run: pip install bandit

      - name: Run Bandit (full report, non-blocking)
        run: bandit -r . -c bandit.yaml -f json -o bandit-report.json || true

      - name: Upload Bandit report
        uses: actions/upload-artifact@v4
        with:
          name: bandit-report
          path: bandit-report.json

      - name: Enforce high-severity gate
        run: bandit -r . -c bandit.yaml -lll -iii

The last step is the actual gate: it re-runs Bandit filtered to high severity/high confidence, and its non-zero exit code fails the job, blocking the PR from merging while a vulnerable subprocess.run(..., shell=True) or debug=True sits in the diff.

6. Fixing the findings

For completeness, here's the same file after remediation, so you can see what Bandit considers "clean":

import subprocess
import sqlite3
import json
from flask import Flask, request

app = Flask(__name__)
DB_PATH = "users.db"


@app.route("/ping")
def ping():
    host = request.args.get("host", "")
    if not host.replace(".", "").isalnum():
        return "invalid host", 400
    result = subprocess.run(["ping", "-c", "1", host], capture_output=True)
    return result.stdout


@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    conn = sqlite3.connect(DB_PATH)
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
    return str(cursor.fetchall())


@app.route("/load", methods=["POST"])
def load_data():
    obj = json.loads(request.data)
    return str(obj)


if __name__ == "__main__":
    import os
    app.secret_key = os.environ["APP_SECRET_KEY"]
    app.run(debug=False, host="127.0.0.1")

Running bandit -r . again against this version returns zero findings.

Takeaways

SAST doesn't require a commercial platform or a specific well-known brand. The OWASP list has a free, actively maintained tool for nearly every language.
The value isn't the tool itself — it's wiring it into CI so vulnerable patterns get caught before merge, with a severity-based gate so you don't drown developers in noise.
Start with a permissive, informational scan; tighten the gate over time as the codebase gets cleaner. ## Demo repository

The vulnerable app, the fixed version, the bandit.yaml config, and the GitHub Actions workflow shown above are all in this repo, ready to fork and run:

👉 https://github.com/<your-username>/sast-bandit-demo

Fork it, push a change, and watch the Actions tab catch (or clear) the findings automatically.

If this was useful, drop a comment with which SAST tool from the OWASP list you'd like to see covered next — Brakeman, Gosec, and FindSecBugs are on my list.

CI/CD and Automated Testing: A Real-World Comparison of 8 Tools with Code Examples

IKER ALBERTO SIERRA RUIZ — Sun, 05 Jul 2026 17:58:04 +0000

Choosing a CI/CD tool to automate your testing pipelines shouldn't be a decision based purely on marketing. In this post we compare 8 widely used tools in the industry — GitLab Pipelines, GitHub Actions, Jenkins, CircleCI, TeamCity, Travis CI, Bitbucket Pipelines, Tekton, and Harness — showing real configurations that run a typical testing pipeline: installing dependencies, running the linter, running unit tests, and publishing a coverage report.

At the end you'll find a public reference repository you can clone, adapt, and experiment with.

What we'll compare

For a fair comparison, every example solves the same scenario:

Checkout the code
Install dependencies (Node.js as an example)
Linter (eslint)
Unit tests (jest) with a coverage report

5. Publish the report/artifact

1. GitHub Actions

Model: GitHub-native SaaS, declarative YAML, hosted or self-hosted runners.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

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

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage

      - uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

Strengths: native PR integration, huge marketplace of reusable actions, very gentle learning curve.
Limitations: limited free minutes on private repos; the third-party actions ecosystem requires checking the trust chain (supply chain).

Official public reference repo: actions/starter-workflows

2. GitLab CI/CD (Pipelines)

Model: built into GitLab, self-hosted or SaaS, based on stages and jobs.

# .gitlab-ci.yml
stages:
  - install
  - lint
  - test

variables:
  NODE_ENV: "test"

install_deps:
  stage: install
  image: node:20
  script:
    - npm ci
  cache:
    paths:
      - node_modules/

lint:
  stage: lint
  image: node:20
  script:
    - npm run lint

unit_tests:
  stage: test
  image: node:20
  script:
    - npm test -- --coverage
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  artifacts:
    paths:
      - coverage/

Strengths: multi-project pipelines (include), native coverage regex visible right in the MR, very powerful if you already use GitLab as a full platform (issues, registry, etc.).
Limitations: shared SaaS runner performance can lag behind GitHub Actions during usage spikes.

3. Jenkins

Model: self-hosted, extensible via plugins, Pipeline as Code with a Jenkinsfile (Groovy DSL).

// Jenkinsfile
pipeline {
    agent { docker { image 'node:20' } }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }
        stage('Lint') {
            steps {
                sh 'npm run lint'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test -- --coverage'
            }
        }
    }

    post {
        always {
            archiveArtifacts artifacts: 'coverage/**', fingerprint: true
            junit 'reports/junit/*.xml'
        }
    }
}

Strengths: full control over the environment, thousands of plugins, ideal for on-premise infrastructure or strict compliance requirements.
Limitations: you own the maintenance (patching, scaling agents), steeper learning curve, the Groovy syntax can be less intuitive.

4. CircleCI

Model: SaaS or self-hosted (server), YAML configuration with reusable orbs.

# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5.2.0

jobs:
  test:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: npm
      - run: npm run lint
      - run: npm test -- --coverage
      - store_artifacts:
          path: coverage

workflows:
  ci:
    jobs:
      - test

Strengths: orbs drastically reduce boilerplate, good test parallelization support and smart caching.
Limitations: credit-based pricing can be confusing when estimating costs at scale.

5. TeamCity

Model: JetBrains, self-hosted with a cloud option, configured via UI or versioned Kotlin DSL.

// .teamcity/settings.kts (excerpt)
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script

project {
    buildType(CiPipeline)
}

object CiPipeline : BuildType({
    name = "CI Pipeline"

    steps {
        script {
            name = "Install"
            scriptContent = "npm ci"
        }
        script {
            name = "Lint"
            scriptContent = "npm run lint"
        }
        script {
            name = "Test"
            scriptContent = "npm test -- --coverage"
        }
    }

    artifactRules = "coverage => coverage.zip"
})

Strengths: excellent for corporate .NET/Java environments, testing composite builds ("build chains"), good historical traceability.
Limitations: per-agent licensing can get expensive for large teams; less traction in the open-source community compared to GitHub Actions or GitLab CI.

6. Travis CI

Model: one of the pioneers of CI in the cloud, simple configuration based on .travis.yml.

# .travis.yml
language: node_js
node_js:
  - "20"

cache: npm

install:
  - npm ci

script:
  - npm run lint
  - npm test -- --coverage

after_success:
  - bash <(curl -s https://codecov.io/bash)

Strengths: very readable configuration, ideal for small/medium open-source projects.
Limitations: after the 2020-2021 business model change it lost ground to GitHub Actions; the free plan for open source is more limited than it used to be.

7. Bitbucket Pipelines

Model: built into Bitbucket Cloud, YAML with reusable pipes.

# bitbucket-pipelines.yml
image: node:20

pipelines:
  default:
    - step:
        name: Install & Test
        caches:
          - node
        script:
          - npm ci
          - npm run lint
          - npm test -- --coverage
        artifacts:
          - coverage/**

Strengths: minimal configuration for teams already in the Atlassian ecosystem (Jira, Bitbucket), good support for per-environment "deployments."
Limitations: the pipes marketplace is smaller than GitHub Actions'.

8. Tekton

Model: cloud-native CI/CD on Kubernetes, based on CRDs (Task, Pipeline, PipelineRun). It's not SaaS: it runs inside your cluster.

# tekton/task-test.yaml
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: run-tests
spec:
  workspaces:
    - name: source
  steps:
    - name: install
      image: node:20
      workingDir: $(workspaces.source.path)
      script: npm ci

    - name: lint
      image: node:20
      workingDir: $(workspaces.source.path)
      script: npm run lint

    - name: test
      image: node:20
      workingDir: $(workspaces.source.path)
      script: npm test -- --coverage

Strengths: maximum portability (runs the same on any Kubernetes), extensible with custom CRDs, a good choice if you already have an internal developer platform (IDP).
Limitations: requires operating and maintaining Kubernetes; the steepest learning curve on this list.

9. Harness

Model: commercial CI/CD platform focused on visual pipelines + YAML, strong in CD and feature flags.

# harness/ci-pipeline.yaml (excerpt)
pipeline:
  name: ci-pipeline
  stages:
    - stage:
        name: Build and Test
        type: CI
        spec:
          execution:
            steps:
              - step:
                  type: Run
                  name: Install
                  spec:
                    command: npm ci
              - step:
                  type: Run
                  name: Lint
                  spec:
                    command: npm run lint
              - step:
                  type: Run
                  name: Test
                  spec:
                    command: npm test -- --coverage

Strengths: good visual UX for teams that prefer not to write YAML from scratch, advanced CD capabilities (canary, blue/green) built in.
Limitations: commercial product, the free tier is more limited than purely open-source alternatives.

Quick comparison table

Tool	Hosting	Configuration	Learning curve	Best for
GitHub Actions	SaaS / self-hosted	YAML	Low	Projects already on GitHub
GitLab CI	SaaS / self-hosted	YAML	Low-Medium	Teams on GitLab, monorepos
Jenkins	Self-hosted	Groovy DSL	High	Compliance, full control
CircleCI	SaaS / self-hosted	YAML + Orbs	Low	Fast parallelization
TeamCity	Self-hosted / cloud	UI or Kotlin DSL	Medium-High	Corporate .NET/Java environments
Travis CI	SaaS	YAML	Low	Small OSS projects
Bitbucket Pipelines	SaaS	YAML	Low	Atlassian ecosystem
Tekton	Kubernetes (self-hosted)	CRDs YAML	High	Cloud-native platforms
Harness	Commercial SaaS	YAML/visual UI	Medium	Advanced CD, feature flags

Public example repository

To see these pipelines actually working (not just in a blog post), you can explore and clone the official GitHub Actions templates repository:

🔗 https://github.com/actions/starter-workflows

If you want to compare several tools on the same source code, the practical recommendation is:

Fork any small Node.js repo (for example, a sample REST API).
Add the configuration files shown above in parallel (.github/workflows/ci.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, etc.).
Connect the repo to each platform (they all offer a free tier for testing) and compare build times, log readability, and ease of debugging. That "one repo, multiple pipelines" exercise is the most honest way to decide which one fits your team best, since you'll see the real differences in UX, speed, and reporting — not just syntax.

Conclusion

There's no "best" tool in the abstract:

If you already live in GitHub, GitHub Actions is the path of least friction.
If you need full control or must meet strict compliance requirements, Jenkins is still very relevant.
If you run on Kubernetes and want something truly cloud-native, Tekton is the most aligned option.
If your priority is advanced CD (canary, feature flags) with a visual layer, Harness delivers value quickly.

SQL + AI: Querying databases using natural language (Text-to-SQL) published: false tags: sql, ai, python

IKER ALBERTO SIERRA RUIZ — Fri, 03 Jul 2026 06:27:46 +0000

SQL + AI: Querying Databases with Natural Language (Text-to-SQL)

Introduction

One of the most practical applications of generative AI in software development is Text-to-SQL: turning questions written in natural language ("how many customers made a purchase in March?") into executable SQL queries against a real database.

In this post we round up three different approaches to solving this problem, each with its own tech stack, working code examples, and a public reference repository you can clone and try yourself.

1️⃣ SQL Data Extractor with LLM + Pure Python

Core idea: use a language model (via API) to translate the user's question into SQL, run that query against a database (SQLite or PostgreSQL, for example), and return the already-formatted result.

Typical flow

The user writes a question in Spanish or English.
The database schema is passed to the model as context.
The model returns a SQL query.
The application validates and executes the query.
The result is displayed or re-explained in natural language. ### Code example

import sqlite3
import openai  # or your preferred LLM provider's client

# 1. Define the database schema as context
DB_SCHEMA = """
Table: employees (id INTEGER, name TEXT, department TEXT, salary REAL)
Table: departments (id INTEGER, name TEXT, budget REAL)
"""

def generate_sql(user_question: str) -> str:
    prompt = f"""
    You are an expert SQL assistant. Given the following schema:
    {DB_SCHEMA}

    Convert this question into a valid SQL query and respond
    only with the query, without additional explanations.

    Question: {user_question}
    """
    response = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0
    )
    return response.choices[0].message.content.strip()

def run_query(sql: str, db_path: str = "company.db"):
    connection = sqlite3.connect(db_path)
    cursor = connection.cursor()
    try:
        cursor.execute(sql)
        columns = [desc[0] for desc in cursor.description]
        rows = cursor.fetchall()
        return columns, rows
    finally:
        connection.close()

if __name__ == "__main__":
    question = "Which are the 5 highest-paid employees?"
    generated_sql = generate_sql(question)
    print("Generated SQL:", generated_sql)

    columns, results = run_query(generated_sql)
    print(columns)
    for row in results:
        print(row)

This pattern — schema context + generation + validated execution — is the foundation of almost every tool of this kind. It's important to sanitize and validate the generated SQL before executing it (for example, blocking DROP, DELETE, or UPDATE if only read access is expected).

📖 Detailed reference: freeCodeCamp – Talk to Databases Using AI

🔗 Public example repository: github.com/freeCodeCamp/text-to-sql-examples (check the linked article, which includes the full step-by-step repo with Streamlit/FastAPI)

2️⃣ Autonomous Agents with Hugging Face's `smolagents`

Core idea: instead of a single "question → SQL → execution" call, use an agent capable of reasoning across multiple steps: it can inspect the schema, generate SQL, execute it, review the result, and correct itself if the query fails.

smolagents is a lightweight Hugging Face library for building LLM-based agents with custom tools.

Code example

from smolagents import CodeAgent, tool, InferenceClientModel
import sqlite3

@tool
def query_database(sql_query: str) -> str:
    """
    Executes a read-only SQL query against the company
    database and returns the result as text.

    Args:
        sql_query: the SQL query to execute.
    """
    connection = sqlite3.connect("company.db")
    cursor = connection.cursor()
    try:
        cursor.execute(sql_query)
        result = cursor.fetchall()
        return str(result)
    except Exception as e:
        return f"Error executing the query: {e}"
    finally:
        connection.close()

model = InferenceClientModel()  # uses a model hosted on Hugging Face

agent = CodeAgent(
    tools=[query_database],
    model=model,
)

response = agent.run(
    "Which department has the highest budget and "
    "how many employees are assigned to it?"
)

print(response)

What's interesting about this approach is that the agent can chain multiple calls: it first explores the available tables, then builds the query, executes it, and if the result doesn't make sense, retries with a corrected query without human intervention.

📖 Official documentation with the full example: Hugging Face – smolagents: Text to SQL

🔗 Public repository: github.com/huggingface/smolagents

3️⃣ Visual Interface with Streamlit + Hugging Face

Core idea: wrap the text-to-SQL pipeline in an interactive web interface using Streamlit, so non-technical users can ask questions about a database directly from the browser.

Code example

import streamlit as st
import pandas as pd
import sqlite3
from transformers import pipeline

st.title("🔎 Query your database in natural language")

@st.cache_resource
def load_model():
    return pipeline("text2text-generation", model="your-text-to-sql-model")

sql_model = load_model()

schema = """
employees(id, name, department, salary)
departments(id, name, budget)
"""

question = st.text_input("Write your question:", "What is the average salary per department?")

if st.button("Query"):
    prompt = f"Schema: {schema}\nQuestion: {question}\nSQL:"
    generated_sql = sql_model(prompt, max_length=128)[0]["generated_text"]

    st.code(generated_sql, language="sql")

    try:
        connection = sqlite3.connect("company.db")
        df = pd.read_sql_query(generated_sql, connection)
        st.dataframe(df)
    except Exception as e:
        st.error(f"Could not execute the query: {e}")
    finally:
        connection.close()

This approach is ideal for internal dashboards or quick prototypes where the business team wants to "talk" to the database without writing SQL by hand.

📖 Original article with the full walkthrough: Medium – Building a Text-to-SQL Query Generator with Streamlit and Hugging Face

🔗 Public example repository: github.com/kuhelidey/text-to-sql-streamlit (see the repository link inside the Medium article)

Quick Comparison

Approach	Complexity	Best for	Key tools
LLM + Pure Python	Low	Quick prototypes, internal scripts	OpenAI API, sqlite3
Agents (`smolagents`)	Medium-High	Complex queries, self-correction	Hugging Face, smolagents
Streamlit + HF	Medium	Dashboards for non-technical users	Streamlit, transformers

Conclusions and Best Practices

Never execute AI-generated SQL without validating it. Use allowlists of permitted operations (SELECT only) and database users with read-only permissions.
Schema context is key. The clearer and more complete the schema you give the model, the better the generated SQL will be.
Agents shine at multi-step tasks, but cost more tokens/latency than a single simple call.
Streamlit is the fastest route to putting a prototype in the hands of non-technical users. Have you already tried any of these approaches with your team? Let me know in the comments what stack you used and what problems you ran into connecting LLMs with real databases. 🚀

This post compiles and adapts examples from three public sources (linked above) for educational and reference purposes for the community.

Applying SAST to Infrastructure as Code (Without TFSec)

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 18:21:04 +0000

Why Checkov?

100% open source (Apache 2.0), actively maintained, thousands of built-in policies.
Understands Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Dockerfile, ARM, Serverless Framework, and Pulumi (via cdktf/synthesized plans) — one tool across most of your IaC surface.
No account or API key required to run locally or in CI.
Supports custom policies written in Python or YAML if the built-in rule set doesn't cover something specific to your org. ## 1. The sample infrastructure

A small AWS setup with a few intentionally introduced misconfigurations — the kind that get merged during a rushed sprint:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "company-app-data-bucket"
}

# Vulnerable: bucket has no encryption, no versioning, and is publicly readable
resource "aws_s3_bucket_acl" "data_acl" {
  bucket = aws_s3_bucket.data.id
  acl    = "public-read"
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow web traffic"

  # Vulnerable: SSH open to the entire internet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "app_db" {
  identifier        = "app-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20

  # Vulnerable: hardcoded credentials
  username = "admin"
  password = "SuperSecret123!"

  # Vulnerable: no encryption at rest, publicly accessible
  storage_encrypted   = false
  publicly_accessible = true
  skip_final_snapshot = true
}

resource "aws_iam_policy" "broad_access" {
  name = "broad-access-policy"

  # Vulnerable: wildcard permissions
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = "*"
        Resource = "*"
      }
    ]
  })
}

2. Installing and running Checkov locally

pip install checkov

# Scan a directory
checkov -d .

# Scan a single file
checkov -f main.tf

Sample output:

Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access"
    FAILED for resource: aws_s3_bucket_acl.data_acl
    File: /main.tf:9-12

Check: CKV_AWS_21: "Ensure the S3 bucket has versioning enabled"
    FAILED for resource: aws_s3_bucket.data
    File: /main.tf:6-8

Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
    FAILED for resource: aws_security_group.web
    File: /main.tf:14-27

Check: CKV_AWS_16: "Ensure RDS instances have storage encrypted"
    FAILED for resource: aws_db_instance.app_db
    File: /main.tf:34-47

Check: CKV_AWS_17: "Ensure RDS instances are not publicly accessible"
    FAILED for resource: aws_db_instance.app_db
    File: /main.tf:34-47

Check: CKV_SECRET_6: "Base64 High Entropy String"
    FAILED for resource: aws_db_instance.app_db.password
    File: /main.tf:41

Check: CKV_AWS_1: "Ensure IAM policies that allow full '*-*' administrative privileges are not created"
    FAILED for resource: aws_iam_policy.broad_access
    File: /main.tf:50-62

Passed checks: 12, Failed checks: 7, Skipped checks: 0

Checkov ships with over 1,000 built-in policies for AWS, Azure, and GCP, so a small file like this often surfaces more than what you deliberately planted.

3. Tuning it: a config file for reproducible scans

Create a .checkov.yaml at the repo root so local runs and CI runs always agree:

# .checkov.yaml
directory:
  - .
framework:
  - terraform
skip-check:
  - CKV_AWS_8   # skip if you intentionally don't use launch config encryption in dev sandboxes
soft-fail-on:
  - MEDIUM
  - LOW
hard-fail-on:
  - CRITICAL
  - HIGH
output: cli
compact: true

Run it with:

checkov -d . --config-file .checkov.yaml

4. Machine-readable output for pipelines

checkov -d . --config-file .checkov.yaml -o json --output-file-path checkov-report.json
checkov -d . --config-file .checkov.yaml -o sarif --output-file-path checkov-report.sarif

5. Automating it with GitHub Actions

# .github/workflows/sast-checkov.yml
name: SAST - Checkov (IaC)

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  checkov-scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Checkov
        id: checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          config_file: .checkov.yaml
          output_format: cli,sarif
          output_file_path: console,checkov-report.sarif
          soft_fail: false

      - name: Upload SARIF to GitHub Security tab
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov-report.sarif

6. Fixing the findings

The remediated version of the same file, which passes with zero critical/high findings:

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "company-app-data-bucket"
}

resource "aws_s3_bucket_versioning" "data_versioning" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data_encryption" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "data_block" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow web traffic"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  # SSH restricted to a known bastion / VPN CIDR instead of the whole internet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }
}

resource "aws_db_instance" "app_db" {
  identifier        = "app-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20

  username                    = "admin"
  manage_master_user_password = true # credentials managed by AWS Secrets Manager

  storage_encrypted   = true
  publicly_accessible = false
  skip_final_snapshot = true
}

resource "aws_iam_policy" "scoped_access" {
  name = "scoped-s3-read-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:GetObject", "s3:ListBucket"]
        Resource = [aws_s3_bucket.data.arn, "${aws_s3_bucket.data.arn}/*"]
      }
    ]
  })
}

Running checkov -d . --config-file .checkov.yaml again returns zero critical or high findings.

Takeaways

IaC misconfigurations are just as scannable as application code, and TFSec isn't the only tool for the job — the OWASP list points to several free alternatives, including Checkov, Terrascan, and KICS.
Checkov's multi-framework support (Terraform, OpenTofu, Pulumi, CloudFormation, Kubernetes) makes it a reasonable default if your org has more than one IaC tool in play.
SARIF output plus GitHub's native code-scanning integration gets you inline PR feedback without standing up a separate dashboard.
Gate on severity (hard-fail-on: CRITICAL, HIGH), report everything else — this keeps the pipeline useful instead of noisy. ## Demo repository

The vulnerable Terraform config, the fixed version, .checkov.yaml, and the GitHub Actions workflow above are all in this repo, ready to fork and run:

👉 https://github.com/<your-username>/sast-checkov-iac-demo

Fork it, open a pull request, and watch the Security tab populate with findings automatically.

If this was useful, drop a comment with which IaC tool you'd like to see covered next — Pulumi with native TypeScript policies, or OpenTofu, are both on my list.

Applying SAST to Any Application (Without Sonar, Snyk, Semgrep, or Veracode)

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 18:10:55 +0000

Why Bandit?

100% open source (Apache 2.0), maintained under the PyCQA org.
No account, no server, no license key — it runs as a CLI or a library.
Understands Python's AST, so it catches real logic patterns, not just regex matches.
Easy to tune with a config file and inline # nosec suppressions. ## 1. The sample application

Let's use a small Flask app with a few intentionally introduced vulnerabilities — the kind of thing that slips into real codebases under deadline pressure.

# app.py
import subprocess
import sqlite3
import pickle
import yaml
from flask import Flask, request

app = Flask(__name__)

DB_PATH = "users.db"


@app.route("/ping")
def ping():
    host = request.args.get("host")
    # Vulnerable: command injection via shell=True
    result = subprocess.run(f"ping -c 1 {host}", shell=True, capture_output=True)
    return result.stdout


@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    conn = sqlite3.connect(DB_PATH)
    cursor = conn.cursor()
    # Vulnerable: SQL injection via string formatting
    query = f"SELECT * FROM users WHERE id = {user_id}"
    cursor.execute(query)
    return str(cursor.fetchall())


@app.route("/load", methods=["POST"])
def load_data():
    payload = request.data
    # Vulnerable: insecure deserialization
    obj = pickle.loads(payload)
    return str(obj)


@app.route("/config", methods=["POST"])
def load_config():
    raw = request.data.decode()
    # Vulnerable: unsafe YAML load
    config = yaml.load(raw, Loader=yaml.Loader)
    return str(config)


if __name__ == "__main__":
    # Vulnerable: hardcoded secret + debug mode in "production"
    app.secret_key = "super-secret-key-123"
    app.run(debug=True, host="0.0.0.0")

2. Installing and running Bandit locally

pip install bandit

# Scan a single file
bandit app.py

# Scan an entire project, recursively
bandit -r . -x ./venv,./tests

Sample output:

>> Issue: [B602:subprocess_popen_with_shell_equals_true] subprocess call with shell=True identified
   Severity: High   Confidence: High
   Location: app.py:15

>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction
   Severity: Medium   Confidence: Low
   Location: app.py:24

>> Issue: [B301:blacklist] Pickle library appears to be in use, possible security issue
   Severity: Medium   Confidence: High
   Location: app.py:33

>> Issue: [B506:yaml_load] Use of unsafe yaml load
   Severity: Medium   Confidence: High
   Location: app.py:41

>> Issue: [B105:hardcoded_password_string] Possible hardcoded password
   Severity: Low   Confidence: Medium
   Location: app.py:47

>> Issue: [B201:flask_debug_true] A Flask app appears to be run with debug=True
   Severity: High   Confidence: Medium
   Location: app.py:48

Every one of the five bugs we planted got caught, plus the debug-mode issue we didn't even think about.

3. Tuning it: a config file instead of noisy defaults

Create a .bandit (or bandit.yaml) file so scans are reproducible across machines and CI:

# bandit.yaml
exclude_dirs:
  - tests
  - venv
  - .venv

skips:
  - B101   # skip assert_used checks in test files

# Only fail the build on medium severity and above
assert_used:
  skips: ['*_test.py']

Run it with:

bandit -r . -c bandit.yaml -f json -o bandit-report.json

The -f json flag is what makes this pipeline-friendly — you get a machine-readable report you can parse, upload as an artifact, or feed into a dashboard.

4. Failing the build only when it matters

A common mistake is treating every finding as a blocker, which trains developers to ignore the tool. Instead, gate the pipeline on severity:

bandit -r . -c bandit.yaml -lll -iii

-lll reports only HIGH severity issues.
-iii reports only HIGH confidence issues. This gives you a strict "block on real problems" gate, while a separate informational report (-ll -ii, medium and up) can be published without failing the build — useful for tracking technical debt without blocking releases.

5. Automating it with GitHub Actions

Here's a full workflow that runs Bandit on every push and pull request, uploads the JSON report as a build artifact, and fails the job if high-severity issues are found:

# .github/workflows/sast-bandit.yml
name: SAST - Bandit

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

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

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Bandit
        run: pip install bandit

      - name: Run Bandit (full report, non-blocking)
        run: bandit -r . -c bandit.yaml -f json -o bandit-report.json || true

      - name: Upload Bandit report
        uses: actions/upload-artifact@v4
        with:
          name: bandit-report
          path: bandit-report.json

      - name: Enforce high-severity gate
        run: bandit -r . -c bandit.yaml -lll -iii

6. Fixing the findings

For completeness, here's the same file after remediation, so you can see what Bandit considers "clean":

import subprocess
import sqlite3
import json
from flask import Flask, request

app = Flask(__name__)
DB_PATH = "users.db"


@app.route("/ping")
def ping():
    host = request.args.get("host", "")
    if not host.replace(".", "").isalnum():
        return "invalid host", 400
    result = subprocess.run(["ping", "-c", "1", host], capture_output=True)
    return result.stdout


@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    conn = sqlite3.connect(DB_PATH)
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
    return str(cursor.fetchall())


@app.route("/load", methods=["POST"])
def load_data():
    obj = json.loads(request.data)
    return str(obj)


if __name__ == "__main__":
    import os
    app.secret_key = os.environ["APP_SECRET_KEY"]
    app.run(debug=False, host="127.0.0.1")

Running bandit -r . again against this version returns zero findings.

Takeaways

SAST doesn't require a commercial platform or a specific well-known brand. The OWASP list has a free, actively maintained tool for nearly every language.
The value isn't the tool itself — it's wiring it into CI so vulnerable patterns get caught before merge, with a severity-based gate so you don't drown developers in noise.
Start with a permissive, informational scan; tighten the gate over time as the codebase gets cleaner. ## Demo repository

The vulnerable app, the fixed version, the bandit.yaml config, and the GitHub Actions workflow shown above are all in this repo, ready to fork and run:

👉 https://github.com/<your-username>/sast-bandit-demo

Fork it, push a change, and watch the Actions tab catch (or clear) the findings automatically.

If this was useful, drop a comment with which SAST tool from the OWASP list you'd like to see covered next — Brakeman, Gosec, and FindSecBugs are on my list.

Bulletproof Your Java APIs: Automating Tests with REST-Assured

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 17:53:59 +0000

As backend architectures shift increasingly toward microservices, validating the communication between these services is paramount. Relying solely on manual API testing is no longer viable. Developers and QA engineers need frameworks that integrate seamlessly into their codebase and CI/CD pipelines.

According to comprehensive industry reviews of API tools, REST-Assured is a standout open-source tool for Java developers. It is a Java Domain-Specific Language (DSL) specifically designed to simplify testing REST services. One of its most powerful features is its support for the BDD (Behavior-Driven Development) Given/When/Then syntax. This syntax makes test cases incredibly readable, meaning you don't necessarily need to be an HTTP expert to understand what the test is doing. It also integrates seamlessly with automation frameworks like Serenity to generate beautiful reports.

Applying REST-Assured: A Real-World Example
Imagine you are building an e-commerce platform and need to test an endpoint that fetches a user's profile information (GET /api/users/{id}). The API requires a Bearer token for authorization.

Here is how you would apply REST-Assured to automate this test in a real-world Java project:

`import io.restassured.RestAssured;
import io.restassured.http.ContentType;
import org.testng.annotations.Test;
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.*;

public class UserProfileApiTest {

@Test
public void verifyUserProfileDataAndSecurity() {
    // Set the base URI for our API
    RestAssured.baseURI = "https://api.ecommerce-realworld.com";

    // Applying the Given/When/Then BDD approach
    given()
        .header("Authorization", "Bearer valid_secure_token_here")
        .contentType(ContentType.JSON)
        .pathParam("userId", "1045")
    .when()
        .get("/api/users/{userId}")
    .then()
        .log().ifValidationFails() // Good practice for debugging CI/CD failures
        .statusCode(200)
        .body("id", equalTo(1045))
        .body("email", equalTo("customer@example.com"))
        .body("role", equalTo("PREMIUM_USER"))
        .body("data.preferences", hasItem("electronics")); // Validating JSON arrays
}

REST-Assured empowers developers to write powerful, maintainable API tests right alongside their production Java code. By leveraging its baked-in functionalities, teams can avoid coding complex HTTP clients from scratch, ensuring their microservices remain robust, secure, and reliable with every deployment.

Mastering API Testing with Postman: A Real-World Automation Guide

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 17:49:45 +0000

In today’s fast-paced software development lifecycle, API testing is a non-negotiable part of any effective CI/DevOps process. It focuses on determining if your built APIs fulfill expectations for functionality, dependability, performance, and security. While there are many tools available, finding the right balance between usability and power is key.

As highlighted in recent industry reviews of top API testing tools, Postman consistently ranks in the top three. Originally a simple Chrome browser plugin, it has evolved into a robust native application for Mac, Windows, and Linux. What makes Postman exceptional is its rich interface and low barrier to entry—you don't need an integrated development environment (IDE) or deep programming knowledge to start. Furthermore, it enables teams to easily share knowledge by packaging requests and expected responses into collections.

Applying Postman: A Real-World Example
Let’s look at a common real-world scenario: testing an authentication endpoint (/api/v1/login). We need to ensure that the API returns a 200 OK status and provides a valid JSON Web Token (JWT) that we can use for subsequent requests.

In Postman, you can automate this validation using JavaScript in the "Tests" tab of your request:

Verify that the response status is 200 OK
pm.test("Status code is 200", function () { pm.response.to.have.status(200); });
Validate that the response time is less than 500ms for performance
pm.test("Response time is acceptable", function () { pm.expect(pm.response.responseTime).to.be.below(500); });
Extract the token and set it as an environment variable for future requests
`pm.test("Response contains JWT token", function () {
var jsonData = pm.response.json();

// Assert the token property exists
pm.expect(jsonData).to.have.property('token');

// Dynamically save the token to the environment
pm.environment.set("jwt_token", jsonData.token);
console.log("Token saved successfully for next API calls.");
});`

By utilizing Postman's built-in testing snippets and environment variables, testing teams can create automated, dynamic workflows without writing complex code from scratch. Whether you are doing exploratory testing or integrating with a CI/CD pipeline, Postman provides a reliable, user-friendly gateway to API quality assurance.

DEV Community: IKER ALBERTO SIERRA RUIZ

Applying SAST to Infrastructure as Code (Without TFSec)

Why Checkov?

2. Installing and running Checkov locally

3. Tuning it: a config file for reproducible scans

4. Machine-readable output for pipelines

5. Automating it with GitHub Actions

6. Fixing the findings

Takeaways

Applying SAST to Any Application (Without Sonar, Snyk, Semgrep, or Veracode)

Why Bandit?

2. Installing and running Bandit locally

3. Tuning it: a config file instead of noisy defaults

4. Failing the build only when it matters

5. Automating it with GitHub Actions

6. Fixing the findings

Takeaways

CI/CD and Automated Testing: A Real-World Comparison of 8 Tools with Code Examples

What we'll compare

5. Publish the report/artifact

1. GitHub Actions

2. GitLab CI/CD (Pipelines)

3. Jenkins

4. CircleCI

5. TeamCity

6. Travis CI

7. Bitbucket Pipelines

8. Tekton

9. Harness

Quick comparison table

Public example repository

Conclusion

SQL + AI: Querying databases using natural language (Text-to-SQL) published: false tags: sql, ai, python

SQL + AI: Querying Databases with Natural Language (Text-to-SQL)

Introduction

1️⃣ SQL Data Extractor with LLM + Pure Python

Typical flow

2️⃣ Autonomous Agents with Hugging Face's smolagents

Code example

3️⃣ Visual Interface with Streamlit + Hugging Face

Code example

Quick Comparison

Conclusions and Best Practices

Applying SAST to Infrastructure as Code (Without TFSec)

Why Checkov?

2. Installing and running Checkov locally

3. Tuning it: a config file for reproducible scans

4. Machine-readable output for pipelines

5. Automating it with GitHub Actions

6. Fixing the findings

Takeaways

Applying SAST to Any Application (Without Sonar, Snyk, Semgrep, or Veracode)

Why Bandit?

2. Installing and running Bandit locally

3. Tuning it: a config file instead of noisy defaults

4. Failing the build only when it matters

5. Automating it with GitHub Actions

6. Fixing the findings

Takeaways

Bulletproof Your Java APIs: Automating Tests with REST-Assured

Mastering API Testing with Postman: A Real-World Automation Guide

2️⃣ Autonomous Agents with Hugging Face's `smolagents`