TL;DR: A 2025 cloud security report cited by Orca Security found that 85% of organizations have plaintext secrets embedded in source code repositories, making exposed Git history a durable access path for attackers. Secrets caught before commit or push reduce blast radius, but governance still depends on preventing credential material from reaching shared repositories in the first place.
At a glance
What this is: Orca Security explains how Git hooks can stop plaintext secrets from entering Git history by detecting them before commit or push.
Why it matters: This matters because once secrets land in shared repositories, IAM and NHI teams are often dealing with irreversible exposure paths rather than a simple cleanup task.
By the numbers:
- 85% of organisations have plaintext secrets embedded in source code repositories.
Context
Plaintext secrets in source code repositories are a governance failure, not just a developer mistake. When API keys, tokens, passwords, or certificates reach shared Git history, the access problem shifts from prevention to containment, and containment is materially harder once copies spread across repositories and mirrors.
The issue matters most to NHI governance because secrets often authenticate service accounts, workloads, and automation paths. In that setting, a leaked secret is not just a credential leak. It is a durable identity exposure that can outlast the original commit and defeat any assumption that removal from the working tree removes access.
Git hooks matter because they move detection to the point where change is still reversible. Pre-commit checks on the developer machine and pre-receive checks on the SCM server create two control points before the secret becomes part of shared history. That is the right place to govern the risk.
Key questions
Q: What is the first step when plaintext secrets are found in Git workflows?
A: Stop the secret before it is committed or pushed, because once it reaches shared history, cleanup becomes incomplete and copies may already exist in clones, mirrors, or caches. The first action is to block ingress at the developer machine or SCM server, then rotate the exposed credential and review where it may have replicated.
Q: Why do plaintext secrets in source code create a broader access risk than the repository itself?
A: Because many secrets authenticate systems outside Git, including service accounts, APIs, workloads, and cloud resources. A leaked key is therefore a reusable identity path, not just a code quality issue. The risk expands when the same credential can be used to access other environments, escalate privileges, or move laterally after exposure.
Q: What are the signs that secret detection controls are not working in Git?
A: Repeated secret discoveries after commits, inconsistent enforcement across teams, bypassed local hooks, and secrets still appearing in shared repositories all indicate control failure. If pushes are accepted without server-side checks, the programme is relying on developer discipline rather than enforceable policy, which is not reliable enough for credential material.
Q: How should security teams implement secrets management across distributed environments?
A: Security teams should centralise governance, maintain a complete inventory of secret stores, and map each secret to its workload consumers before changing rotation or access policy. The goal is to make every secret traceable from creation to revocation, including CI/CD, runtime, and vault locations. Without that inventory, policy changes create blind spots instead of control.
Technical breakdown
Why Git history makes secret exposure durable
Git is a distributed version control system, so commits are replicated across local clones, remotes, caches, and sometimes mirrored storage. Once a secret is committed, removing it from the working tree does not remove all copies already propagated through the development chain. History rewriting can help, but it is operationally messy and incomplete when other systems have already cached or mirrored the content. That is why source control exposure behaves like identity persistence, not a one-time mistake. The security problem is not only detection. It is preventing a secret from becoming part of the durable record that other systems treat as authoritative.
Practical implication: block secret material before commit, because post-commit cleanup rarely eliminates every copy.
How pre-commit and pre-receive hooks split enforcement
A pre-commit hook runs on the developer machine before a commit is finalized, so it can stop a secret at the earliest local stage. A pre-receive hook runs on the SCM server before a push is accepted, which gives the organisation a central enforcement point even if local controls are missing or bypassed. Used together, they create layered prevention, with local feedback for developers and server-side policy for governance. This is important because policy written in a handbook does not stop a push. Enforcement has to exist at the point where Git accepts change into shared control.
Practical implication: pair local and server-side hooks so one missed control does not let secrets enter shared repositories.
Why scanning only changed lines is a control design choice
Orca Security describes hooks that scan only the changes being committed or pushed, which reduces developer friction and runtime overhead. That matters because controls that are too slow tend to be bypassed, excluded from installs, or left inconsistent across teams. Fast detection is not just a convenience feature. It is what makes the control enforceable in ordinary engineering workflows. In identity terms, this is the difference between a policy that exists on paper and a policy that can actually be applied at the moment credentials are about to cross from private work into shared infrastructure.
Practical implication: tune secret detection for speed and low friction, or teams will route around it.
Threat narrative
Attacker objective: The attacker wants a reusable credential path that turns source code exposure into broader system access and data compromise.
- Entry occurs when a plaintext secret is introduced into source code, a commit, or a push destined for a shared repository.
- Credential access follows when an attacker extracts the secret from public, breached, mirrored, or cached repository data.
- Escalation happens when the stolen secret is used to access systems, expand privileges, or move into connected environments.
- Impact is the resulting data exposure, system access, or downstream compromise enabled by the reused secret.
Breaches seen in the wild
- 17,000+ Secrets Exposed in Public GitLab Repositories: Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secret exposure is a lifecycle problem, not a scan problem. The article is about preventing secrets from ever entering shared Git history, which is the point where cleanup becomes uncertain and control weakens. Once a secret is propagated into repository clones, mirrors, or caches, the organisation no longer owns the full copy set. Practitioners should treat source control as part of the credential lifecycle, not merely a code review system.
Pre-commit and pre-receive hooks work because they shift governance to the decision point. Secret detection is most effective when it runs before the repository accepts the change, not after a leak is already durable. That aligns with OWASP-NHI principles around secret leakage and long-lived exposure. For NHI programmes, the practical lesson is that prevention at ingress is stronger than remediation after replication.
Plaintext secrets in source code create identity blast radius that is larger than the codebase itself. A leaked API key or token can authenticate workloads, service accounts, or cloud resources outside the repository boundary. That means the governance failure is not just exposure of text, but exposure of authority. Teams need to see source code as an identity-bearing surface, not a neutral asset store.
Layered enforcement is the only realistic model in distributed development. Local developer controls reduce accidental exposure, while SCM-side controls catch bypasses and inconsistent workstation hygiene. That dual model is what makes Git hooks operationally relevant rather than symbolic. The field should stop treating secret prevention as a single control and start treating it as a governed choke point across the full development path.
From our research library:
- 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: Guide to the Secret Sprawl Challenge
What this signals
Credential leakage should be treated as an ingress control problem. Source repositories are not just storage locations. They are control surfaces where secrets can either be stopped early or become durable identity material that survives normal cleanup processes. Teams that still rely on post-commit removal are governing the wrong moment in the lifecycle.
Repository enforcement needs both local and central controls. Pre-commit hooks reduce accidental exposure on the workstation, while pre-receive hooks enforce policy at the SCM boundary. That division matters because one control catches developer mistakes and the other catches bypasses, which is the minimum viable model for distributed engineering teams.
For practitioners
- Implement pre-commit secret detection Run secret scanning on the developer machine before a commit is finalized so plaintext credentials are blocked before they enter local history.
- Enforce pre-receive controls on the SCM server Reject pushes that contain API keys, tokens, passwords, or certificates even when local hooks are absent or bypassed.
- Treat repository cleanup as incomplete remediation Assume a secret may persist in clones, mirrors, cached data, or rewritten history after exposure, and do not rely on deletion alone.
- Align secret detection with developer workflow speed Scan only changed lines where possible so the control stays fast enough to remain in everyday use across all repositories.
Key takeaways
- Plaintext secrets in Git are a lifecycle failure because once they enter shared history, removal is uncertain and replication may already have occurred.
- The article shows why prevention at commit and push time is more dependable than attempting to clean up after exposure has spread across repositories and mirrors.
- Teams should govern secrets at the ingress point, using layered controls that make it difficult for credentials to become durable identity material.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Plaintext secrets in repositories are the core exposure pattern described in the article. |
| NHI-07 — Long-Lived Secrets | Secrets that reach Git history can persist far longer than their intended lifecycle. | |
| Recommendation — Scan source control for exposed secrets and block commits before credentials enter shared history. Reduce secret lifetime by preventing durable repository storage and revoking exposed credentials quickly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential management and rotation are directly implicated when secrets are exposed in source code. |
| Recommendation — Apply IA-5 to govern credential issuance, rotation, and revocation for exposed repository secrets. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secrets in source code can enable account abuse if not governed with account lifecycle controls. |
| Recommendation — Use CIS-5 to inventory, control, and remove accounts and credentials that could be exposed in code. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article centres on attacker extraction and reuse of exposed secrets for credential access. |
| Recommendation — Map exposed repository secrets to TA0006 and prioritise containment of credentials already at risk. | ||
Key terms
- Plaintext Secret: A plaintext secret is a credential, token, or key stored in readable form instead of protected by encryption or a secret manager. In practice, it behaves like a live identity with immediate misuse potential, which is why discovery and rotation must be treated as urgent controls.
- Pre-commit Hook: A pre-commit hook is an automated local check that runs before code is written into git history. It is especially useful for catching secrets, because once a token or key is committed, removal becomes a revocation problem as well as a code cleanup problem.
- Pre-receive Hook: A pre-receive hook is a server-side Git control that evaluates a push before the repository accepts it. It provides centralized enforcement for secret detection and other policies, which helps catch developer bypasses and inconsistent local configurations before code reaches shared history.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
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 June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org