DEV Community: DAYAN ELVIS JAHUIRA PILCO

CI/CD Testing Tools Compared: the Same Pipeline in GitHub Actions, GitLab CI and Jenkins

DAYAN ELVIS JAHUIRA PILCO — Sat, 04 Jul 2026 23:54:20 +0000

TL;DR: I compared the major CI/CD tools for test automation (GitHub Actions, GitLab CI, Jenkins, CircleCI, Travis CI, TeamCity, Bitbucket Pipelines, Tekton, Harness) — and instead of stopping at a table, I wrote the exact same test pipeline three times: once for GitHub Actions (running live), once for GitLab CI, and once as a Jenkinsfile, all in one public repo so you can compare the syntax line by line. Repo: github.com/Dayan-18/ci-tools-demo →

Why CI is where your tests actually live

A test suite that runs only on your laptop protects exactly one person: you. The moment tests run automatically on every push and pull request, they protect the whole team — and that's the job of a CI/CD tool. In my previous articles I used GitHub Actions to automate SAST scans, IaC scans and API tests. But GitHub Actions is one option among many. How do the alternatives compare?

The landscape

Tool	Hosting	Config	Pricing (open source)	Standout feature	Watch out for
GitHub Actions	SaaS (+ self-hosted runners)	YAML in repo	Free for public repos	Marketplace with 20k+ reusable actions	Vendor lock-in to GitHub
GitLab CI	SaaS or self-hosted	YAML in repo	Free tier + minutes	Single tool: repo, CI, registry, environments	Complex YAML at scale
Jenkins	Self-hosted	Jenkinsfile (Groovy)	100% free, open source	Total control, 1,900+ plugins	You maintain the server, plugins break
CircleCI	SaaS	YAML	Free tier	Very fast, first-class Docker	Credits model gets pricey
Travis CI	SaaS	YAML	Limited free	Historic pioneer for OSS	Lost most mindshare after pricing changes
TeamCity	Self-hosted or Cloud	UI or Kotlin DSL	Free tier	Deep JetBrains IDE integration	Heavier setup
Bitbucket Pipelines	SaaS	YAML	Free tier	Native Jira/Bitbucket integration	Only useful inside Atlassian stack
Tekton	Kubernetes	CRDs (YAML)	Free, CNCF	Cloud-native building blocks	Steep learning curve; it's a framework, not a product
Harness	SaaS	YAML/UI	Free tier	AI-assisted pipelines, deployment verification	Enterprise-oriented complexity

Tables are nice, but syntax is what you live with every day. So let's compare the three most representative tools with real code: the same pipeline — install dependencies, run a pytest suite, publish a JUnit report — written three times.

The test suite (identical for all three)

A small shopping-cart calculator with 10 tests (happy paths, error paths, parametrized cases):

@pytest.mark.parametrize("amount,percent,expected", [
    (100.0, 0, 100.0),
    (100.0, 10, 90.0),
    (100.0, 100, 0.0),
    (59.99, 25, 44.99),
])
def test_apply_discount(amount, percent, expected):
    assert apply_discount(amount, percent) == expected

Running locally:

test_calculator.py::test_subtotal_sums_price_times_quantity PASSED       [ 10%]
test_calculator.py::test_subtotal_empty_cart_is_zero PASSED              [ 20%]
test_calculator.py::test_subtotal_rejects_negative_values PASSED         [ 30%]
test_calculator.py::test_apply_discount[100.0-0-100.0] PASSED            [ 40%]
test_calculator.py::test_apply_discount[100.0-10-90.0] PASSED            [ 50%]
test_calculator.py::test_apply_discount[100.0-100-0.0] PASSED            [ 60%]
test_calculator.py::test_apply_discount[59.99-25-44.99] PASSED           [ 70%]
test_calculator.py::test_apply_discount_rejects_invalid_percent PASSED   [ 80%]
test_calculator.py::test_total_with_tax_default_18_percent PASSED        [ 90%]
test_calculator.py::test_total_with_tax_custom_rate PASSED               [100%]

