TL;DR: Unosecur reports that a leaked GitLab personal access token let attackers clone private repositories, harvest hard-coded cloud and SaaS keys, and pivot into production at Pearson, with a similar exposure pattern also seen at the Internet Archive. Static secrets in source control remain a systemic identity failure, not a point-in-time code hygiene issue.
At a glance
What this is: This analysis shows how a leaked Git token can expose cloud and SaaS credentials, enable repository cloning, and create a long-lived production compromise path.
Why it matters: It matters because DevOps pipelines often treat tokens and keys as implementation details, while identity teams need them governed as non-human identities with lifecycle, scope, and detection controls.
👉 Read Unosecur's analysis of Git token leakage and DevOps secrets security failures
Context
Git token leakage is an identity governance problem when credentials live inside source control instead of a controlled secrets lifecycle. In that model, the token is not just a code mistake; it is a non-human identity with broad access, unclear ownership, and no reliable offboarding path.
This article uses Pearson and the Internet Archive to show how the same pattern repeats across organisations. A GitLab personal access token in a public .git/config file opened access to private repositories, exposed downstream cloud and SaaS keys, and left defenders reacting after the credentials had already done their work.
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 hardcoded secrets create such a large security risk?
A: Hardcoded secrets turn source code, build output, and configuration files into credential repositories, which makes exposure easy to repeat and difficult to contain. Once a secret is copied into multiple systems, revocation becomes slow and incomplete, and the attack window stays open far longer than most teams expect. That is why hardcoded credentials are a governance failure, not just a code smell.
Q: What are the signs that a Git token has become a governance problem?
A: Warning signs include tokens with no clear owner, no expiry, broad scopes, and repo access patterns that do not match normal engineering activity. If defenders cannot answer who issued the token, what it can reach, and when it should be retired, governance has already failed.
Q: How should teams respond when a token leak exposes production access?
A: Revoke the token first, then inventory every credential that token could have exposed or unlocked. After containment, rotate related secrets, inspect repository history, and verify that no lingering access paths remain in CI/CD, cloud, or SaaS systems.
Technical breakdown
How a Git token becomes a reusable identity
A Git personal access token behaves like a credentialed identity, not a harmless string. Once it is embedded in a repository configuration file, it can be copied, replayed, and abused anywhere the token is accepted. Because PATs often bypass MFA and can carry broad scopes, they become durable access paths that outlive the developer intent that created them. The real failure is not the leak alone. It is the absence of lifecycle control over a credential that should have been issued, scoped, and retired like any other privileged identity.
Practical implication: treat Git tokens as governed identities with scope, owner, and expiry, not as incidental developer artefacts.
Why hard-coded secrets amplify cloud and SaaS exposure
Hard-coded secrets turn source control into an access broker for everything downstream. If a repository contains AWS, GCP, Snowflake, or Salesforce keys, one token leak can reveal multiple control planes at once. That is why the attack path is so damaging: repository access becomes credential discovery, and credential discovery becomes production access. The issue is not limited to the Git platform. It is the trust boundary between code, secrets management, and runtime access, which breaks when credentials are stored where every clone can recover them.
Practical implication: remove production secrets from source trees and verify that repository access cannot reveal cloud or SaaS credentials.
Why DevOps-native detection must watch clone behaviour
Traditional cloud or IAM monitoring often misses DevOps misuse because the suspicious action starts inside the engineering workflow. A mass repository clone, unusual token usage, or access from an unexpected geography may look like normal build automation unless the detection model understands developer context. In this article, the absence of real-time visibility meant the token could be used quietly for months. The control gap is not just logging; it is behavioural detection around token ownership, age, and use patterns across the software delivery pipeline.
Practical implication: baseline repository clone volume, token age, and owner context so unusual DevOps access stands out quickly.
Threat narrative
Attacker objective: The attacker objective was to turn one leaked development token into broad production access and sustained data theft across multiple platforms.
- Entry occurred when attackers found a GitLab personal access token exposed in a public .git/config file.
- Credential access followed as the token unlocked private repositories and revealed hard-coded cloud and SaaS secrets.
- Escalation happened when those downstream credentials were used to reach production systems and broader data stores.
- Impact came from prolonged, quiet exfiltration of customer and financial data without timely detection.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Git tokens have crossed from developer convenience into identity governance territory. Once a PAT can unlock repositories and downstream cloud credentials, the question is no longer code hygiene but credential lifecycle control. The article shows that ownership, scope, and retirement are the real failure points. Practitioners should treat every token in source control as a governed non-human identity.
Hard-coded secrets create identity blast radius, not just exposure risk. One leaked token can expose multiple control planes because source code often contains credentials for AWS, GCP, Snowflake, and SaaS services. That widens the compromise from a single repository to the production environment itself. The practitioner lesson is that secrets sprawl multiplies the blast radius of any one leak.
Zero-standing-privilege for DevOps is now a source-control requirement, not a nice-to-have. Long-lived PATs bypass the assumptions behind static access models because they remain valid long after the developer context has changed. That makes dormant credentials one of the most durable paths into cloud and SaaS infrastructure. Security teams need to recognise that persistent token access is a governance failure, not an operational edge case.
DevOps detection must understand credential behaviour, not just infrastructure events. A large repository clone, a stale token, or a token used from an unusual network location are identity signals, not merely platform noise. The article’s core lesson is that the pipeline itself has to be monitored as an access surface. Without that, compromise looks like normal engineering activity until production data is already gone.
Git token leakage is a cross-domain identity problem that spans human, NHI, and delivery workflow controls. Developers create the secret, the token acts as the non-human identity, and the pipeline preserves the exposure. That overlap makes this problem especially hard for organisations that split IAM, DevOps, and security operations. The practical conclusion is that source control, secrets management, and identity governance have to be managed as one control plane.
What this signals
Source control now needs to be governed as an identity surface, because the same token sprawl that helps developers move fast can quietly extend access into cloud and SaaS systems. The operational question is no longer whether secrets exist in code, but whether the organisation can see, scope, and retire them before they become reusable access.
A stronger programme will connect secrets management, token lifecycle, and repository monitoring into one control loop. That is the only way to close the gap between development convenience and production-grade identity assurance.
For practitioners
- Audit repository configuration files for exposed credentials Search public and private repos for .git/config files, hard-coded access keys, and PATs that can be replayed into production systems. Treat any finding as an active credential exposure event, not a documentation issue.
- Reclassify Git tokens as governed non-human identities Assign owners, scopes, expiry rules, and revocation paths to every token used in DevOps workflows. If a token cannot be tied to a person, service, or system with clear lifecycle controls, it should not be allowed to persist.
- Move secrets out of source control Store production credentials in a managed secrets system and ensure repositories only reference short-lived retrieval paths. Blocking hard-coded secrets is more effective than trying to detect every downstream misuse after the fact.
- Add DevOps-native detection for unusual token use Baseline normal clone volume, token age, and repository access patterns so a sudden bulk clone or off-hours access is visible. Tie alerts to owner context so security teams can distinguish automation from credential abuse.
Key takeaways
- A single leaked Git token can turn source control into a production access path when repositories contain hard-coded cloud and SaaS secrets.
- The breach pattern in the article shows that ungoverned tokens create lasting exposure because ownership, scope, and rotation are often missing.
- Teams limit damage by moving secrets out of code, shortening token lifetime, and monitoring repository behaviour as an identity control surface.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on Git tokens and hard-coded secrets exposed through source control. |
| NHI-07 — Long-Lived Secrets | Long-lived PATs are a core failure mode in the article's breach pattern. | |
| NHI-05 — Overprivileged NHI | The token and downstream keys carried broad scopes that enabled production access. | |
| Recommendation — Scan repositories for leaked secrets and revoke any exposed tokens immediately. Shorten token lifetimes and remove secrets that remain valid after the developer context ends. Reduce token scope so repository credentials cannot reach production systems or SaaS control planes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle, rotation, and revocation are central to the failure described. |
| Recommendation — Apply IA-5 to manage token issuance, rotation, and revocation with enforceable lifecycle rules. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path moved from token theft to repository access and then to production compromise. |
| Recommendation — Map leaked-token incidents to credential access and lateral movement patterns in your detections. | ||
Key terms
- GitHub Personal Access Token: A GitHub Personal Access Token is a secret string used to authenticate a person or automation to GitHub resources. It functions as a bearer credential tied to a user account, with scopes that limit what APIs, repositories, and actions the token can access. If exposed, it can enable unauthorized code, data, or workflow access.
- Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
- Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
What's in the full article
Unosecur's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of how the Pearson token exposure moved from repository leak to production access
- Specific control failures across hard-coded secrets, token scope, and missing DevOps threat detection
- Practical sequencing for repository scanning, token rotation, and CI/CD gate insertion
- The Internet Archive comparison that shows why the same leak pattern persists across very different organisations
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management 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 IAM programme maturity, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org