Why do Git-based secrets create lasting NHI risk?

Why This Matters for Security Teams

Git-based secrets are not just a hygiene problem; they are an identity problem. Once a token, API key, or certificate lands in commit history, it can be copied into forks, caches, mirrors, developer clones, CI logs, and incident archives. That creates a durable attack surface for the underlying NHI, even if the original file is deleted. NHIMG research shows that 44% of NHI tokens are exposed in the wild, often through code commits and collaboration tools, which matches what teams see during post-incident reviews in the Top 10 NHI Issues analysis.

The risk persists because many secrets authenticate a workload, service account, or automation path rather than a person. If that NHI is overprivileged, shared across apps, or tied to long-lived credentials, the exposure becomes reusable far beyond the original repository. This is why guidance in the OWASP Non-Human Identity Top 10 treats secret lifecycle failure as a primary control gap, not an edge case. In practice, many security teams encounter the breach only after the token has already been harvested from history and replayed elsewhere, rather than through intentional discovery.

How It Works in Practice

Git makes history immutable by default, so removal from the latest branch tip does not remove the secret from every place it has propagated. That is why rotation, not deletion, is the real remediation. The exposed value must be revoked, reissued, and traced across downstream systems that may have cached it. The operational question is whether the NHI behind the secret can be isolated quickly enough to stop replay. NHIMG case studies such as the CI/CD pipeline exploitation case study show how quickly a single leaked credential can become a broader pipeline compromise.

A practical response usually combines inventory, detection, and time-bounded credentialing:

• Find secrets in commit history, pull requests, issue threads, and build artefacts, then treat each finding as an NHI exposure event.
• Rotate the credential at the source, because removing the Git object alone does not invalidate the token.
• Reduce standing privilege so the secret cannot operate outside its narrow task scope.
• Use short-lived credentials where possible, because expiry limits the value of a harvested secret.

That approach aligns with NIST Cybersecurity Framework 2.0, especially identification, protection, and recovery activities, and it is reinforced by the 52 NHI Breaches Analysis, which shows how identity compromise often outlives the initial disclosure. Current guidance also favours secret scanning in CI/CD, but there is no universal standard for how quickly every downstream replica can be purged. These controls tend to break down when secrets are copied into unmanaged developer machines and third-party SaaS integrations, because the organisation cannot reliably find every replica.

Common Variations and Edge Cases

Tighter secret controls often increase engineering overhead, requiring organisations to balance developer speed against revocation certainty. That tradeoff becomes sharper in legacy systems, vendor integrations, and release pipelines that still expect static credentials. In those environments, rotation can cause outages if the workload identity model is weak or undocumented. Best practice is evolving toward workload identity and JIT issuance, but there is no universal standard for a clean cutover in every stack.

The hardest edge cases involve secrets that are shared across multiple applications, embedded in build tooling, or stored in places that Git does not control directly. In those scenarios, a Git leak is only the first copy. The actual risk comes from the credential’s reach, not the repository alone. The Shai Hulud npm malware campaign illustrates how repository exposure can feed later supply chain abuse, while the Reviewdog GitHub Action supply chain attack shows that automation can multiply exposure faster than teams can revoke it.

NIST guidance on resilience and the OWASP NHI model both point to the same operational conclusion: treat every committed secret as a potentially durable identity compromise, then design for rapid revocation, narrow scope, and short lifetime. For organisations with mature controls, the next step is not just better scanning, but less reliance on static secrets in the first place.

Related resources from NHI Mgmt Group

• Why do developer workstations create NHI risk as well as human identity risk?
• Why do non-human identities create more risk than many human accounts?
• Why do secrets create disproportionate risk in NHI environments?
• Why do non-human identities create more remediation risk than many human accounts?