API keys, tokens, private keys and connection strings keep leaking into code, builds and collaboration tools, and every one of them lets an attacker authenticate as a non-human identity. OWASP lists this as NHI2:2025 Secret Leakage in its Non-Human Identities Top 10, naming source repositories, logs, developer endpoints, scripts, chat tools and SaaS platforms as places where secrets end up. Secrets scanning tools find those credentials, ideally before they are pushed, and help teams prove whether they are still live. This vendor-neutral buyer's guide helps security, platform and AppSec teams define requirements, compare capabilities and run a proof of concept. It does not rank vendors; how to store secrets properly is covered in the Secrets Management Guide.
Key takeaways
- Prevention beats detection. Push protection and pre-commit checks stop a secret before it enters history; everything found later needs rotation.
- Coverage is wider than Git. Container images, CI logs, tickets, wikis, chat and app binaries all hold secrets, so weigh the sources a tool can scan as heavily as its detection rules.
- Validity checking drives triage. Knowing whether a key is still live, and what it can reach, is what turns thousands of findings into a short queue.
- Remediation is an identity task. A finding is closed when the credential is revoked and replaced, not when the line is deleted. The tool must route each finding to an owner.
- Test on your own data. Detection quality varies by secret type and by how your organisation formats internal tokens, so a proof of concept on real repositories is the only reliable comparison.
Define requirements
- Sources: which source control platforms (cloud and self-hosted), CI/CD systems, container registries, artefact stores, ticketing, wiki and chat tools hold code or configuration today?
- Scope of history: do you need a one-off scan of full Git history across all branches, continuous scanning of new commits, or both? The Secret Sprawl Measurement Guide explains how to baseline what you already have.
- Prevention points: where should a secret be blocked: developer workstation (pre-commit or IDE), server-side push, pull request check, or pipeline gate?
- Secret types: public cloud keys, SaaS and AI provider API keys, database connection strings, private keys and certificates, and your own internal token formats that will need custom rules.
- Response model: who receives a finding, how it is tied to an owner, and whether your secrets manager or provider can rotate it automatically. See the Leaked Credential Response Playbook.
- Deployment and data handling: SaaS or self-hosted, where scanned content and matched secrets are stored, whether raw secret values are retained, and data residency requirements.
- Native features already licensed: source control platforms include secret scanning. GitHub secret scanning runs automatically on public repositories and needs GitHub Secret Protection for private organisation repositories; GitLab secret detection is offered on all tiers. Decide what a separate tool must add.
Capability areas
| Area | What to look for |
|---|---|
| Push and commit prevention | Server-side push protection and pre-commit hooks that block before history is written; clear developer message; bypass reasons recorded and alerted. GitHub's push protection, for example, records a reason (used in tests, false positive, fix later) and creates an alert and audit log entry for each bypass |
| Historical scanning | Full history across all branches, deleted branches where available, forks and archived repositories, with incremental rescans when new detectors are added |
| Non-code sources | Issues, pull request comments, wikis, discussions, CI logs, container image layers, package artefacts, chat and document stores, and mobile app binaries |
| Detection methods | Provider-specific patterns, generic patterns (private keys, connection strings, passwords), entropy and AI-assisted detection for unstructured secrets, and custom regular expressions for internal formats |
| Validity checks | Safe, read-only verification that a secret is active, with clear rules on when the tool contacts the issuing provider |
| Context and impact | Which account, project and permissions the key belongs to, first and last seen, every location it appears, and whether it is in a public place |
| Ownership and routing | Mapping findings to committers, repository owners and the NHI owner, with ticketing and chat integration |
| Remediation | Provider revocation partnerships, integration with secrets managers for rotation, and tracking until the credential is confirmed revoked |
| Public exposure monitoring | Monitoring public code hosts, package registries and paste sites for your organisation's secrets and domains |
| Reporting and APIs | Finding APIs, SIEM export, metrics by team and secret type, audit evidence for bypasses |
Evaluation criteria
| Criterion | How to test it | Why it matters |
|---|---|---|
| True positive rate on your secret types | Seed test repositories with known, revoked secrets of every type you use, including internal formats | Missed types become silent gaps |
| False positive rate | Scan a real repository set and have engineers label a sample of 100 findings | High noise causes developers to bypass push protection |
| Validity check accuracy | Compare tool verdicts against seeded live and revoked test keys | Triage depends on knowing which findings are live |
| Time to detect | Push a seeded secret and time the alert across each source | Exposed keys on public hosts can be harvested very quickly |
| Scan performance | Full history scan time for your largest repository; pre-commit latency on a developer laptop | Slow hooks get disabled |
| Developer experience | Message clarity, local reproducibility, how to mark a test secret | Determines adoption |
| Data protection | Where matched values are stored, masking in the UI, access control on findings | The findings database is itself a store of live credentials |
| Coverage outside Git | Scan a container image, a CI log and a ticket with seeded secrets | Many leaks never touch a repository |
The Docker Hub secrets leak shows why the last row matters: Flare reported 10,456 public images in one month exposing keys, many in .env files and Dockerfiles copied into image layers, and found that most credentials were not revoked even when developers removed them.
Where identity fits
Every finding is a non-human credential with a scope, an owner (or none) and a lifetime. Scanning measures leakage; it does not shorten that lifetime. Pair the tool with short-lived credentials such as workload identity federation and vault-issued dynamic secrets, which the OWASP NHI2 entry recommends alongside automated detection. A key that expires in an hour is far less dangerous when it leaks. See the Top 10 NHI Risks and the API Key Management Guide. The Toyota T-Connect key exposure is the long-lifetime case: a data server access key sat in a public GitHub repository from December 2017 until September 2022 before anyone noticed.
Questions to ask vendors
- Which sources can you scan today, natively, and which need custom integration? Show a container image and a CI log scan.
- How do you detect secrets with no fixed format, such as passwords in configuration files, and what is the false positive rate you measure for that detector?
- How do you write and test custom detectors for our internal token formats, and can they apply at push time as well as in scans?
- When you run a validity check, exactly what request is sent to the provider, from where, and can it be disabled per secret type?
- Do you store the raw secret value? If so, where, how is it encrypted, and who at your company can see it?
- How does a finding get to the person who can rotate it, and how do you confirm the credential was actually revoked?
- What does a developer see when a push is blocked, and how are bypasses approved, logged and reviewed?
- How do findings deduplicate when the same key appears in many repositories, forks and images?
- Which provider revocation or notification partnerships do you have, and what happens for providers without one?
Red flags
- A finding marked "resolved" when the file is edited, with no check that the key was revoked.
- Coverage claims quoted as a number of detectors with no measured precision or recall on your data.
- Validity checks that call provider APIs with write or billable actions, or that cannot be switched off.
- Raw secrets stored in clear text in the vendor's findings database or shown unmasked to every user.
- Pre-commit scanning only, with no server-side control, so any developer can skip it.
- No answer for secrets outside Git: images, logs, tickets and chat.
- Advice to rewrite Git history as the primary fix. GitHub and the OWASP Secrets Management Cheat Sheet both treat revocation and rotation as the priority, with history rewriting secondary.
Proof of concept
- Create a seeded test set: revoked and live test keys for each provider you use, internal token formats, private keys and passwords, placed in code, history, a container image, a CI log and a ticket. Use agreed test secrets, as the OWASP cheat sheet recommends, so they can be allowlisted later.
- Run a full history scan on a representative sample of real repositories, including your largest, and record scan time.
- Have engineers label a sample of findings to measure false positive rate by detector.
- Enable push protection in audit mode for one team for two weeks, then in blocking mode; measure blocks, bypasses and developer feedback.
- Test validity checks against the seeded live and revoked keys and review what the tool sent to each provider.
- Run one finding end to end: alert, owner routing, rotation through your secrets manager, confirmation of revocation, closure.
- Check the exit path: export all findings and configuration, and confirm how stored secret values are deleted.
Roll out by enabling historical scanning first, then push protection in audit mode, then blocking for high-confidence detectors only, widening as false positive rates are known. Track live secrets found per month, mean time to revoke, push protection bypass rate and the share of findings with a named owner. For CI-specific controls see the CI/CD Pipeline Identity Security Guide.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for secrets scanning, secrets management and NHI security programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Git Secret Scanning Guide · Secrets Management Buyer's Guide · Application Security Testing Buyer's Guide · Infrastructure as Code Security Guide