Hey everyone! 👋 I've been diving deep into secret scanning tools lately, and I've hit a recurring snag with GitHub's built-in secret scanning for private repositories. Don't get me wrong, it's fantastic for catching those well-known public service tokens (like Slack bots, AWS keys, etc.) before they hit the public timeline. But in our private enterprise repos, we keep finding that a lot of internal, proprietary, or just less-common secrets slip right through the net.
For example, we have:
* Internal API keys for our own microservices (like `COMPANY_API_SECRET_v2=`)
* Database connection strings for staging environments
* Encryption keys for our internal tooling
* Configuration for legacy systems that use non-standard formats
GitHub's pattern-matching is understandably focused on the big, public SaaS providers. So I've been on the hunt for tools that give us more control and a wider net. I've tested a few, and each has a different strength.
Here’s a breakdown of the alternatives I've been working with, focusing on their "catch" capabilities:
**1. GitGuardian**
This one is a powerhouse for breadth. You can define custom detectors using regex, which is exactly what we needed for those internal secrets.
* **Pro:** The custom detector setup is very flexible. You can scan for specific variable names, partial hashes, or even specific file formats.
* **Con:** It's a separate SaaS service, so you need to integrate it into your CI/CD pipeline. Pricing scales with seats and repos.
* **Sample config snippet for a custom detector (conceptual):**
```yaml
# Example of a custom pattern for an internal key
patterns:
- name: "Internal Service Token"
regex: '(?:INTERNAL_SVC|ISEC)_KEY[=s]["']?([a-fA-F0-9]{64})["']?'
severity: high
```
**2. TruffleHog / Gitleaks (Open Source)**
These are CLI tools you run in your pipeline. The huge advantage is you can define a vast array of custom rules in a TOML or JSON config file.
* **Pro:** Incredibly granular control. You can scan for entropy (random strings), specific file paths, and commit histories. Gitleaks' rule set is very easy to extend.
* **Con:** You own the pipeline integration and the secret management for the findings. It adds maintenance overhead.
* **Gotcha:** Running these in CI requires careful setup to avoid the tool itself exposing secrets in logs. Always use `--redact` or similar flags!
**3. StepSecurity's Harden-Runner / GitHub Actions OIDC**
This is a slightly different, preventative approach. Instead of just *finding* secrets, it focuses on stopping them from being used in the first place.
* **Pro:** Uses GitHub's OpenID Connect (OIDC) to generate short-lived, dynamic credentials for your cloud providers. This drastically reduces the need for long-lived secrets in code.
* **Con:** It's more about eliminating the risk vector than scanning for existing leaks. You'll likely still need a scanner for legacy code and other secret types.
My current "recipe" for a robust setup is a layered defense:
1. Use **GitHub's native scanning** as the first, fast, free layer.
2. Run **Gitleaks in CI** with a custom rule set for our internal patterns.
3. For our most critical repos, we also have a **GitGuardian monitor** running as a second opinion.
4. We're gradually migrating cloud workflows to use **OIDC** wherever possible.
Has anyone else set up a similar multi-tool pipeline? I'm especially curious about how you handle the alert fatigue from multiple scanners and how you've tuned custom regex rules to avoid false positives. Share your war stories and config snippets!
-- Ian
Integration Ian
I'm a cloud security lead at a fintech of about 300 people. We run AWS, GitHub Enterprise, and a sprawling microservices stack. We replaced GitHub's native scanning over a year ago to catch our internal secrets.
Here's the breakdown from running two of these in production and evaluating a third:
1. **Custom Detector Control**: GitGuardian lets you write regex and simple validation rules (like checksums). TruffleHog uses entropy and regex. Gitleaks is regex-only. For your `COMPANY_API_SECRET_v2`, you need strong regex support; GitGuardian's UI for this is easier, but Gitleaks' regex is just as powerful if your team codes.
2. **Deployment & Operational Load**: Gitleaks is a single binary. You run it in CI, period. It's zero management but adds zero central visibility unless you build it. GitGuardian is a SaaS dashboard with a sidecar scanner. Setup took my team a week to tune and integrate across all pipelines. Ongoing, it's maybe 2-3 hours a week for triage.
3. **Price & Target**: Gitleaks is free (OSS). GitGuardian starts around $4-7 per developer per month for teams our size, but you need the "Internal Secrets" add-on for full custom regex, which bumps it. TruffleHog's open source version is free; their paid platform is enterprise-priced (you have to contact sales). Gitleaks wins for pure budget, GitGuardian for mid-market with a compliance team.
4. **Where They Break**: Gitleaks gives you raw output; you must pipe it to a SIEM and build alerting yourself. GitGuardian can flood you with false positives on binary files or minified JS if you don't exclude paths properly. TruffleHog's entropy scanning, while powerful, can flag high-entropy strings that are just random data, not secrets, requiring fine-tuning.
My pick is **GitGuardian** for your listed use case, because your examples (internal API keys, non-standard configs) need the custom regex managed in a central place with audit trails for compliance. If budget is tight and you have engineering cycles to build the alerting pipeline, **Gitleaks** paired with a good CI/CD policy is brutally effective.
Tell me your team size and whether you need a dashboard for auditors, and I'll tighten that recommendation.
Trust but verify