DEV Community: Hariharan

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 6: The Full Pipeline

Hariharan — Sun, 26 Apr 2026 11:23:18 +0000

If you've followed along from Part 1, we have built five separate scanning
workflows. This final part replaces them with a single unified pipeline —
one YAML file, one run, everything in the right order.

The pipeline structure
The five individual workflow files are deleted and replaced with one:
.github/workflows/devsecops-pipeline.yml

name: DevSecOps Pipeline

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:

  secret-scan:
    name: Secret Scanning - Gitleaks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  sast:
    name: SAST - Bandit
    runs-on: ubuntu-latest
    needs: secret-scan
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install Bandit
        run: pip install bandit
      - name: Run Bandit
        run: bandit -r app.py --severity-level high -f json -o bandit-report.json
      - name: Upload Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: bandit-report
          path: bandit-report.json

  sca:
    name: SCA - pip-audit
    runs-on: ubuntu-latest
    needs: secret-scan
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install pip-audit
        run: pip install pip-audit
      - name: Run pip-audit
        run: pip-audit -r requirements.txt -f json -o pip-audit-report.json
      - name: Upload Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: pip-audit-report
          path: pip-audit-report.json

  iac:
    name: IaC - Checkov
    runs-on: ubuntu-latest
    needs: secret-scan
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install Checkov
        run: pip install checkov
      - name: Run Checkov
        run: checkov -d terraform/ -o json > checkov-report.json
      - name: Upload Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: checkov-report
          path: checkov-report.json

  container-scan:
    name: Container Scan - Trivy
    runs-on: ubuntu-latest
    needs: [sast, sca, iac]
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t devsecops-demo:${{ github.sha }} .
      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: devsecops-demo:${{ github.sha }}
          format: json
          output: trivy-report.json
          severity: CRITICAL,HIGH
          exit-code: 1
      - name: Upload Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: trivy-report
          path: trivy-report.json

The logic is deliberate:

Secret scanning runs first. If credentials are found in the code, nothing else runs. There's no value in scanning code that's already compromised.
SAST, SCA, and IaC run in parallel after secrets pass. These are independent checks — no reason to run them sequentially. Running in parallel keeps the pipeline fast.
Container scanning runs last. It only runs if the three parallel scans all pass. If the code has known vulnerabilities, there's no point building and scanning the image.

What the pipeline run looks like

Secret Scanning passed — no leaks detected. SAST, SCA, and IaC all failed
because the demo app is deliberately broken. Container Scan was skipped.
That skipped Trivy stage is worth explaining. It's not a failure — it's the pipeline working correctly. GitHub Actions skips a job when its dependencies fail. Trivy needed Bandit, pip-audit, and Checkov to all pass before it would run. They didn't, so it didn't. There's no point scanning a container image built from code you already know is vulnerable.
In a real project where the code is clean, all five stages would run and the pipeline would either pass completely or fail at Trivy if the image has CVEs.

What this pipeline catches
Across the five parts of this series, the pipeline found:

Secrets — AWS access keys hardcoded in app.py, caught before commit and at push time
Code vulnerabilities — SQL injection, eval() on user input, debug=True in Flask, all flagged by Bandit
Vulnerable dependencies — 37 known CVEs across 6 packages in requirements.txt, caught by pip-audit
Infrastructure misconfigurations — 18 failed Checkov checks including a public S3 bucket, unencrypted EBS, and no IMDSv2 enforcement
Container CVEs — 1,747 vulnerabilities in the Docker image, 185 of them CRITICAL, caught by Trivy

None of this required a security expert. Each tool is open source, free,
and wired into a standard GitHub Actions workflow.

What this pipeline doesn't catch

DAST — Dynamic Application Security Testing scans a running application for vulnerabilities. Nothing here does that. Tools like OWASP ZAP fill this gap.
Runtime security — once the container is running in production, nothing here monitors it. Tools like Falco watch for suspicious behaviour at runtime.
Secrets in git history — Gitleaks scans current files and recent commits. A secret committed years ago and deleted may still be in history.
Logic flaws — no static analysis tool catches business logic vulnerabilities. Those require manual review.

The repo
Everything built across this series is at
https://github.com/pkkht/devsecops-demo — the vulnerable Flask app, the Terraform, the Dockerfile, and all the GitHub Actions workflows.
Clone it, run the pipeline, break things deliberately, and see what gets caught.

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 5 - Container Scanning with Trivy

