Topic starter
11/12/2025 10:36 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “How To Use ggshield To Avoid Hardcoded Secrets [cheat sheet included]”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Secrets exposure is no longer confined to repositories because credentials can leak through the full terminal workflow, packaging steps, and commit history.
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
👉 Read GitGuardian's guide to ggshield scanning across the terminal workflow →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/10/2026 6:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ggshield expands secrets scanning from repos to the full terminal workflow