What breaks when Git tokens and hard-coded secrets are left in source control?

Why This Matters for Security Teams

When Git tokens and hard-coded secrets land in source control, the repository stops being a collaboration system and becomes an identity distribution channel. Attackers do not need to break in if the codebase already contains reusable access. That risk is amplified because source control is often replicated into CI, mirrors, forks, backups, and developer laptops, extending exposure far beyond the original commit. The OWASP Non-Human Identity Top 10 treats exposed machine credentials as a first-class identity problem, not just a hygiene issue.

NHI Management Group has documented how secrets sprawl turns ordinary development workflows into security debt, especially when teams assume private repositories are inherently safe. The Guide to the Secret Sprawl Challenge shows that secrets routinely escape into tickets, docs, and commits, while the Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why static credentials are especially dangerous once they are duplicated across environments.

In practice, many security teams discover the exposure only after a token is already being used to enumerate cloud services, access SaaS data, or plant additional persistence.

How It Works in Practice

A leaked Git token or embedded API key usually fails in stages, not all at once. First, the secret is discovered through a commit history scan, dependency compromise, branch leak, or developer paste. Next, it is replayed against the target service. If the token is overprivileged, long-lived, or shared across workloads, the attacker can pivot from one repository into cloud consoles, package registries, CI/CD systems, or collaboration tools. The main failure is lifecycle control: the organisation has no reliable way to know where the credential exists, who can use it, or when it should stop working.

Operationally, the right response is to treat secrets as short-lived identity artefacts rather than static configuration. That means secret scanning in pre-commit hooks and server-side checks, automated revocation on detection, scoped permissions, and rotation tied to deployment events. For machine access, prefer workload identity and ephemeral credentials over copied tokens. Current guidance suggests using policy-backed controls so that access is not just issued, but continuously constrained by context and purpose.

• Scan source, pull requests, build logs, and issue trackers for exposed secrets.
• Revoke and rotate immediately when a token is found, even if exposure seems limited.
• Replace shared static tokens with per-workload identity and short TTL credentials.
• Separate human developer access from service-to-service access paths.
• Track where a secret has been copied, not just where it was first created.

GitGuardian’s 2026 research shows that secrets sprawl is now systemic, with 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone. The same research also shows that 64% of valid secrets leaked in 2022 are still valid today, which makes revocation and inventory accuracy as important as detection. These controls tend to break down when organisations rely on long-lived tokens inside CI/CD runners and then assume repository access controls will contain the blast radius.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance developer speed against revocation discipline and access traceability. That tradeoff becomes more visible in fast-moving delivery pipelines, legacy applications, and third-party integrations that cannot easily adopt workload identity.

One common edge case is the “private repo is safe” assumption. Internal repositories are often more exposed than teams expect because they are cloned, mirrored, and shared across automation. Another is offboarding: if a former employee’s token remains active, the repository leak may simply accelerate an already open access path. NHI Management Group’s research on CI/CD pipeline exploitation case study shows how build systems can become the preferred pivot point once a secret is available.

There is no universal standard for every remediation workflow yet, but best practice is evolving toward automated discovery, immediate revocation, and replacement with ephemeral credentials. For teams dealing with token reuse across SaaS platforms, the Salesloft OAuth token breach illustrates how a single exposed identity artefact can turn into broad downstream access. The hardest cases are monorepos, shared service accounts, and legacy integrations where one leaked secret can still authenticate many unrelated systems.

Related resources from NHI Mgmt Group

• What is the impact of using hard-coded credentials on security?
• What breaks when access control is still hard-coded after product-market fit?
• What breaks when DNS resolvers are open to recursion from any source?
• What breaks when NHI credentials are long-lived and hard to monitor?