Novo Nordisk Breach Exposes the Hidden Danger Inside Software Development Pipelines
When people think about data breaches, they typically imagine sophisticated nation-state hackers, ransomware gangs, or elaborate phishing campaigns. But one of the most instructive security incidents in recent memory started with something far more mundane: a leaked GitHub token. The Novo Nordisk breach has pulled back the curtain on a vulnerability that exists inside thousands of organizations — a fundamental misunderstanding of what secrets management actually is, and who is responsible for it.
The incident is more than a cautionary tale for pharmaceutical companies or large enterprises. It is a wake-up call for every organization running a modern software development pipeline, which, in 2025, means nearly every organization on the planet.
What Happened with the Novo Nordisk GitHub Token Leak
Details emerging from the Novo Nordisk incident point to a leaked GitHub personal access token that exposed the company's software development pipeline. GitHub tokens function as authentication keys — they grant whoever holds them the ability to read, write, and in some cases administer code repositories. When a token like this leaks into a public space, whether through a misconfigured repository, an accidentally committed config file, or a third-party tool logging credentials, the consequences can be severe.
In a pharmaceutical and life sciences context, the stakes are extraordinarily high. Software pipelines at companies like Novo Nordisk do not just manage internal productivity tools. They underpin research workflows, regulatory submission systems, and increasingly, software embedded in or adjacent to medical devices and drug delivery platforms. Compromising a development pipeline could mean injecting malicious code into systems that have real-world patient safety implications.
But the core lesson here is not specific to Novo Nordisk's industry. The mechanism of failure — a leaked secret providing an attacker with authenticated access — is one of the most common and most underestimated attack vectors across all sectors.
The Real Problem: Secrets Management Is an Identity Problem
Here is where most organizations get it fundamentally wrong. When a leaked token or exposed API key is discovered, the instinctive response is to reach for a tooling solution. Teams evaluate secrets scanning products, deploy vaults, implement pre-commit hooks, and configure automated alerts. These are all valuable measures. But they address the symptom rather than the disease.
The deeper issue is that secrets — tokens, API keys, certificates, passwords — are a form of identity. They assert, on behalf of a machine or service, the right to access a resource. And yet, most organizations manage machine identity with a fraction of the rigor they apply to human identity.
Think about how a large enterprise handles a new employee's access. There is an onboarding process, role-based permissions, multi-factor authentication, and periodic access reviews. Now think about how that same enterprise handles a new service account or a GitHub Actions workflow token. In most cases, the token is created, granted broad permissions to avoid friction during development, stored in an environment variable or a config file, and then largely forgotten. No rotation schedule. No least-privilege review. No audit trail for who created it or why.
This asymmetry between human identity governance and machine identity governance is the gap that attackers exploit. The Novo Nordisk incident is simply the latest high-profile example of what happens when that gap goes unaddressed.
Why CI/CD Pipelines Are Especially Vulnerable
Modern software delivery depends on continuous integration and continuous deployment pipelines. These automated systems pull code from repositories, run tests, build artifacts, and push deployments — often touching dozens of integrated services along the way. To do this, they need credentials. Lots of them.
A typical CI/CD pipeline might hold tokens for source control, container registries, cloud providers, monitoring platforms, package repositories, and internal services. Each one of those tokens is a potential entry point. And because pipelines are designed for speed and automation, security controls are frequently deprioritized in favor of keeping builds fast and developers unblocked.
The result is what security researchers sometimes call a "secrets sprawl" problem. Credentials proliferate across pipeline configuration files, environment variables, third-party integrations, and developer machines. Many of them are over-privileged. Many are never rotated. Some are duplicated across multiple systems. Tracking them all becomes practically impossible without deliberate, systematic governance.
What Organizations Must Do Differently
Addressing this problem requires a shift in mindset before it requires a shift in tooling. Organizations need to start treating every secret as an identity artifact — something that must be provisioned, governed, audited, and eventually deprovisioned with the same care as a human user account.
In practical terms, this means several things:
- Adopt a least-privilege model for machine identities. Every token, service account, and API key should have only the permissions it needs to perform its specific function — nothing more. Broad, permissive tokens might be convenient during development, but they dramatically expand the blast radius of any compromise.
- Implement mandatory rotation policies. Long-lived credentials are a persistent liability. Automated rotation, enforced at the platform level, reduces the window of exposure for any single leaked secret.
- Centralize secrets storage in a dedicated vault. Hardcoded credentials in source code or pipeline configuration files are a solved problem — solved by secrets management platforms that provide centralized storage, access logging, and integration with CI/CD tooling. The technology exists; the challenge is consistent adoption.
- Integrate secrets scanning into the development workflow. Pre-commit hooks and repository scanning tools can catch accidental credential commits before they reach a shared codebase, let alone a public repository.
- Establish continuous audit and discovery. Organizations cannot govern what they cannot see. Regular discovery sweeps to identify where credentials exist, who created them, and what they can access are essential for maintaining an accurate picture of machine identity risk.
Reframing DevSecOps Around Identity
The DevSecOps movement has done important work embedding security thinking into software development culture. But much of that work has focused on application-layer security — vulnerability scanning, dependency audits, penetration testing. The identity layer of the pipeline itself has received comparatively little attention.
The Novo Nordisk breach is an opportunity for the industry to correct that imbalance. Software pipelines are not just code factories. They are complex, interconnected systems of trust relationships — and every token, key, and certificate in those systems represents a trust relationship that must be actively managed.
Organizations that continue to treat secrets management as a checkbox in their security tooling inventory, rather than as a core discipline of identity governance, will remain exposed. The question is not whether a leaked credential will become an attack vector. It is whether the governance structures are in place to detect it, contain it, and prevent it from becoming a catastrophic breach.
The Novo Nordisk incident will not be the last of its kind. But it does not have to be the next one to affect your organization.