Hariharan — Sun, 26 Apr 2026 11:00:03 +0000

The previous parts secured the code and the infrastructure. This part secures the container image — the thing that actually runs in production.
When you build a Docker image, you're not just shipping your application.
You're shipping the entire base image underneath it — the OS, the system
libraries, the package manager, all of it. Every CVE in those packages is
now your problem.

Code repo: https://github.com/pkkht/devsecops-demo/

What container scanning is
Container scanning analyses a built Docker image for known vulnerabilities. It inspects the OS layer, every installed package, and the application dependencies, then cross-references each one against public CVE databases. The key insight: most of the vulnerabilities in a container image come from the base image, not from the application code. Choosing an old or full base image can introduce hundreds of vulnerabilities before you've written a single line of your own code.

The tool: Trivy
Trivy is an open source vulnerability scanner from Aqua Security. It scans container images, filesystems, git repositories, Kubernetes clusters, and more. It queries multiple vulnerability databases including the NVD, GitHub Advisory Database, and OS-specific advisories. It's free, fast, and requires no account or API key.

The demo Dockerfile
The Dockerfile in the repo has two intentional issues:

# ISSUE 1: Using python:3.8 (not slim, not alpine)
# An older, full base image with many OS-level packages = more CVE surface.
# The fix: use python:3.11-slim or python:3.11-alpine.
FROM python:3.8

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

# ISSUE 2: No USER directive — container runs as root
# Running as root means if the app is compromised, the attacker
# has root inside the container.
# The fix:
#   RUN adduser --disabled-password --gecos '' appuser
#   USER appuser

EXPOSE 5000
CMD ["python", "app.py"]

python:3.8 is a full Debian-based image. It includes everything — compilers, build tools, image processing libraries, the lot. Most of it is unnecessary for running a Flask API, but all of it adds CVE surface.

GitHub Actions workflow
Create .github/workflows/container-scan.yml:

name: Container Scan - Trivy

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  trivy:
    name: Trivy Container Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t devsecops-demo:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: devsecops-demo:${{ github.sha }}
          format: json
          output: trivy-report.json
          severity: CRITICAL,HIGH
          exit-code: 1

      - name: Upload Trivy Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: trivy-report
          path: trivy-report.json

severity: CRITICAL,HIGH tells Trivy to only report and gate on CRITICAL and HIGH findings — ignoring MEDIUM and LOW keeps the noise manageable.
exit-code: 1 fails the build when findings are found.

What the pipeline found

The pipeline failed immediately.

The trivy-report.json artifact from the Actions run tells the full story.
Total: 1,747 vulnerabilities
OS layer (Debian 12.7): 1,736 vulnerabilities
CRITICAL: 185
HIGH: 1,551

Python packages: 11 vulnerabilities
HIGH: 11

OS layer findings
The python:3.8 base image ships with ImageMagick, which alone accounts for
185 CRITICAL findings. ImageMagick is an image processing library with a long history of CVEs. You almost certainly don't need it in a Flask API container, but because python:3.8 is a full Debian image, it's there anyway.

Python package findings
The application dependencies contributed 11 HIGH severity findings:

These overlap with what pip-audit found in Part 4 — Trivy is scanning the same packages but from inside the built image rather than from
requirements.txt. Both tools catching the same issues is a good sign.

A sample finding from the JSON report

{
  "VulnerabilityID": "CVE-2023-30861",
  "PkgName": "Flask",
  "InstalledVersion": "1.1.2",
  "FixedVersion": "2.2.5, 2.3.2",
  "Severity": "HIGH",
  "Title": "Flask vulnerable to possible disclosure of permanent session cookie"
}

The fix is simple

Both issues in the Dockerfile have straightforward fixes:
Switch to a slim base image:

# Before
FROM python:3.8

# After
FROM python:3.11-slim

python:3.11-slim is a minimal Debian image — no ImageMagick, no compilers, no build tools. The CVE count drops dramatically.

Add a non-root user:

RUN adduser --disabled-password --gecos '' appuser
USER appuser

The container no longer runs as root.
These two changes would eliminate the vast majority of the 1747 findings.
They are intentionally left in the demo so the pipeline has something real
to catch.

What we've built so far
Six layers now in place:

