Join our Newsletter — 33% off our NHI Course

Ungoverned GitHub tokens: what IAM teams are missing now

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16876
Topic starter  

TL;DR: Unosecur reports that a GitHub personal access token embedded in client-side JavaScript let FulcrumSec move through hundreds of private Novo Nordisk repositories, harvest additional credentials and claim access to AI assets and clinical data. The breach shows that long-lived machine credentials become an identity graph when they are never inventoried or rotated, and blast radius matters more than initial access.

Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Novo Nordisk Breach: How One Ungoverned Token Cost Millions”.

Key questions

Q: What breaks when a GitHub token is embedded in client-side code?

A: The token stops behaving like a controlled identity and starts behaving like an unmanaged bearer credential.

Q: Why do code-resident machine credentials create such a large breach surface?

A: Because their risk is determined by scope, not by the line of code where they appear.

Q: How can organisations tell whether token governance is actually working?

A: Token governance is working when every live token has a named owner, a bounded purpose, and a clear runtime signal that shows whether it is being used inside its intended context.

Practitioner guidance

  • Map repository-exposed machine identities Build a live inventory of tokens, service credentials, and API keys that appear in source, build artefacts, and CI paths, and record their owners, scope, and expiry.
  • Enforce narrow repository scope Review every GitHub personal access token and remove broad access across hundreds of private repositories unless the business case is explicit and current.
  • Move credentials out of source code Block commits and builds that contain secrets in JavaScript bundles, config files, or deployment manifests, and fail the pipeline when detection hits.

Bottom line: A single unmanaged GitHub token can behave like a broad identity graph when it is embedded in code and granted access across repositories.

What's in the full article

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

  • The article traces the reported timeline of the Novo Nordisk incident and the claims FulcrumSec made about repository access.
  • It discusses how the token was embedded in client-side JavaScript and how that changed the attack surface.
  • It outlines the claimed repository count, AI assets, and clinical data exposure in more operational detail.
  • It closes with Unosecur's own mapping of the incident to machine-identity governance gaps and detection limitations.

👉 Read Unosecur's analysis of ungoverned GitHub tokens and Novo Nordisk exposure →

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 6 months ago
Posts: 17366
 

Ungoverned tokens create an identity graph, not a secret leak. This incident is not explained by a single leaked credential alone. The real failure mode is that a machine credential lived inside code without lifecycle governance, so every reachable repository became part of its access surface. That is a non-human identity governance problem, not a one-off secrets mishap. Practitioners should stop asking where the token was found and start asking what other identities it could expose.

A few things that frame the scale:

  • 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
  • 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.

A question worth separating out:

Q: What should teams do after discovering a token has been used in a breach?

A: They should treat the incident as a credential graph problem, not a single-token problem. That means revoking the exposed token, searching every reachable repository and pipeline for related secrets, and determining which downstream identities may already have been harvested.

👉 Read our full editorial: Ungoverned tokens in code create the real NHI breach surface



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.