Git token leakage shows why DevOps secrets security still fails

At a glance

What this is: This article explains how a single leaked Git token can expose multi-cloud environments by turning source code into a credential distribution channel.

Why it matters: It matters because IAM, NHI, and DevOps teams still treat repository secrets, token lifecycle, and runtime access as separate problems when attackers move across them as one chain.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Unosecur's analysis of how one leaked Git token can expose multi-cloud security

Context

A leaked Git token is a non-human identity problem because the credential, not the person, is what unlocks source control, cloud access, and downstream SaaS systems. In this pattern, version control becomes an identity distribution layer, and a single exposed token can bridge development, build, and production boundaries without triggering the controls most programmes rely on.

The governance gap is not simply secret sprawl. It is the absence of ownership, lifecycle enforcement, and detection across the places secrets actually live: commits, config files, history, and cloned repositories. Once a long-lived token lands in code, the access path can outlive the developer, the repo change, and sometimes the vendor relationship itself.

Key questions

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

A: Source control becomes an access path instead of a safe delivery system. A single leaked token can unlock private repositories, reveal additional credentials in code, and give attackers a repeatable way into cloud and SaaS services. The failure is not just exposure. It is the absence of lifecycle control and detection around identity-bearing artefacts.

Q: Why do long-lived repository tokens create so much identity risk?

A: They create standing privilege outside ordinary human login controls. Because PATs often bypass MFA and remain valid until revoked, they can be reused long after the original change is forgotten. That persistence makes them difficult to govern with traditional joiner-mover-leaver processes alone.

Q: How do teams know whether secret scanning is actually working?

A: They should see secrets detected in both live code and historical commits, owners assigned to each finding, and revocation completed before the credential is reused. If a token can remain active after exposure or the same secret reappears in multiple repositories, the control is not effective.

Q: Who is accountable when a leaked Git token leads to cloud data exposure?

A: Accountability should sit with the team that owns the credential lifecycle, not only with the developer who committed it. That includes engineering, IAM, and security operations, because the breach crosses code, identity, and cloud control planes. OWASP NHI Top 10 and NIST Zero Trust Architecture both reinforce that shared governance model.

Technical breakdown

How Git token exposure becomes a multi-cloud access path

A Git personal access token is an identity artefact with whatever scopes were granted at creation time. If that token is exposed in a public .git/config file or hard-coded in a repository, an attacker can use it to authenticate to Git hosting, clone private repos, and extract embedded cloud keys. The important detail is that Git history preserves secrets long after the original commit, so deletion in the current branch does not erase the earlier exposure. This is why source control must be treated as part of the identity surface, not just a software delivery tool.

Practical implication: scan current and historical repository content for secrets, not just live branches.

Why long-lived PATs and hard-coded secrets defeat normal IAM controls

A PAT is not just a password substitute. It often bypasses MFA, survives beyond any human login session, and can be reused until explicitly revoked. Hard-coded AWS, GCP, Snowflake, or Salesforce credentials compound the problem because one repository compromise can expose multiple platforms at once. Traditional HR-driven lifecycle controls miss this entirely because the identity is machine-issued and code-embedded, not a human account managed through joiner-mover-leaver workflows. That creates a standing privilege problem inside engineering pipelines.

Practical implication: inventory token age, scope, and owner, then enforce expiry and revocation as policy.

What DevOps-native detection must watch for in secret compromise

Classic IAM and CIEM tools often miss the moment when an attacker clones an entire repository or begins using a credential from an unusual location. DevOps-native detection has to baseline repository access patterns, clone volume, geo-location, and token usage context so that a suspicious full-repo pull is not treated like a routine build job. Once an exposed token is found, the control objective shifts from prevention to containment. The attack surface is the combination of code, credentials, and pipeline behaviour, not any one system in isolation.

Practical implication: add repository- and token-behaviour telemetry to your identity threat detection coverage.

Threat narrative

Attacker objective: The objective was to turn a single exposed development token into broad, persistent access across cloud and SaaS systems for long-term data theft.

1. entry: Attackers located a GitLab personal access token in a public .git/config file and used it to access private repository content.
2. escalation: The cloned repositories contained hard-coded AWS, GCP, Snowflake, and Salesforce credentials that expanded access across multiple environments.
3. impact: The attackers pivoted into production and quietly siphoned large volumes of customer, financial, and support data over an extended dwell period.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Git repositories have become identity stores, not just code stores. Once secrets live in .git/config, commit history, or copied repository trees, the repository itself becomes a credential reservoir. That shifts the governance problem from software hygiene to identity containment across the DevOps toolchain. The practical conclusion is that source control must be governed as an access-bearing system, not a passive asset repository.