Gitleaks pre-commit — blocks secrets at commit time
Gitleaks GitHub Actions — catches secrets at push time
Bandit GitHub Actions — catches code vulnerabilities, gates on HIGH
pip-audit GitHub Actions — catches vulnerable dependencies
Checkov GitHub Actions — catches Terraform misconfigurations
Trivy GitHub Actions — catches CVEs in the container image

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 4 - IaC Scanning with Checkov

Hariharan — Sun, 26 Apr 2026 10:28:06 +0000

The previous parts covered application security — secrets, code vulnerabilities, and dependency CVEs. This part shifts to the infrastructure side. The Terraform in the repo describes the AWS resources the app would run on. If that infrastructure is misconfigured, it doesn't matter how clean the application code is. IaC scanning catches those misconfigurations before terraform apply ever runs.

Code repo: https://github.com/pkkht/devsecops-demo/

What IaC scanning is
Infrastructure as Code scanning analyses your Terraform, CloudFormation,
Kubernetes manifests, or Helm charts for security misconfigurations. It works the same way as SAST — static analysis, no cloud connection required. It checks your configuration files against a library of security rules and tells you what's wrong and how to fix it.
The value is catching misconfigurations at code review time rather than after they've been deployed to a live environment. An open S3 bucket found in a Terraform file takes seconds to fix. The same bucket found after a data exposure incident is a very different conversation.

The tool: Checkov
Checkov is an open source IaC scanner maintained by Bridgecrew (now part of Palo Alto Networks). It supports Terraform, CloudFormation, Kubernetes, Helm, ARM, Bicep, and more. It maps findings to CWE and CVE identifiers and has over 1000 built-in rules for AWS, Azure, and GCP.

The demo Terraform

The terraform/main.tf in the repo contains 6 intentional misconfigurations:

S3 bucket without server-side encryption — data at rest is unencrypted
S3 bucket set to public-read — all objects exposed to the internet
S3 bucket versioning not enabled — no recovery from accidental deletion
Security group open to 0.0.0.0/0 on all ports — any IP, any port
EC2 with unencrypted EBS root volume — encrypted = false
No IMDSv2 enforcement — SSRF attacks can reach the instance metadata service

Local setup is skipped here for brevity — Checkov has known issues running
on Windows paths with spaces. The GitHub Actions workflow handles the scan
in a clean Linux environment.

GitHub Actions workflow
Create .github/workflows/iac.yml:

name: IaC - Checkov

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  checkov:
    name: Checkov IaC Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install Checkov
        run: pip install checkov

      - name: Run Checkov
        run: checkov -d terraform/ -o json > checkov-report.json

      - name: Upload Checkov Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: checkov-report
          path: checkov-report.json

What the pipeline found

The workflow failed as expected. GitHub Actions downloaded the checkov-report.json artifact which contains the full findings. Here's a snapshot of what Checkov caught — 18 failed checks across 4 resources:

"summary": {
  "passed": 10,
  "failed": 18,
  "skipped": 0,
  "resource_count": 4,
  "checkov_version": "3.2.524"
}

The intentional misconfigurations were all caught, plus several additional
issues Checkov flagged that weren't in the original list. That's worth
noting — a real codebase will always have more findings than you expect.

Breaking down the failed checks by resource:

aws_security_group.app_sg — 5 failures

The wide-open ingress rule (from_port = 0, to_port = 65535, cidr = 0.0.0.0/0) triggered multiple checks because Checkov evaluates each port range independently. One misconfiguration, five findings.

aws_instance.app_server — 5 failures

aws_s3_bucket.app_storage — 8 failures

A single example finding from the JSON report:

{
  "check_id": "CKV_AWS_79",
  "check_name": "Ensure Instance Metadata Service Version 1 is not enabled",
  "check_result": { "result": "FAILED" },
  "resource": "aws_instance.app_server",
  "file_path": "/main.tf",
  "file_line_range": [81, 102]
}

Why 18 failures from 6 misconfigurations
One thing worth explaining for readers who run this themselves — you'll see more failures than the 6 intentional misconfigurations. Checkov has over 1000 rules and many of them overlap. A single misconfigured security group rule triggers checks for SSH, RDP, HTTP, and unrestricted egress separately. A single S3 bucket without proper access controls triggers checks for ACLs, public access blocks, KMS encryption, versioning, and logging independently.
This is expected behaviour, not noise. Each check represents a distinct
security concern, and a real security review would assess each one individually.

