TL;DR: GitGuardian says ggshield now scans repositories, files, archives, Docker images, PyPI packages, CI pipelines, and commit ranges, while also supporting hooks, Honeytokens, and HasMySecretLeaked checks from the terminal. Secrets governance cannot stop at repo scanning when leaked credentials travel through developer workflows and still persist in history.
At a glance
What this is: This is a GitGuardian guide to ggshield’s expanded command set for scanning secrets beyond repositories and into terminal-based developer workflows.
Why it matters: It matters because IAM and NHI teams need controls that catch secrets in files, archives, containers, CI, and commit history before they become standing access paths.
👉 Read GitGuardian's guide to ggshield scanning across the terminal workflow
Context
Developers do not expose secrets only in source repositories. The real governance gap is that credentials can appear in local files, archives, container exports, package artifacts, CI jobs, and commit history before any central review process sees them. That makes the terminal and surrounding workflow part of the identity attack surface, not just the repo.
ggshield is positioned here as a workflow control for finding and handling secrets where developers actually work. The article’s core point is that secrets management has to move left and widen from repository scanning to broader command-line, build, and packaging activity.
Key questions
Q: What breaks when secret scanning only covers public repositories?
A: Repository-scoped scanning misses secrets that leak through forks, issues, comments, build logs, open source contributions, and attacker-controlled exfiltration paths. That creates a false sense of coverage because the credential may already be validated and abused before the platform ever sees public exposure. Effective governance needs scanning plus containment, rotation, and revocation.
Q: Why do exposed machine secrets create more risk than ordinary code leaks?
A: Because a secret is not just data, it is a credential. If the value can still authenticate a workload, repository, or pipeline, the exposure becomes an access path rather than a disclosure event. That is why identity, privilege scope, and revocation are the real controls, not only source-code remediation.
Q: What are the signs that secret controls are not catching workflow exposure?
A: Common signs include secrets found outside repositories, repeated findings in commit history, exposed values in package artifacts, and leak-check hits for credentials that were thought to be removed. Those signals show the control is too late in the lifecycle and is only seeing what survived packaging and sharing.
Q: Should teams prioritise hooks, CI scans, or leaked-secret checks first?
A: Start with the control point where secrets are most likely to enter your workflow, then add the next boundary rather than treating these as interchangeable. Hooks prevent new leakage, CI scans catch what slips through, and leak checks confirm whether exposed credentials have already escaped into public channels.
Technical breakdown
Why repository-only scanning misses the real exposure window
Repository scanning catches one part of the problem, but secrets often enter the workflow earlier and survive later cleanup. A credential can be introduced in a local file, bundled into an archive, embedded in a Docker export, or copied into commit history before it ever lands in a central code review gate. That is why terminal-first scanning changes the control point: it extends detection to the places where developers create and package software, not only where they publish it.
Practical implication: extend scanning to developer workstations, build outputs, and commit ranges instead of treating the repository as the only control boundary.
How hooks, CI scans, and commit-range checks work together
The control model here is layered. Git hooks inspect tracked changes before commit or push, CI scans look at pushed commits inside pipeline execution, and commit-range scans let teams narrow investigation to specific history windows. Each layer covers a different moment in the software lifecycle, which matters because a leaked secret may be introduced locally, propagated through a branch, and only become visible once it enters automated delivery. The useful design pattern is not one scanner everywhere, but the same scanner applied at multiple decision points.
Practical implication: place secret scanning at local, pipeline, and history checkpoints so exposure is caught before it becomes durable.
Why Honeytokens and leaked-secret checks change governance from detection to tripwires
Scanning finds known exposure, but Honeytokens and leaked-secret checks add active monitoring. Honeytokens are decoy credentials that should never be used, so any attempt to validate them becomes a signal of misuse. HasMySecretLeaked extends that idea by checking whether secrets have already appeared publicly. Together, these functions shift secrets management from passive discovery to ongoing verification that credentials are not merely stored safely but are also unused, unexposed, and monitored for abuse.
Practical implication: combine exposure scanning with decoy credentials and leak verification so secret handling includes both prevention and early warning.
Threat narrative
Attacker objective: The attacker wants durable access through exposed secrets that survive ordinary code cleanup and remain usable across build and distribution paths.
- Entry occurs when developers place API keys, passwords, or tokens into files, repositories, archives, containers, or package artifacts that are later shared or committed. Credential exposure then persists in commit history, exported images, or packaged dependencies even after the original file is edited. Detection fails when teams only scan the repo and ignore the surrounding terminal workflow, leaving the secret available to reuse. Impact follows when those leaked credentials are validated, reused, or quietly accessed at scale.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets governance has outgrown repository scanning: The article shows that the practical exposure surface now includes the terminal, local files, archives, containers, package artifacts, and CI-triggered history. That means the control problem is not just secret detection but secret containment across the developer workflow. Teams that still anchor governance to the repo alone are managing the wrong boundary.
Terminal-first scanning is a workflow control, not a point tool: ggshield is useful here because it matches how developers actually create and move secrets. The article’s real lesson is that prevention has to sit at the same place as creation, packaging, and delivery if it is going to catch credentials before they harden into history. Practitioners should think in terms of control placement, not tool count.
Honeytokens redefine secrets management as active deception: Decoy credentials turn a static leakage problem into a monitored abuse problem. That matters because identity teams need to know not only whether a secret exists, but whether it has been touched in the wild. The practical conclusion is that secrets governance now includes tripwires, not just vaults and scanners.
Identity blast radius starts before production: A secret exposed in a local terminal session or package artifact can create a longer-lived access path than a typical application bug because the credential itself becomes the attack surface. This shifts the governance question from where a secret was stored to where it can still be reused. Practitioners should treat every developer handoff as a potential privilege extension point.
Leaked-secret monitoring closes the gap between discovery and misuse: The article’s HasMySecretLeaked workflow points to a broader governance reality: finding a secret in your own environment is only half the job if it has already been copied elsewhere. The discipline now has to account for public exposure, validation attempts, and reuse across environments. Teams should align monitoring to the full secret lifecycle, not just the internal vault.
From our research library:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Secrets Management Buyer's Guide
What this signals
Identity blast radius starts at the terminal: Once a secret is typed, copied, or packaged in a developer workflow, the exposure path is no longer limited to source control. Teams need controls that inspect files, archives, containers, and commit history before those artefacts become reusable credentials.
Hardcoded secret discovery now has to be lifecycle-aware: A scan that only watches repositories will miss the earlier stages where secrets are introduced and the later stages where they are redistributed. The governance problem is not detection alone, but whether detection is placed where the credential can still be stopped.
Workflow guardrails belong beside developer tooling: Pre-commit and pre-push controls, CI scans, and leak verification work best when they operate as a single policy chain. The programme implication is to treat secret scanning as part of development flow design, not a separate security afterthought.
For practitioners
- Extend scanning beyond repositories Run secret checks across local files, directories, archives, Docker exports, package artifacts, and commit ranges so the workflow, not just the repo, is covered.
- Place hooks at commit and push boundaries Use pre-commit and pre-push checks to stop tracked changes that introduce API keys, passwords, or tokens before they become durable history.
- Use CI scans as a second control point Scan pushed commits in build pipelines so secrets introduced after local checks are still caught before release artifacts are produced.
- Add Honeytokens for exposed credential paths Create decoy secrets in locations an attacker might realistically touch, then monitor any validation attempt as a sign of misuse.
- Check public leakage with leaked-secret fingerprints Compare discovered secrets against public exposure checks so teams can confirm whether credentials have already appeared outside the organisation.
Key takeaways
- Secrets exposure is no longer confined to repositories because credentials can leak through the full terminal workflow, packaging steps, and commit history.
- The article frames ggshield as a way to extend detection into developer activity, with hooks, CI checks, and leak verification covering different points in the lifecycle.
- Teams that still rely on repo scanning alone leave a governance gap that lets reusable credentials survive long enough to become an access problem.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets leaking through developer workflows and persisted artifacts. |
| NHI-07 — Long-Lived Secrets | Commit history and packaged artifacts keep leaked credentials usable after the initial exposure. | |
| Recommendation — Scan developer workflows for exposed secrets and revoke any credential found in code, archives, or logs. Reduce credential lifetime so secrets do not remain valid after exposure in source or build artefacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article deals with managing and invalidating credentials across their lifecycle. |
| Recommendation — Apply IA-5 to manage credential issuance, rotation, and revocation across developer workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Leaked secrets become access permissions that must be governed across the environment. |
| Recommendation — Review entitlement paths for exposed secrets and remove any unnecessary access immediately. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is credential exposure and reuse through leaked secrets. |
| Recommendation — Map exposed secrets to TA0006 and prioritise detection where credentials are most likely to be captured. | ||
Key terms
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Honeytoken: A honeytoken is a deliberately planted secret or credential designed to be detected when used. It helps security teams spot misuse early, especially in environments where machine identities and automation can move faster than manual investigation or containment.
- Commit-Range Scanning: Commit-range scanning inspects a chosen slice of Git history instead of the entire repository. It is useful when teams need to focus on a suspected window of exposure, but it still depends on downstream response because a secret found in history can already be valid elsewhere.
- Terminal Workflow: The terminal workflow is the collection of developer actions carried out through CLI tools, scripts, package handling, and local file operations. It matters because secrets often enter the environment before they ever reach a repository, build, or review control.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- Exact ggshield command examples for repo, path, archive, Docker, PyPI, and commit-range scans
- CLI syntax, authentication flow, and configuration order for practical setup
- Pre-commit, pre-push, and pre-receive hook installation details for developer workflows
- HasMySecretLeaked usage patterns, fingerprinting flow, and Honeytoken creation commands
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org