Secrets Scanner

What is a Secrets Scanner?

A secrets scanner checks your code, configuration files, and environment variables for accidentally committed credentials. Leaked API keys, database passwords, and private keys are among the most common causes of security breaches. Tools like TruffleHog, Gitleaks, and detect-secrets run in CI/CD pipelines, but this scanner works entirely in your browser — nothing is sent to any server.

Why Scan .env Files and Configs?

The #1 rule of secrets management is: never commit secrets to version control. Yet it happens constantly — a developer adds a quick .env file with real credentials, forgets to add it to .gitignore, and pushes to a public repo. Automated bots scan GitHub for leaked AWS keys within seconds of a push.

This tool helps you catch secrets before they reach your repository. Paste your code, CI/CD configs, Docker Compose files, Kubernetes manifests, or Terraform configs and review the results before committing.

Detected Secret Types

Shannon Entropy Analysis

Beyond pattern matching, this tool uses Shannon entropy to detect high-randomness strings that look like secrets even if they don't match a known pattern. Entropy measures how "random" a string is — truly random strings (like API keys or hashes) have high entropy (4.5+ bits/char for base64, 3.5+ for hex), while normal text averages around 3.5-4.0.

This catches custom tokens, internal API keys, and secrets from less common services that may not have a vendor-specific pattern.

CLI Equivalents

Copy# TruffleHog — scan a git repo
trufflehog git file://./my-repo --only-verified

# Gitleaks — scan local directory
gitleaks detect --source . --no-git

# detect-secrets — scan files
detect-secrets scan --all-files

Secret Leak Prevention Best Practices

1. Use .gitignore — Exclude .env, *.pem, *.key from version control (use our .gitignore Generator to build one)
2. Pre-commit hooks — Run Gitleaks or detect-secrets as a git pre-commit hook to block commits containing secrets
3. CI/CD pipeline scanning — Add TruffleHog or Gitleaks to your CI pipeline for automated detection
4. Use secret managers — Store credentials in HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets instead of code
5. Rotate immediately — If a secret is leaked, revoke and rotate it before removing from git history

Secret Remediation Guide

Finding a leaked secret is step one. The critical next step is immediate remediation — revoke, rotate, and audit. Simply removing the secret from code is not enough because git history preserves the old value.

Time is critical: automated bots scan public repos within minutes. AWS keys leaked to GitHub are typically exploited within 5 minutes for crypto mining. Always revoke first, then investigate.

Removing Secrets from Git History

Deleting a secret in a new commit does not remove it from git history. Anyone with repo access can find it via git log -p. Use these tools to rewrite history:

# git filter-repo (recommended, faster than BFG)
# Install: pip install git-filter-repo
git filter-repo --path-glob '*.env' --invert-paths
git filter-repo --replace-text <(echo 'AKIAIOSFODNN7EXAMPLE==>***REMOVED***')

# BFG Repo-Cleaner (simpler for common cases)
# Install: brew install bfg
bfg --replace-text passwords.txt my-repo.git
bfg --delete-files '*.pem' my-repo.git

# After rewriting history, force push ALL branches
git push --force --all
git push --force --tags

# IMPORTANT: All collaborators must re-clone the repo
# Old clones still contain the secret in their local history

For public repos, assume the secret is already compromised regardless of how quickly you remove it. Always revoke and rotate before cleaning up git history.

CI/CD Pipeline Integration

Automated secret scanning in CI/CD catches leaks before they reach production. Here are integration patterns for popular platforms:

# GitHub Actions — Gitleaks
name: Secret Scan
on: [push, 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 }}

# GitLab CI — TruffleHog
secret_scan:
  image: trufflesecurity/trufflehog:latest
  script:
    - trufflehog git file://. --since-commit HEAD~1 --fail
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Pre-commit hook (local, blocks commits with secrets)
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Kubernetes Secrets Are Not Encrypted

A common misconception: Kubernetes Secrets are base64-encoded, not encrypted. Anyone with RBAC access to the namespace can decode them instantly with kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d. By default, etcd stores Secrets in plaintext.

SOPS: Encrypted Secrets in Git

SOPS (Secrets OPerationS, by Mozilla) encrypts values in YAML/JSON files while keeping keys readable — so you can review diffs and track changes in git. It supports AWS KMS, GCP KMS, Azure Key Vault, age, and PGP for encryption.

# Encrypt a secrets file (values encrypted, keys stay readable)
sops --encrypt --age age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p \
  secrets.yaml > secrets.enc.yaml

# Result: keys are readable, values are encrypted
# apiVersion: v1
# data:
#   password: ENC[AES256_GCM,data:abc123...,type:str]

# Decrypt at deploy time
sops --decrypt secrets.enc.yaml | kubectl apply -f -

# Edit encrypted file in-place (decrypts, opens editor, re-encrypts)
sops secrets.enc.yaml

# .sops.yaml — configure default encryption per path
creation_rules:
  - path_regex: .*\.enc\.yaml$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

Unlike Sealed Secrets (K8s-only), SOPS works with any YAML/JSON file — Terraform tfvars, Ansible vault alternatives, Docker Compose overrides, Helm values. It's the most flexible option for storing encrypted secrets alongside your code.

GitHub & GitLab Native Push Protection

Both GitHub and GitLab now offer server-side secret scanning that blocks pushes containing detected secrets before they reach the repository:

# GitHub Push Protection (free for public repos, GHAS for private)
# Settings → Code security → Secret scanning → Enable push protection
# Detects 200+ token patterns from 100+ service providers
# Blocks the push with an actionable error message

# GitLab Secret Detection (all tiers, CI-based)
# Add to .gitlab-ci.yml:
include:
  - template: Security/Secret-Detection.gitlab-ci.yml

# GitLab Push Rules (Premium) — custom regex blocking:
# Settings → Repository → Push Rules → Secret files regex

Push protection is your last line of defense. Combine it with pre-commit hooks (Gitleaks) for local prevention and CI scanning (TruffleHog) for comprehensive coverage. A layered approach catches secrets at every stage of the development workflow.