What we've built so far
Five layers now in place:

Gitleaks pre-commit — blocks secrets at commit time
Gitleaks GitHub Actions — catches secrets at push time
Bandit GitHub Actions — catches code vulnerabilities, gates on HIGH severity
pip-audit GitHub Actions — catches vulnerable dependencies
Checkov GitHub Actions — catches Terraform misconfigurations before deployment

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 3 - SCA with pip-audit

Hariharan — Sun, 26 Apr 2026 09:49:02 +0000

Parts 1 and 2 covered the code you write — secrets and static vulnerabilities in app.py. But modern applications are mostly made up of code you didn't write. Every package in requirements.txt is someone else's code running in your app. If any of those packages have known vulnerabilities, your app inherits them.
That's what SCA is for.

Code repo: https://github.com/pkkht/devsecops-demo/

What SCA is
SCA stands for Software Composition Analysis. It looks at your dependency list, checks each package version against public vulnerability databases, and reports any known CVEs. It doesn't analyse your code — it analyses what your code depends on. This matters because a lot of real-world breaches don't come from custom code at all. They come from a vulnerable library that nobody noticed was outdated.

The tool: pip-audit
pip-audit is maintained by the Python Packaging Authority (PyPA) — the same group that maintains pip itself. It queries the Python Packaging Advisory Database (PyPA Advisory DB) and the OSV database for known vulnerabilities. It's free, open source, and requires no account or API key.

pip install pip-audit
pip-audit --version

The demo dependencies
The requirements.txt in the repo contains intentionally outdated packages with known CVEs:

Flask==1.1.2
Jinja2==2.11.3
Werkzeug==1.0.1
requests==2.20.0
itsdangerous==1.1.0
SQLAlchemy==1.3.20
click==7.1.2

These are real versions that were in production use a few years ago. A lot of projects still have dependency files that haven't been updated in that kind of timeframe.

Running pip-audit

pip-audit -r requirements.txt

37 known vulnerabilities across 6 packages. That's from 7 packages in
requirements.txt — only one came back clean. Some of the findings worth noting:

Flask 1.1.2 — 2 vulnerabilities, fixed in 2.2.5
Jinja2 2.11.3 — 4 vulnerabilities including CVE-2024-22195 and CVE-2024-34064, fixed in 3.1.3+
Werkzeug 1.0.1 — 13 vulnerabilities, the most of any package, fixed versions ranging up to 3.1.6
requests 2.20.0 — 5 vulnerabilities including CVE-2024-35195 and CVE-2026-25645, fixed in 2.31.0+
urllib3 — 13 vulnerabilities flagged as a transitive dependency (pulled in by requests)

The fix version column tells you exactly what to upgrade to. That's the
output you hand to a developer — not a vague warning, but a specific action.

Generating a JSON report

pip-audit -r requirements.txt -f json -o pip-audit-report.json

Same findings, machine-readable output. Add it to .gitignore so it doesn't get committed to the repo:

GitHub Actions workflow

Create .github/workflows/sca.yml:

name: SCA - pip-audit

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  pip-audit:
    name: pip-audit SCA Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install pip-audit
        run: pip install pip-audit

      - name: Run pip-audit
        run: pip-audit -r requirements.txt -f json -o pip-audit-report.json

      - name: Upload pip-audit Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: pip-audit-report
          path: pip-audit-report.json

Push and watch it run:

The pipeline fails at the Run pip-audit step — "Found 37 known
vulnerabilities in 6 packages", exit code 1. The report is still uploaded
as an artifact via the if: always() step so the findings are available even though the build failed.
Again — this is the correct behaviour. The pipeline found real vulnerabilities and stopped the build. In a real project the fix is straightforward: update the packages to the versions shown in the Fix Versions column, push again, and the build passes.

What we've built so far
Four layers now in place:

Gitleaks pre-commit — blocks secrets at commit time
Gitleaks GitHub Actions — catches secrets at push time
Bandit GitHub Actions — catches code vulnerabilities, gates on HIGH severity
pip-audit GitHub Actions — catches vulnerable dependencies

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 2 - SAST with Bandit

Hariharan — Sun, 26 Apr 2026 09:32:22 +0000