============================== 10 passed ==============================

Now, the same automation in three dialects.

Round 1: GitHub Actions (`.github/workflows/tests.yml`)

name: Tests (GitHub Actions)

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

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest test_calculator.py -v --junitxml=report-${{ matrix.python-version }}.xml
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: test-report-${{ matrix.python-version }}
          path: report-${{ matrix.python-version }}.xml

Notice the matrix: two Python versions tested in parallel with four extra lines. Reusable actions (actions/setup-python) replace what would be manual scripting elsewhere. This one is running live in the repo — check the Actions tab.

Round 2: GitLab CI (`.gitlab-ci.yml`)

stages:
  - test

.test_template: &test_template
  stage: test
  before_script:
    - pip install -r requirements.txt
  script:
    - pytest test_calculator.py -v --junitxml=report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

test:python3.11:
  <<: *test_template
  image: python:3.11

test:python3.12:
  <<: *test_template
  image: python:3.12

Two things stand out. First, jobs declare a Docker image directly — the container is the environment, no setup action needed. Second, reports: junit is built into the platform: failed tests appear annotated in the merge request UI. The version matrix, though, requires YAML anchors (&template/<<:) — more manual than Actions' matrix.

Round 3: Jenkins (`Jenkinsfile`)

pipeline {
    agent {
        docker { image 'python:3.12' }
    }

    stages {
        stage('Install') {
            steps {
                sh 'pip install -r requirements.txt'
            }
        }

        stage('Test') {
            steps {
                sh 'pytest test_calculator.py -v --junitxml=report.xml'
            }
        }
    }

    post {
        always {
            junit 'report.xml'
        }
    }
}

Jenkins is the only one here that is not YAML — it's a Groovy DSL, which means real programming (variables, conditionals, shared libraries) when you need it. The post { always { junit ... } } block is Jenkins' classic test-report integration. The trade-off is operational: GitHub and GitLab run your pipeline on their servers; with Jenkins, you run the server, the agents, the plugins, and the upgrades.

What the comparison actually teaches

