Security February 6, 2026 · 3 min read

Secret Scanning in CI Pipelines: A Practical Guide

Credentials in code remain one of the most common attack vectors. We walk through setting up dual-engine secret scanning in your CI/CD pipeline with Gitleaks and TruffleHog.

Introduction

Leaked credentials remain one of the most exploited attack vectors in modern software. API keys, database passwords, and cloud access tokens committed to version control have led to some of the most publicised breaches in recent years. The fix is not just developer education; it is automated, layered detection built into your CI/CD pipeline.

This guide walks through implementing dual-engine secret scanning using Gitleaks and TruffleHog, two complementary tools that catch different categories of secrets.

Why Two Tools?

No single scanner catches everything. Gitleaks excels at pattern-based detection using configurable regex rules, catching API keys, tokens, and passwords that match known formats. TruffleHog takes a different approach: it detects high-entropy strings and can verify discovered secrets against live APIs to confirm they are active. Running both provides defence in depth.

Dual-engine secret scanning architecture — A dual-engine approach catches both pattern-based secrets (Gitleaks) and high-entropy credentials (TruffleHog).

Setting Up Gitleaks

Gitleaks integrates natively with GitHub Actions, GitLab CI, and most CI platforms. The basic setup scans every pull request for secrets before the code can be merged. A custom configuration file lets you add rules for your organisation's internal secret formats and whitelist known false positives.

# .github/workflows/secret-scan.yml
name: Secret Scan
on: [pull_request]
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_CONFIG: .gitleaks.toml

Adding TruffleHog

TruffleHog's verification capability is its standout feature. Rather than simply flagging potential secrets, it can confirm whether a discovered AWS key, Slack token, or GitHub PAT is actually valid. This dramatically reduces false positives and lets your team focus on real exposures.

Run TruffleHog as a pre-commit hook for immediate feedback during development.
Add it as a CI step alongside Gitleaks for belt-and-suspenders coverage.
Schedule periodic full-history scans to catch secrets committed before scanning was enabled.
Integrate alerts with your incident response workflow for automatic rotation triggers.

Secret scanning pipeline flow — The complete pipeline: pre-commit hooks catch secrets early, CI scanning prevents merges, and scheduled scans cover historical commits.

Handling Discoveries

Finding a secret is only half the battle. Your response workflow should include: immediate revocation of the compromised credential, rotation of any related secrets, an audit of where the credential was used, and a post-incident review to prevent recurrence. Automating the first two steps, revocation and rotation, is worth the investment.

Conclusion

Secret scanning is not optional; it is a baseline security control. Implementing dual-engine scanning with Gitleaks and TruffleHog takes less than an hour and provides continuous protection against one of the most common and preventable attack vectors. At CaeliCode, we build these controls into every CI/CD pipeline we design.

Talk to us about this Read more posts