Part 1 covered secret scanning with Gitleaks — catching credentials before they reach the repo. That's one layer. But credentials aren't the only problem in app.py. There's a SQL injection vulnerability, an eval() call that lets an attacker run arbitrary Python code, and debug mode left on. None of those are secrets. Gitleaks won't touch them.
That's what SAST is for.

Code repo: https://github.com/pkkht/devsecops-demo/

What SAST is

SAST stands for Static Application Security Testing. It analyses your source code without running it, looking for patterns that indicate security vulnerabilities. No server needed, no database, no HTTP requests — just the code itself.
The key difference from a linter: SAST is specifically looking for security issues, not style or correctness. It knows what SQL injection looks like. It knows which Python functions are dangerous. It knows that debug=True in a Flask app exposes the Werkzeug interactive debugger to anyone who can reach it.

The tool: Bandit

Bandit is the standard SAST tool for Python.
It is open source, maintained by the Python Security community, and maps its findings to CWE (Common Weakness Enumeration) IDs so you know exactly what class of vulnerability you're dealing with.

Installing Bandit

pip install bandit
bandit --version

Running it against the app

bandit -r app.py

The -r flag means recursive — scan the directory, not just a single file. Here it's running against app.py directly.

The first findings are hardcoded passwords — supersecretkey123, the API token, the AWS keys. These are all flagged as B105: hardcoded_password_string, severity Low. Bandit and Gitleaks overlap here — both tools catch hardcoded credentials, just from different angles.

The more serious findings:

B608: hardcoded_sql_expressions — the f-string SQL query on line 69. Severity Medium. This is the SQL injection vulnerability — user input is
embedded directly into the query string.

B307: blacklist — the eval() call on line 127. Severity Medium,
Confidence High. Bandit flags eval() as blacklisted because it executes
arbitrary code. An attacker who can reach the /calculate endpoint can run anything on the server.

B201: flask_debug_true — debug=True on line 137. Severity High.
The Werkzeug debugger is interactive — if an unhandled exception hits in
production, anyone who sees the error page gets a Python shell.

B104: hardcoded_bind_all_interfaces — host="0.0.0.0" on line 137.
Severity Medium. The app is listening on every network interface, not just
localhost.

The summary: 81 lines of code, 8 issues total — 4 Low, 3 Medium, 1 High.

Filtering by severity
In a real pipeline you don't want to fail on every Low finding — you'd never ship anything. The practical approach is to gate on High severity only, and report everything else for visibility.

bandit -r app.py --severity-level high

With --severity-level high, only one finding comes through: the Flask
debug=True. That's the gate. Everything else is still visible in the full report but won't block the build.

Generating a JSON report

bandit -r app.py -f json -o bandit-report.json

The JSON output is what the pipeline uses — it's machine-readable and can be uploaded as a build artifact. One thing to watch: the report contains the actual secret values from the code as context snippets. Add it to .gitignore so it doesn't get committed.

GitHub Actions workflow
Create .github/workflows/sast.yml:

name: SAST - Bandit

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  bandit:
    name: Bandit SAST Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install Bandit
        run: pip install bandit

      - name: Run Bandit
        run: bandit -r app.py --severity-level high -f json -o bandit-report.json

      - name: Upload Bandit Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: bandit-report
          path: bandit-report.json

if: always() on the upload step is important — it means the report gets
uploaded even when the scan fails, so you can inspect the findings.
Push it and watch it run:

The pipeline fails. This is the right outcome — Bandit found a HIGH severity issue (debug=True) and exited with code 1. The bandit-report artifact is still uploaded and available for download.
This is the pipeline doing its job. In a real codebase, a developer would fix debug=True, push again, and the build would pass. In this demo repo the vulnerability is intentional, so we leave it failing as a demonstration that the gate is real.

What we've built so far
Three layers are now in place:

Gitleaks pre-commit hook — blocks secrets at commit time
Gitleaks GitHub Actions — catches secrets at push time
Bandit GitHub Actions — catches code vulnerabilities at push time, gates on HIGH severity

DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 1 - Secret Scanning with Gitleaks

Hariharan — Sun, 26 Apr 2026 08:48:08 +0000

Secret Scanning with Gitleaks

I have built a deliberately vulnerable Flask app to use as a target for building a real DevSecOps pipeline. The repo is at
https://github.com/pkkht/devsecops-demo.

This part covers the first gate in the pipeline — secret scanning.