Reading the three files side by side (they're all in the repo), the pattern is obvious: every CI tool automates the same four verbs — trigger, environment, steps, report. The differences are dialect and philosophy: Actions optimizes for reusable building blocks, GitLab for platform integration, Jenkins for control and extensibility. The niche players follow the same verbs too: Tekton expresses them as Kubernetes resources, Bitbucket Pipelines as Atlassian-flavored YAML, Harness wraps them in an enterprise UI.

My recommendation for choosing: if your code lives on GitHub, use Actions; on GitLab, use GitLab CI — fighting your platform's native tool is rarely worth it. Choose Jenkins when you need on-premise control or heavy customization, and Tekton only if your team already breathes Kubernetes.

Conclusion

"Which CI tool should I learn?" is less important than understanding the shared model: trigger → environment → steps → report. Learn it once, and every tool becomes a syntax lookup. The full working example — one suite, three pipelines — is public here: github.com/Dayan-18/ci-tools-demo, with GitHub Actions running it live on every push.

Which CI tool does your team use — and would you switch? Tell me in the comments! 👇

Previous articles in this series: SAST with Bandit · IaC scanning with Checkov · API testing with pytest

References: GitHub Actions docs · GitLab CI docs · Jenkins Pipeline docs · Tekton · CircleCI

API Testing Frameworks Compared — and a Real Suite with Pytest + Requests

DAYAN ELVIS JAHUIRA PILCO — Sat, 04 Jul 2026 23:44:04 +0000

TL;DR: I compared the most popular API testing frameworks (Postman/Newman, REST Assured, Karate, Supertest, pytest+requests), then built a real 14-test suite against a live public API with pytest + requests, covering status codes, JSON schema, error handling, response time and CRUD — all automated in GitHub Actions with a daily scheduled run. Full code: GitHub repo →

Why test APIs directly?

UI tests are slow and fragile; unit tests can't tell you if your service actually talks to the world correctly. API tests sit in the sweet spot of the testing pyramid: fast enough to run on every commit, realistic enough to catch integration bugs — wrong status codes, broken schemas, slow endpoints — before your users do.

The frameworks, compared

There are many tools in this space (Postman's blog lists dozens). Here's an honest comparison of the big five:

Framework	Language	Style	Best for	Watch out for
Postman + Newman	GUI + JS	Collections + scripts	Manual exploration, teams with non-coders	Test logic hidden in JSON exports; hard to code-review
REST Assured	Java	Fluent DSL	Java shops, Spring ecosystems	Verbose; needs Maven/Gradle setup
Karate	Gherkin DSL	BDD feature files	Readable specs, mixing API+UI+perf	Its own language to learn; JVM required
Supertest + Jest	JavaScript	Code	Node.js teams testing their own Express apps	Tied to the JS ecosystem
pytest + requests	Python	Code	Anyone who knows Python; CI-first teams	You assemble the pieces yourself

My pick for this article is pytest + requests, for three reasons: tests are plain Python (reviewable in any PR like normal code), pytest's fixtures and parametrization eliminate boilerplate, and the ecosystem (pytest-xdist for parallelism, jsonschema for contract validation) grows with you.

The target: a real, live API

JSONPlaceholder is a free fake REST API with realistic resources (posts, comments, users...). Perfect to demonstrate every kind of assertion against a real HTTP service — no mocks.

The test suite

The full suite is 14 tests in one file. Let's walk through the interesting parts.

Setup: one session for all tests

import os

import pytest
import requests

BASE_URL = os.environ.get("API_BASE_URL", "https://jsonplaceholder.typicode.com")
TIMEOUT = 10


@pytest.fixture(scope="session")
def session():
    """Reuse one HTTP session for all tests (faster: keep-alive)."""
    with requests.Session() as s:
        s.headers.update({"Accept": "application/json"})
        yield s

Two production-grade details here: the base URL comes from an environment variable, so the same suite runs against dev, staging or production; and a session-scoped fixture reuses one TCP connection for all tests.

Status codes, schema, and the unhappy path

def test_get_single_post_has_expected_schema(session):
    resp = session.get(f"{BASE_URL}/posts/1", timeout=TIMEOUT)
    assert resp.status_code == 200
    post = resp.json()
    # schema validation: keys and types
    assert set(post.keys()) == {"userId", "id", "title", "body"}
    assert isinstance(post["userId"], int)
    assert post["id"] == 1


def test_get_nonexistent_post_returns_404(session):
    resp = session.get(f"{BASE_URL}/posts/9999", timeout=TIMEOUT)
    assert resp.status_code == 404

Testing the error path is where most real bugs hide — an API that returns 200 with an empty body for a missing resource will silently corrupt every client that consumes it.

Non-functional checks: performance and content type

def test_response_time_under_2_seconds(session):
    resp = session.get(f"{BASE_URL}/posts", timeout=TIMEOUT)
    assert resp.elapsed.total_seconds() < 2.0


def test_content_type_is_json(session):
    resp = session.get(f"{BASE_URL}/posts/1", timeout=TIMEOUT)
    assert "application/json" in resp.headers["Content-Type"]

A latency budget as a test means a performance regression fails CI like any other bug.

Writing: POST, PUT, DELETE

def test_create_post_returns_201_and_echoes_body(session):
    payload = {"title": "SAST and API testing", "body": "hello", "userId": 7}
    resp = session.post(f"{BASE_URL}/posts", json=payload, timeout=TIMEOUT)
    assert resp.status_code == 201
    created = resp.json()
    assert created["title"] == payload["title"]
    assert "id" in created

Note the assertion on 201 Created — not just "2xx". Precise status codes are part of your API's contract.

Parametrization: one test, five cases

@pytest.mark.parametrize("resource,expected_count", [
    ("posts", 100),
    ("comments", 500),
    ("albums", 100),
    ("todos", 200),
    ("users", 10),
])
def test_collection_sizes(session, resource, expected_count):
    resp = session.get(f"{BASE_URL}/{resource}", timeout=TIMEOUT)
    assert resp.status_code == 200
    assert len(resp.json()) == expected_count

This is where pytest beats collection-based tools: five endpoints covered in eight lines, and each case reports individually.

Running it

pip install pytest requests
pytest test_api.py -v

test_api.py::test_get_all_posts_returns_200_and_100_items PASSED         [  7%]
test_api.py::test_get_single_post_has_expected_schema PASSED             [ 14%]
test_api.py::test_get_nonexistent_post_returns_404 PASSED                [ 21%]
test_api.py::test_response_time_under_2_seconds PASSED                   [ 28%]
test_api.py::test_content_type_is_json PASSED                            [ 35%]
test_api.py::test_filter_posts_by_user PASSED                            [ 42%]
test_api.py::test_create_post_returns_201_and_echoes_body PASSED         [ 50%]
test_api.py::test_update_post_returns_200 PASSED                         [ 57%]
test_api.py::test_delete_post_returns_200 PASSED                         [ 64%]
test_api.py::test_collection_sizes[posts-100] PASSED                     [ 71%]
test_api.py::test_collection_sizes[comments-500] PASSED                  [ 78%]
test_api.py::test_collection_sizes[albums-100] PASSED                    [ 85%]
test_api.py::test_collection_sizes[todos-200] PASSED                     [ 92%]
test_api.py::test_collection_sizes[users-10] PASSED                      [100%]

============================== 14 passed ==============================

Automating with GitHub Actions — including a daily run

API tests have a property unit tests don't: they can break without any commit, because the API on the other side changes. That's why my workflow adds a schedule trigger on top of push/PR:

name: API Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: "0 6 * * *" # daily run: catch API regressions even without commits

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run API test suite
        run: pytest test_api.py -v --junitxml=report.xml
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: api-test-report
          path: report.xml

If the API breaks its contract overnight, tomorrow at 06:00 UTC this workflow turns red and I get an email — before any user files a bug.

Takeaways

Framework choice matters less than people think — what matters is what you assert: exact status codes (including errors), response schema, latency budgets, and the full CRUD cycle. Code-based frameworks like pytest+requests make those assertions reviewable, versionable, and parametrizable, which is why they scale better in CI than GUI-first tools. And because APIs change under you, a scheduled run is as important as the per-commit one.

Full demo code + workflow: github.com/Dayan-18/api-testing-demo

Which API testing framework does your team use, and why? Tell me in the comments! 👇

Previous articles in this series: SAST for Python with Bandit · IaC scanning with Checkov

References: pytest documentation · requests documentation · JSONPlaceholder

Your Infrastructure Has Bugs Too: Scanning Terraform with Checkov (IaC SAST)

DAYAN ELVIS JAHUIRA PILCO — Sat, 04 Jul 2026 23:24:24 +0000

TL;DR: Application code isn't the only thing that ships vulnerabilities — your Terraform does too. I wrote an intentionally insecure AWS configuration, scanned it with Checkov (a SAST tool for Infrastructure as Code, listed on the OWASP Source Code Analysis Tools page), went from 35 failed checks to 0, and wired the scan into GitHub Actions. Full code: GitHub repo →

SAST for infrastructure? Yes, that's a thing

In my previous article I used Bandit to find security bugs in Python code. But modern applications are deployed with Infrastructure as Code (Terraform, Pulumi, OpenTofu, CloudFormation) — and a misconfigured S3 bucket has caused more real-world data breaches than most code vulnerabilities.

The good news: since infrastructure is now code, it can be statically analyzed like code. That's exactly what Checkov does: an open-source tool (Python, maintained by Prisma Cloud) with 1,000+ built-in policies that scans Terraform, CloudFormation, Kubernetes manifests, Dockerfiles, and more — no cloud credentials needed, it never touches your AWS account.

The target: a deliberately insecure AWS stack

I wrote a main.tf that concentrates the misconfigurations behind many famous breaches:

# Issue 1: S3 bucket - public, unencrypted, no versioning, no logging
resource "aws_s3_bucket" "data" {
  bucket = "company-customer-data-bucket"
  acl    = "public-read"
}

# Issue 2: security group open to the entire internet, including SSH
resource "aws_security_group" "web" {
  name = "web-sg"

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

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

# Issue 3: database publicly accessible, unencrypted, hardcoded password
resource "aws_db_instance" "db" {
  identifier          = "app-db"
  engine              = "mysql"
  instance_class      = "db.t3.micro"
  allocated_storage   = 20
  username            = "admin"
  password            = "SuperSecret123!"
  publicly_accessible = true
  storage_encrypted   = false
  skip_final_snapshot = true
}

# Issue 4: EC2 instance without IMDSv2 and with unencrypted root volume
resource "aws_instance" "app" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  vpc_security_group_ids = [aws_security_group.web.id]

  root_block_device {
    encrypted = false
  }
}

# Issue 5: IAM policy with full admin wildcard
resource "aws_iam_policy" "admin" {
  name = "app-policy"

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

Five resources. Looks harmless, right? Let's see.

Running Checkov

pip install checkov
checkov -f main.tf

The verdict, in a few seconds and without touching AWS:

Passed checks: 14, Failed checks: 35, Skipped checks: 0

35 failed checks in 70 lines of Terraform. Some highlights:

🔴 The public S3 bucket (the classic breach)

Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
    FAILED for resource: aws_s3_bucket.data
Check: CKV2_AWS_6: "Ensure that S3 bucket has a Public Access block"
    FAILED for resource: aws_s3_bucket.data
Check: CKV_AWS_145: "Ensure that S3 buckets are encrypted with KMS by default"
    FAILED for resource: aws_s3_bucket.data

A bucket named company-customer-data-bucket with acl = "public-read" — this exact pattern exposed hundreds of millions of records in real incidents (Capital One, Accenture, the US voter records leak...).

🔴 The god-mode IAM policy

Check: CKV_AWS_62: "Ensure IAM policies that allow full "*-*" administrative
       privileges are not created"
    FAILED for resource: aws_iam_policy.admin
Check: CKV_AWS_286: "Ensure IAM policies does not allow privilege escalation"
    FAILED for resource: aws_iam_policy.admin
Check: CKV_AWS_288: "Ensure IAM policies does not allow data exfiltration"
    FAILED for resource: aws_iam_policy.admin

Action = "*" on Resource = "*" earned eight failed checks by itself: privilege escalation, credentials exposure, data exfiltration... one wildcard, every attack path.

🔴 SSH open to the world + public database

Checkov also flagged the security group allowing 0.0.0.0/0 on port 22 (CKV_AWS_24), the RDS instance with publicly_accessible = true (CKV_AWS_17), no storage encryption (CKV_AWS_16), and the hardcoded database password sitting in version control.

Fixing it

The remediated main_fixed.tf applies standard hardening:

Misconfiguration	Fix
Public S3 bucket	`aws_s3_bucket_public_access_block` + private ACL
Unencrypted bucket	KMS key with rotation + SSE configuration
No versioning/logging	`aws_s3_bucket_versioning` + access logging to a second bucket
SSH open to 0.0.0.0/0	Ingress restricted to a trusted CIDR variable, HTTPS only
Hardcoded DB password	`variable "db_password" { sensitive = true }` via `TF_VAR_db_password`
Public, unencrypted RDS	`publicly_accessible = false`, `storage_encrypted = true`, multi-AZ
EC2 metadata v1	`metadata_options { http_tokens = "required" }` (IMDSv2)
Admin wildcard IAM	Least privilege: `s3:GetObject` on one bucket ARN only

Two checks didn't apply to this workload (cross-region replication, S3 event notifications), so instead of silencing the scanner I documented the decision inline — Checkov's equivalent of Bandit's # nosec:

resource "aws_s3_bucket" "data" {
  #checkov:skip=CKV_AWS_144:Single-region deployment, replication not required
  #checkov:skip=CKV2_AWS_62:No downstream consumers need S3 event notifications
  bucket = "company-customer-data-bucket"
}

The result:

Passed checks: 79, Failed checks: 0, Skipped checks: 5

From 35 failed checks to 0, with every skip justified and auditable. ✅

Automating with GitHub Actions

Same principle as any SAST tool: a manual scan is a snapshot, a CI scan is a security gate. This workflow runs on every push and PR, and fails the build if the hardened configuration regresses:

name: Checkov IaC Scan

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

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install Checkov
        run: pip install checkov
      - name: Scan vulnerable config (findings expected, does not block)
        run: checkov -f main.tf --compact || true
      - name: Scan fixed config (security gate)
        run: checkov -f main_fixed.tf --compact
      - name: Generate JSON report
        if: always()
        run: checkov -f main_fixed.tf -o json > checkov-report.json || true
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: checkov-report
          path: checkov-report.json

Now a pull request that opens port 22 to the internet gets a red ❌ before any human even reviews it.

Strengths and limitations

What impressed me about Checkov: enormous policy coverage out of the box, scans finish in seconds with zero cloud credentials, checks map to real breach patterns, and the graph-based engine understands connections between resources (that's what the CKV2_* checks do — for example, it knows my bucket lacks a Public Access Block resource, not just a bad attribute).

Limitations, in line with what OWASP says about SAST generally: it analyzes declared state, not what actually runs in your account (drift is invisible to it); it can't know your business context, so expect policies that don't apply to your workload — that's what documented skips are for; and it won't catch logic flaws in how your services use the infrastructure. Combine it with cloud posture management (CSPM) and runtime monitoring for full coverage.

Conclusion

The same lesson as application SAST, but the stakes are arguably higher: nobody exploits your off-by-one error as fast as a scanner finds your public S3 bucket. Checkov made 35 concrete problems visible in seconds, taught me the hardening pattern for each one, and now guards my infrastructure on every commit — for free.

Full demo code + workflow: github.com/Dayan-18/checkov-demo

Do you scan your IaC in CI? Which tool? Tell me in the comments! 👇

References: OWASP Source Code Analysis Tools · Checkov documentation · Terraform AWS provider docs

Finding Security Bugs Before They Ship: Applying Bandit (SAST) to a Python Web App

DAYAN ELVIS JAHUIRA PILCO — Sat, 04 Jul 2026 22:40:34 +0000

TL;DR: I took a small Flask application with 7 classic security flaws, ran Bandit (a SAST tool from the OWASP Source Code Analysis Tools list) against it, fixed everything it found, and automated the scan with GitHub Actions so no insecure code reaches main again. Full code: GitHub repo →

What is SAST and why should you care?

Static Application Security Testing (SAST) tools analyze your source code without executing it, looking for patterns that are known to cause vulnerabilities: SQL injection, command injection, weak cryptography, hardcoded secrets, and more.

The main advantage over finding bugs in production? Cost and timing. A SAST scan runs in seconds, inside your IDE or CI pipeline, before the code ever ships. According to OWASP, SAST scales well precisely because it can run repeatedly on every build.

For this experiment I chose Bandit: an open-source SAST tool designed specifically for Python, originally developed within the OpenStack project and now maintained by PyCQA. It builds an AST (Abstract Syntax Tree) from each file and runs security plugins against it.

The target: a deliberately vulnerable Flask app

I wrote a small Flask application that concentrates 7 mistakes you can still find in real-world codebases:

import hashlib
import pickle
import random
import sqlite3
import subprocess

from flask import Flask, request

app = Flask(__name__)

# Issue 1: hardcoded credentials
DB_PASSWORD = "SuperSecret123!"


@app.route("/user")
def get_user():
    # Issue 2: SQL injection (string concatenation)
    username = request.args.get("username")
    conn = sqlite3.connect("users.db")
    query = "SELECT * FROM users WHERE name = '%s'" % username
    return str(conn.execute(query).fetchall())


@app.route("/ping")
def ping():
    # Issue 3: command injection (shell=True with user input)
    host = request.args.get("host")
    result = subprocess.check_output("ping -c 1 " + host, shell=True)
    return result


@app.route("/login", methods=["POST"])
def login():
    # Issue 4: weak hashing algorithm (MD5)
    password = request.form.get("password", "")
    return hashlib.md5(password.encode()).hexdigest()


@app.route("/token")
def token():
    # Issue 5: insecure randomness for security tokens
    return str(random.randint(100000, 999999))


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


if __name__ == "__main__":
    # Issue 7: debug mode enabled in production
    app.run(host="0.0.0.0", debug=True)

Running Bandit

Installation and scan are two commands:

pip install bandit
bandit app.py

In under a second, Bandit reported 10 issues in 35 lines of code:

Run metrics:
    Total issues (by severity):
        Low: 4
        Medium: 3
        High: 3

Here are the most interesting findings:

🔴 High: command injection (B602, CWE-78)

>> Issue: [B602:subprocess_popen_with_shell_equals_true] subprocess call with
   shell=True identified, security issue.
   Severity: High   Confidence: High
   Location: ./app.py:32

With shell=True and unsanitized user input, requesting /ping?host=;cat /etc/passwd executes arbitrary commands on the server.

🔴 High: weak hashing (B324, CWE-327)

>> Issue: [B324:hashlib] Use of weak MD5 hash for security.
   Severity: High   Confidence: High
   Location: ./app.py:40

MD5 has been broken for decades — modern GPUs compute billions of MD5 hashes per second, so leaked password hashes fall quickly.

🔴 High: Flask debug mode (B201, CWE-94)

>> Issue: [B201:flask_debug_true] A Flask app appears to be run with
   debug=True, which exposes the Werkzeug debugger and allows the
   execution of arbitrary code.
   Severity: High   Confidence: Medium

The Werkzeug debugger includes an interactive Python console. Exposing it publicly is handing out remote code execution.

🟡 Medium: SQL injection (B608, CWE-89)

Bandit flags the string-formatted query. Note the Low confidence here — pattern-based detection can't always know if the interpolated value is user-controlled. That's a good reminder that SAST findings need human triage.

Other findings included hardcoded credentials (B105), insecure pickle deserialization (B301, Medium), non-cryptographic random for tokens (B311), and binding to 0.0.0.0 (B104).

Fixing the findings

Every fix is small and idiomatic:

Vulnerability	Fix
Hardcoded password	`os.environ.get("DB_PASSWORD")`
SQL injection	Parameterized query: `execute(query, (username,))`
Command injection	Argument list, no `shell=True`, absolute binary path
MD5 password hash	`hashlib.pbkdf2_hmac("sha256", ..., 600_000)`
Insecure random	`secrets.token_urlsafe(16)`
Pickle deserialization	`json.loads()` for untrusted data
Debug mode + 0.0.0.0	`debug=False`, bind to `127.0.0.1`

For example, the ping endpoint becomes:

@app.route("/ping")
def ping():
    host = shlex.quote(request.args.get("host", ""))
    result = subprocess.check_output(["/usr/bin/ping", "-c", "1", host])  # nosec B603
    return result

The # nosec B603 comment tells Bandit this specific call was reviewed and accepted — an important feature for managing false positives without silencing the whole scanner.

Re-running the scan on the fixed version:

Run metrics:
    Total issues (by severity):
        Low: 0
        Medium: 0
        High: 0

From 10 findings to 0. ✅

Automating with GitHub Actions

A scan you run once is a snapshot; a scan that runs on every push is a security control. This workflow blocks any PR that introduces new findings:

name: Bandit SAST Scan

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

jobs:
  bandit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install Bandit
        run: pip install bandit
      - name: Scan vulnerable app (findings expected, does not block)
        run: bandit app.py || true
      - name: Scan fixed app (security gate)
        run: bandit app_fixed.py
      - name: Upload JSON report
        if: always()
        run: bandit -r . -f json -o bandit-report.json --exclude ./.github || true
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: bandit-report
          path: bandit-report.json

Because Bandit exits with a non-zero code when it finds issues, the job fails and the merge is blocked. The JSON report is archived as an artifact for later review.

Strengths and limitations

What I liked about Bandit: zero-config startup, fast scans that fit any CI budget, findings mapped to CWE with links to documentation, and granular suppression with # nosec.

What it won't do for you — and OWASP is explicit about this for SAST in general: it can't detect authentication or access-control flaws, it doesn't track data flow across services, and some findings (like B608) are educated guesses that require human review. SAST is one layer; combine it with dependency scanning (SCA) and dynamic testing (DAST) for real coverage.

Conclusion

In less than an hour, a free tool found 10 real security issues, taught me the CWE behind each one, and became a permanent quality gate in my pipeline. If you write Python and your CI doesn't run a SAST tool yet, pip install bandit is one of the highest-return security investments you can make today.

Full demo code + workflow: github.com/Dayan-18/bandit-demo

What SAST tool does your team use? Let me know in the comments! 👇

References: OWASP Source Code Analysis Tools · Bandit documentation · CWE Top 25

DEV Community: DAYAN ELVIS JAHUIRA PILCO

CI/CD Testing Tools Compared: the Same Pipeline in GitHub Actions, GitLab CI and Jenkins

Why CI is where your tests actually live

The landscape

The test suite (identical for all three)

Round 1: GitHub Actions (.github/workflows/tests.yml)

Round 2: GitLab CI (.gitlab-ci.yml)

Round 3: Jenkins (Jenkinsfile)

What the comparison actually teaches

Conclusion

API Testing Frameworks Compared — and a Real Suite with Pytest + Requests

Why test APIs directly?

The frameworks, compared

The target: a real, live API

The test suite

Setup: one session for all tests

Status codes, schema, and the unhappy path

Non-functional checks: performance and content type

Writing: POST, PUT, DELETE

Parametrization: one test, five cases

Running it

Automating with GitHub Actions — including a daily run

Takeaways

Your Infrastructure Has Bugs Too: Scanning Terraform with Checkov (IaC SAST)

SAST for infrastructure? Yes, that's a thing

The target: a deliberately insecure AWS stack

Running Checkov

🔴 The public S3 bucket (the classic breach)

🔴 The god-mode IAM policy

🔴 SSH open to the world + public database

Fixing it

Automating with GitHub Actions

Strengths and limitations

Conclusion

Finding Security Bugs Before They Ship: Applying Bandit (SAST) to a Python Web App

What is SAST and why should you care?

The target: a deliberately vulnerable Flask app

Running Bandit

🔴 High: command injection (B602, CWE-78)

🔴 High: weak hashing (B324, CWE-327)

🔴 High: Flask debug mode (B201, CWE-94)

🟡 Medium: SQL injection (B608, CWE-89)

Fixing the findings

Automating with GitHub Actions

Strengths and limitations

Conclusion

Round 1: GitHub Actions (`.github/workflows/tests.yml`)

Round 2: GitLab CI (`.gitlab-ci.yml`)

Round 3: Jenkins (`Jenkinsfile`)