Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
Expanded Definition
Secrets scanning is the automated discovery of exposed credentials across code repositories, build systems, chat tools, ticketing platforms, and cloud artifacts. In NHI security, it sits alongside secret hygiene, vault governance, and incident response, but it is not the same as prevention. Prevention tries to keep secrets out of risky places; scanning finds them after they land there.
Usage in the industry is still evolving because definitions vary across vendors. Some tools focus on pattern matching in source code, while others extend into container images, CI/CD logs, infrastructure templates, and collaboration platforms. The operational standard is less about where scanning runs and more about whether it reliably detects reusable credentials before attackers do. The OWASP Non-Human Identity Top 10 treats exposed secrets as a core NHI risk because leaked tokens often become the fastest path to privilege escalation.
For a broader view of how exposure accumulates, the Guide to the Secret Sprawl Challenge shows how quickly secrets spread beyond repositories into everyday collaboration and deployment workflows. The most common misapplication is treating secrets scanning as a one-time compliance check, which occurs when teams enable a tool without ownership, revocation, or developer feedback loops.
Examples and Use Cases
Implementing secrets scanning rigorously often introduces alert volume and remediation overhead, requiring organisations to weigh faster detection against developer friction and false positives.
- Scanning pre-commit hooks and pull requests to catch API keys before they reach a shared branch, then blocking merges until the secret is revoked or rotated.
- Running repository-wide scans on historical commits to find credentials embedded months earlier, a pattern frequently seen in supply-chain incidents such as the Reviewdog GitHub Action supply chain attack.
- Inspecting CI/CD logs and runner environments, where leaked variables can be as damaging as hardcoded files; this is especially relevant in the CI/CD pipeline exploitation case study.
- Extending scans into issue trackers and documentation so exposed tokens in Jira, Confluence, or chat exports are found before they are copied into automation scripts.
- Pairing detection with rotation workflows, because scanning alone does not neutralise an already valid NHI token or cloud key.
GitGuardian reports that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, underscoring why scanning must be continuous rather than periodic. In high-maturity programs, findings from scanning also inform secret classification rules and developer training, not just security tickets.
In practice, the strongest implementations combine Shai Hulud npm malware campaign lessons with policy enforcement at the pipeline edge, while aligning secret handling to the OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Secrets scanning matters because exposed credentials are often the first operational weakness an attacker can use to impersonate an NHI, bypass PAM controls, or pivot into cloud and CI/CD systems. A leaked token is rarely just a disclosure problem; it is usually an access problem with a short path to blast-radius expansion. Once secrets appear in code, chat, or build logs, defenders need visibility, revocation, and lifecycle control, not just detection.
NHIMG research shows that 44% of NHI tokens are exposed in the wild, while 91% of former employee tokens remain active after offboarding. That combination makes scanning a governance control as much as a technical one. It also explains why teams must look beyond source code into the places where credentials are casually shared, duplicated, and forgotten. The 52 NHI Breaches Analysis and the Ultimate Guide to NHIs - Static vs Dynamic Secrets reinforce the same pattern: static secrets persist, and exposed secrets remain exploitable long after discovery.
Organisations typically encounter the operational impact only after a token replay, cloud compromise, or pipeline takeover, at which point secrets scanning becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret handling and exposed NHI credentials as a primary risk. |
| NIST CSF 2.0 | PR.DS | Maps to data security protections for secrets stored or transmitted in systems. |
| NIST Zero Trust (SP 800-207) | null | Zero trust assumes credentials can be exposed and requires continuous verification. |
Classify secrets as sensitive data and enforce detection, protection, and recovery workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org