Why secrets in code are such a big deal?
AWS access keys, API tokens, database passwords — they end up in source code more often than you would think. A developer hardcodes a key to test something locally, forgets to remove it, and commits it. If the repo is public even for a minute, bots are scanning GitHub continuously and will find it.
It is one of the most preventable attack vectors and one of the most common. The fix is to catch it before the commit happens.

The demo app already has secrets in it - intentionally added.

We will use Gitleaks to catch the exposed secrets.

What is Gitleaks
Gitleaks is an open source secret scanner. It scans your code and git history for secrets using a set of regex rules covering AWS keys, GitHub tokens, private keys, generic API keys, and more. It is free, fast, and has no dependencies on any cloud service.

Setting it up locally with pre-commit
The goal is to stop secrets at the developer's machine — before they even
become a commit.

Step 1: Install pre-commit

pre-commit is a framework for managing git hooks. It handles downloading and running Gitleaks automatically — you do not need to install Gitleaks separately.

pip install pre-commit
pre-commit --version
pre-commit install

The last command wires Gitleaks into your .git/hooks/pre-commit so it runs automatically on every git commit.

Step 2: Create the config file
Create .pre-commit-config.yaml in your repo root:

Seeing it in action
Let's try to commit app.py with the secrets still in it:

git add app.py
git commit -m "add task manager app"

First attempt — before the config file was in place:

pre-commit requires a .pre-commit-config.yaml to be present. Once that is added, try again:

The commit is blocked. Gitleaks downloads itself, scans the staged files, and reports two findings — the AWS access key and the secret key — with the exact file and line number. The commit never happens. This is the behaviour you want. A developer cannot accidentally push a secret
without actively bypassing the hook.

Handling intentional secrets in a demo repo

In a real codebase, a finding like this means: remove the secret, rotate it, use an environment variable instead. But this is a demo repo — the secrets are intentional. We need a way to tell Gitleaks "I know about these, ignore them."
That's what .gitleaksignore is for. You add the fingerprints of known,
intentional findings:

The fingerprints come directly from the Gitleaks output and an additional line that you may wish to add — file:rule:line.
Once added, the commit goes through:

"Detect hardcoded secrets... Passed"
In a real project, .gitleaksignore is useful for allowlisting known false
positives — test fixtures, example keys in documentation. It is not a way to skip real secrets.

Wiring it into GitHub Actions

The pre-commit hook covers local commits. But what if someone bypasses it with --no-verify, or clones the repo without setting up pre-commit? The pipeline is the safety net.
Create .github/workflows/secret-scan.yml:

name: Secret Scanning

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  gitleaks:
    name: Gitleaks Secret Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

fetch-depth: 0 is important — it tells GitHub Actions to check out the full git history, not just the latest commit. Gitleaks needs the full history to scan previous commits for secrets.
GITHUB_TOKEN is automatically provided by GitHub on every workflow run —
you don't need to create it. Gitleaks uses it to post findings as job summaries.
Push the workflow file and watch it run in the Actions tab:

"No leaks detected" — the pipeline passes because the .gitleaksignore
covers the intentional secrets in the repo.

What we've built so far

Two layers of secret scanning are now in place:

Pre-commit hook — catches secrets at the developer's machine before commit
GitHub Actions workflow — catches anything that slips through at push time

The pipeline now has its first gate. Every push and pull request is
automatically scanned for secrets.

My experience in passing HashiCorp Certified: Terraform Associate (003) exam

Hariharan — Wed, 01 Nov 2023 18:48:56 +0000

Straight to the subject point:

It took me less than 2 months to prepare for the exam and I attended the exam on Nov 1, 2023. I passed with the score of 93%.
I thought I would share my exam preparation experience.

Firstly, I started reading this book "Terraform: Up and Running" by Brikman.
https://learning.oreilly.com/library/view/terraform-up/9781492046899/

This book gave me a good understanding of IaC and Terraform workflow. I strongly recommend reading the first 5 chapters in the book for the exam. And don't forget to practise the Terraform coding whilst reading! I used AWS cloud to provision resources as mentioned in the book. (It doesn't matter which cloud provider you choose.)

HashiCorp has good documentation of the Terraform product and I used that as a reference too.

Once I got confidence with the basics, I started doing the practice tests that are available in Udemy and O'Reilly. I had 80% as a benchmark in passing these exams. The tests available in these sites come with detailed explanations for the answers.

That is it! Good luck with your exam preparation!!