Long-lived PATs create standing privilege in a place most IAM programmes do not monitor. A Git personal access token can outlast the session, the code change, and even the developer’s awareness that it exists. That makes token age, scope, and ownership a direct NHI governance concern rather than a developer convenience issue. Practitioners should treat PAT persistence as latent privilege accumulation.

Hard-coded secrets create identity blast radius across cloud and SaaS platforms. A single repository leak can expose AWS, GCP, Snowflake, and Salesforce in one move, which means the breach boundary is defined by what the code contains, not by the security of any single cloud account. Identity blast radius: the maximum set of systems an exposed credential can unlock before it is detected and revoked. The implication is that control design must assume multi-platform lateral movement from one secret.

DevOps detection is now part of identity threat detection and response. The article’s core failure mode is not only exposure, but the inability to distinguish a malicious repo clone from ordinary engineering activity. That gap leaves organisations blind to the first meaningful signal of token abuse. The practitioner takeaway is that identity telemetry has to extend into repositories, pipelines, and token-use context.

Security programmes that separate human IAM from machine identity governance will keep missing this class of breach. The same organisation that carefully manages human access may still allow unmanaged tokens to persist in code for years. That inconsistency is not an edge case. It is a programme design flaw that lets NHI risk accumulate in the engineering stack, and it should be treated as such.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Aembit found that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• That same research shows 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with human IAM, which is why 52 NHI Breaches Analysis is a useful next read for control-pattern comparison.

What this signals

Identity blast radius: engineering teams should now think about how far a single leaked credential can move across source control, build systems, and SaaS platforms before detection catches up. The operational signal to watch is not only secret discovery, but whether the organisation can revoke and verify every downstream dependency fast enough to matter.

The numbers point to a structural lag in machine identity governance. With 88.5% of organisations saying non-human IAM lags human IAM, the problem is not isolated negligence, it is a programme design gap that will keep surfacing in repository, pipeline, and token lifecycle failures.

When organisations start treating repositories as identity-bearing systems, incident response changes. Secret scanning, ownership mapping, and token revocation need to be wired into engineering workflows as routine controls, not emergency exceptions, or the same exposure pattern will repeat in every cloud domain.

For practitioners

• Scan repositories for exposed secrets across history Search current branches, tags, and full Git history for PATs, API keys, certificates, and connection strings, including copied .git/config artefacts and forked repositories.
• Enforce owner mapping and expiry for every token Attach a human or system owner to each credential, record the issuing system, and quarantine tokens that have no clear lifecycle owner or a stale creation date.
• Rotate credentials the moment exposure is confirmed Treat a leaked token as active compromise until every related secret has been revoked, replaced, and verified across AWS, GCP, Snowflake, Salesforce, and any linked services.
• Add DevOps-native alerting for abnormal clone behaviour Baseline full-repository clone size, geography, and token use so that unusual access patterns trigger identity threat response before data exfiltration completes.

Key takeaways

• A leaked Git token is a machine identity failure because it turns code storage into a standing access path.
• The evidence shows that one exposed secret can unlock multiple cloud and SaaS systems and remain usable long enough for quiet exfiltration.
• The control that changes the outcome is not just better code review, but ownership, lifecycle enforcement, and repository-aware detection.

Key terms

• Personal Access Token: A personal access token is a bearer credential used to authenticate to a system without re-entering a password. In practice, it behaves like a password substitute for APIs, source control, and automation, so its scope, age, and revocation status must be managed as identity lifecycle data.
• Hard-Coded Secret: A hard-coded secret is a credential written directly into code, configuration, or repository history instead of being stored in a managed secret store. It is dangerous because anyone who can read the file, clone the repo, or access a historical commit may inherit the same access the secret provides.
• Identity Blast Radius: Identity blast radius is the maximum set of systems and data that a compromised credential can reach before it is detected and revoked. The concept is especially important for non-human identities because one leaked token can span multiple clouds, SaaS services, and automation paths at once.
• DevOps-Native Detection: DevOps-native detection is monitoring that understands repository, pipeline, and token behaviour as identity signals rather than treating them as ordinary application events. It is needed when attacker activity looks like normal engineering work unless clone volume, geography, and credential usage are analysed together.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The full GitLab token exposure chain, including the public .git/config path and repository cloning sequence.
• The practical detection and response steps for identifying hard-coded AWS, GCP, Snowflake, and Salesforce keys in source control.
• The GitHub integration workflow, including owner mapping, alerting, and optional token revocation playbooks.
• The specific CI/CD and DevOps controls used to turn secret discovery into a repeatable workflow.

👉 Unosecur's full post covers the Pearson and Internet Archive token exposure patterns, plus the response workflow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.