Novo Nordisk GitHub Token Leak: What Went Wrong and Why It Matters
When a GitHub token linked to Novo Nordisk, one of the world's largest pharmaceutical companies, was found exposed online, it sent a clear warning signal across the software development industry. The incident was not simply a matter of poor tooling or an overlooked configuration file. It pointed to something far more systemic: a fundamental misunderstanding of what secrets management actually is and where it sits within the security stack.
The breach underscores a critical lesson that security professionals have been sounding the alarm about for years. Most organizations treat secrets management as a tooling problem — something to be solved by rotating credentials, adopting a vault solution, or scanning repositories for leaked keys. In reality, secrets management is an identity problem, and until organizations internalize that distinction, their software development pipelines will remain dangerously exposed.
What Is a GitHub Token and Why Is It So Dangerous?
A GitHub token is a form of authentication credential used to grant access to repositories, automate workflows, and interact with the GitHub API. These tokens are routinely embedded in CI/CD pipelines, build scripts, and developer machines to allow automated systems to push code, trigger actions, and pull dependencies without manual sign-in.
When a token is leaked — whether through a public repository commit, a misconfigured environment variable, or an exposed log file — it effectively hands an attacker the keys to your software supply chain. Depending on the permissions scope assigned to the token, an adversary could read proprietary source code, inject malicious dependencies, alter build artifacts, or even pivot deeper into cloud infrastructure through connected integrations.
In the case of a company like Novo Nordisk, whose software development pipelines touch sensitive research data, regulatory compliance systems, and global operational infrastructure, the blast radius of a single leaked token is enormous.
The Core Problem: Secrets Are Identities in Disguise
Here is where the industry continues to get things wrong. Most organizations approach a leaked secret the way they would approach a lost badge — revoke it, reissue it, and add a scanner to catch the next one. That response treats the credential as an object rather than as what it actually is: a non-human identity.
Every API key, service account token, SSH key, and deployment credential represents an entity that can authenticate, authorize, and act within your systems. These are machine identities, and they deserve the same lifecycle management, least-privilege principles, and behavioral monitoring that human identities receive. The failure to treat them that way is precisely why secrets breaches keep happening at organizations of every size and sector.
When a GitHub token is issued for a CI/CD pipeline and never rotated, never audited, and granted broad repository access far beyond its operational needs, that is not a tooling failure. That is an identity governance failure. And vault tools or secret scanning alone cannot fix a governance gap.
How Software Development Pipelines Become Attack Surfaces
Modern software development pipelines are sprawling ecosystems. They span source control platforms, artifact registries, container orchestration systems, cloud providers, and third-party SaaS integrations. Each connection point in that chain typically requires some form of authentication credential — and each of those credentials is a potential entry point for attackers.
The problem compounds when you consider how secrets proliferate in practice. Developers embed tokens in local environment files to meet deadlines. Build systems inherit credentials from parent pipelines without anyone tracking the lineage. Third-party tools request broad permissions during setup and are never restricted afterward. Over time, organizations accumulate hundreds or thousands of secrets they cannot fully account for, spread across systems with inconsistent access controls and no unified visibility.
This is the landscape that the Novo Nordisk breach brings into sharp focus. A single leaked GitHub token is rarely the whole story. It is usually the visible tip of a much larger secrets sprawl problem that has been building quietly beneath the surface.
What Organizations Must Do Differently
Adopt a Non-Human Identity Framework
Security and engineering teams need to extend their identity governance programs explicitly to machine identities. Every secret should be inventoried, attributed to a specific service or workflow, assigned an owner, and governed by a defined lifecycle including creation, rotation, and revocation policies. If you cannot answer who owns a given token and what it is authorized to do, that token is a liability.
Apply Least Privilege to Every Credential
Secrets should carry the minimum permissions required for their specific function and nothing more. A token used to read build artifacts from one repository should not have write access to the entire organization. Scoping credentials tightly limits the damage if they are ever compromised, and it makes anomalous access far easier to detect.
Move Beyond Scanning to Continuous Monitoring
Secret scanning tools are valuable, but they are reactive by design. They catch secrets that have already been exposed. Organizations need to pair scanning with continuous behavioral monitoring that flags when a secret is used in an unexpected context — an unusual geographic location, an off-hours request, or access to a system the credential has never touched before.
Integrate Security Into the Developer Workflow
Security controls that exist outside the developer workflow are consistently bypassed, not out of malice but out of friction. Pre-commit hooks, IDE plugins that detect hardcoded secrets, and secrets injection at runtime through secure vaults rather than environment variables all reduce the likelihood that a credential ends up somewhere it should not be.
The Broader Implication for the Industry
The Novo Nordisk GitHub token incident is not an isolated event. It is representative of a systemic gap in how enterprises think about the security of their software development lifecycle. As organizations accelerate their adoption of DevOps practices, cloud-native architectures, and AI-assisted development tools, the number of machine identities in their environments is growing exponentially — and the governance frameworks are not keeping pace.
Addressing this gap requires a shift in mindset at the leadership level. Secrets management must be elevated from a configuration concern handled at the team level to a core component of enterprise identity strategy, resourced and governed accordingly. The organizations that make that shift now will be considerably more resilient against the software supply chain attacks that are already defining the threat landscape of this decade.
The lesson from Novo Nordisk is not that their tools failed them. It is that the industry's collective mental model of secrets — as static objects rather than dynamic identities — has been failing everyone for a long time.