Topic starter
24/06/2026 5:42 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Pearson & Internet Archive Git Breaches”.
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.
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.
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.
Practitioner guidance
- 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.
- Reclassify Git tokens as governed non-human identities Assign owners, scopes, expiry rules, and revocation paths to every token used in DevOps workflows.
- Move secrets out of source control Store production credentials in a managed secrets system and ensure repositories only reference short-lived retrieval paths.
Bottom line: A single leaked Git token can turn source control into a production access path when repositories contain hard-coded cloud and SaaS secrets.
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
👉 Read Unosecur's analysis of Git token leakage and DevOps secrets security failures →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:38 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Git token leakage shows why DevOps secrets security still fails