We Planted 5 Secrets in a Git Repo. SecurityClaw Found 4.

What We Tested

We created a private GitHub repository that mimics a realistic developer workflow: three commits, three files, five intentionally planted secrets. The kind of repo that looks completely normal until you grep the history.

The secrets we planted span the most common real-world leak categories:

• config.py — AWS Access Key ID (AKIAIOSFODNN7EXAMPLE) and the corresponding AWS Secret Access Key (high-entropy string)
• deploy.sh — GitHub Personal Access Token (ghp_...) and a Slack Webhook URL
• payment.js — Stripe live secret key (sk_live_...)

Why these five? Because AWS keys, GitHub tokens, Slack webhooks, and Stripe keys are the secrets that actually get leaked in production incidents. They're the ones that show up in breach reports. We wanted to test against realistic data, not contrived examples.

The git history includes three commits: an initial config, a deploy script addition, and a payment integration. The secrets aren't just in the working tree — they're baked into commit history. Deleting the file wouldn't remove them.

How SecurityClaw Ran the Campaign

We ran TruffleHog as a SecurityClaw campaign — not a one-off terminal command. The campaign system targets the repo, runs TruffleHog across the full git history, captures structured output, and records the result against the campaign for tracking.

The scan covers every commit in the repo's history, not just the current working tree. That's the correct behaviour: secrets deleted from the latest commit still live in the history, and any developer who has cloned the repo at any point has a copy.

Campaign configuration: default TruffleHog v2 ruleset, full history scan, JSON output format. No custom rules added — this is the out-of-the-box SecurityClaw experience.

What It Found

Scan time: 91 milliseconds. Four findings, zero false positives.

The results against each planted secret:

AWS keys: found by both pattern match (the AKIA prefix is a known AWS signature) and entropy scoring. The GitHub PAT hit on entropy — the token format changed in 2021 to a high-entropy 40-character string that's hard to miss. Slack webhook: direct URL pattern match.

What It Missed — and Why

The Stripe live key (sk_live_...) produced no output. Payment.js returned nothing.

This is a known, documented gap in TruffleHog v2. The Python-based v2 release uses a fixed regex ruleset. Stripe's sk_live_ and sk_test_ patterns are not in that ruleset. This isn't an edge case — Stripe is one of the most widely deployed payment processors in the world, and its live keys are exactly the type of secret that causes expensive incidents when leaked.

TruffleHog v3 (the Go-based rewrite, released in 2023) addressed this. V3 includes per-detector verification — it doesn't just pattern-match, it attempts to validate the secret against the actual API. Stripe detection with liveness checking is included in v3.

Why are we running v2? Because the SecurityClaw Python package integration currently wraps v2. This is a known gap that we're tracking explicitly. It's logged. The fix — upgrading to v3 — is in the pipeline.

The honest takeaway: if your repo contains Stripe keys and you ran this campaign today, SecurityClaw would not catch them. We'd rather you know that now than discover it after an incident.

SecurityClaw AI Layer — Gap Analysis

SecurityClaw's AI orchestration layer reviewed the campaign output and flagged the coverage gap independently. Given the repo contained a payment integration file (payment.js), the AI noted that payment processor credentials — specifically Stripe live keys — are a high-probability target in this context and that the current ruleset does not cover them.

The AI's recommendation: add a custom TruffleHog rule targeting sk_live_[a-zA-Z0-9]{24,} as a temporary mitigation until the v3 upgrade is complete. This is the kind of gap-fill the AI layer is designed for: where tooling has a known limitation, intelligent orchestration can compensate at the config level.

We haven't deployed that custom rule yet — this is Demo #1, and we're documenting the baseline behaviour, not the compensated result. The next campaign run will include the custom rule, and we'll document the delta.

What This Means in Practice

91 milliseconds to scan a full git history for secrets. That's fast enough to run on every push in a CI/CD pipeline with no meaningful latency impact. The speed argument for not scanning your repos doesn't hold up.

The 80% detection rate on this controlled test is not a ceiling — it's a starting point that reflects the current tooling state honestly. The gap is specific and fixable. The four detections it did catch (AWS keys, GitHub token, Slack webhook) represent the most common real-world leak patterns in public breach data.

The broader principle: automated scanning is necessary but not sufficient. TruffleHog will find the patterns it knows about with high reliability and zero noise. It will not find secrets it doesn't have rules for. Security-conscious development teams need to know both sides of that equation.

If you're building out a secrets management practice from scratch, The Web Application Hacker's Handbook covers the credential and secrets attack surface in depth — still the most practical reference on how attackers find and exploit exposed credentials in web application contexts.

Known Gaps + What's Next

• TruffleHog v3 upgrade — planned. Adds Stripe detection, per-detector liveness verification, and a significantly expanded ruleset. Will re-run this exact campaign and document the delta.
• Custom rule deployment — temporary Stripe regex mitigation being evaluated. Will document when deployed.
• Next demo — Web vulnerability scanning (Nuclei against a controlled DVWA-style target). Coming soon.

Run It on Your Repo

If you want to run a secrets detection campaign against your own repositories — or test SecurityClaw's full capabilities across the kill chain — see what we're building:

Learn about SecurityClaw →

SecurityClaw is in active development. The demos section documents real campaign results as the platform matures.