# GitHub Token Leak Exposes Novo Nordisk Development Pipeline: Why Secrets Management Failures Persist


A leaked GitHub personal access token belonging to Novo Nordisk engineers has exposed the company's source code repositories and internal development infrastructure. The incident—discovered through routine secret-scanning—underscores a critical industry pattern: organizations invest heavily in secrets vaults and scanning tools while failing to implement basic identity and access governance around those secrets.


## The Threat


Security researchers identified a Novo Nordisk GitHub token exposed in a publicly accessible repository, granting access to the company's private code repositories, CI/CD pipelines, and development workflows. The token appeared to have been committed accidentally—a common occurrence when developers manually paste credentials into scripts, documentation, or configuration files.


The scope of exposure included:

  • Source code repositories for internal applications
  • Access to build pipelines and deployment automation
  • Potential lateral movement into connected development infrastructure
  • IP exposure related to proprietary development tools and workflows

    • While Novo Nordisk has not disclosed whether the token was exploited before revocation, the incident serves as a reminder that even fortune 500 pharmaceutical companies remain vulnerable to foundational secrets management failures.


    ## Background and Context


    Novo Nordisk is a Danish multinational pharmaceutical corporation valued at over $600 billion USD and ranks among the world's largest drug manufacturers. The company operates globally with massive software engineering operations—development teams in multiple countries maintain thousands of repositories and microservices supporting manufacturing, supply chain, clinical data systems, and customer-facing platforms.


    ### Why This Happens


    GitHub tokens are frequently leaked because:


  • Developer workflow friction: Developers generate personal access tokens for local development, automation scripts, or CI/CD setup—and often forget they're credentials
  • Copy-paste shortcuts: Token reuse across projects and environments reduces overhead but multiplies exposure
  • Incomplete Git training: Many developers remain unaware that .git history is immutable; a committed secret is compromised forever, even after "removal"
  • Automated credential scanning gaps: Companies deploy secret-scanning tools but don't enforce blocking of commits with detected secrets in real-time

    • The Novo Nordisk incident is not unique—thousands of GitHub tokens are discovered leaked monthly by automated researchers and threat actors.


    ## Technical Details: How the Token Was Exposed


    ### The Exposure Chain


    1. Token Generation: An engineer created a GitHub personal access token with broad permissions (likely including repo, admin:org_hook, and user:email scopes)

    2. Accidental Commit: The token was pasted into a script, configuration file, or documentation

    3. Repository Push: The file was committed and pushed to a repository without triggering pre-commit hooks or secret-scanning blocks

    4. Public Availability: The repository was either public or its access controls were misconfigured, making the token discoverable via GitHub search or archived in backup/fork repositories


    ### Scope of Access


    GitHub personal access tokens grant broad permissions depending on their scopes:


    | Scope | Risk |

    |-------|------|

    | repo | Read/write to all private repositories |

    | admin:org_hook | Create webhooks that receive all repository events |

    | workflow | Full CI/CD pipeline manipulation |

    | user:email | Enumerate employee email addresses |

    | read:user | Access profile and user metadata |


    A token with typical developer scopes provides equivalent access to an engineer's account—sufficient to clone sensitive repositories, trigger builds, steal source code, and inject malicious changes into CI/CD pipelines.


    ### Detection and Response


    Novo Nordisk's security team likely discovered the leak through:

  • GitHub's token-scanning integration, which notifies organizations when tokens are detected in public repositories
  • Third-party secret-scanning services (GitGuardian, TruffleHog, etc.) that continuously scan the internet for exposed credentials
  • Internal audit mechanisms that flag inactive or overly-permissive tokens

    • The company revoked the token and initiated an investigation into whether the token had been accessed by unauthorized parties.


    ## Implications for Organizations


    ### Software Supply Chain Risk


    Leaked development credentials represent a direct pathway to software supply chain compromise. An attacker with access to a pharmaceutical company's source code repositories could:


  • Steal intellectual property related to drug formulations, manufacturing processes, or clinical data systems
  • Inject malicious code into applications before deployment (CI/CD poisoning)
  • Exfiltrate employee credentials or API keys stored in configuration files
  • Access internal infrastructure through repository-stored deployment scripts or SSH keys
  • Forge commits to introduce logic bombs, backdoors, or data-stealing code

    • ### Regulatory and Compliance Burden


    For companies in regulated industries like pharmaceuticals:

  • FDA compliance: Source code for clinical applications must be auditable and tamper-proof; unauthorized access creates audit failures
  • Data protection laws: If the repositories contain personal data or clinical records, the exposure triggers GDPR, HIPAA (for US operations), or equivalent notification requirements
  • Investor relations: IP theft or supply chain compromise can trigger mandatory disclosures to shareholders

    • ### Trust Erosion


    A publicized breach of development infrastructure damages:

  • Customer confidence in software security
  • Partner relationships (healthcare providers and hospital systems rely on pharmaceutical software)
  • Recruitment (security-conscious engineers question the company's security culture)

    • ## How Organizations Get This Wrong


    ### The Tooling Trap


    Most enterprises approach secrets management as a tooling problem:

  • *"Deploy a vault (HashiCorp, AWS Secrets Manager, Azure Key Vault)"*
  • *"Scan for exposed secrets with TruffleHog"*
  • *"Rotate credentials quarterly"*

    • These are necessary but insufficient. The Novo Nordisk incident reveals that tooling without identity governance fails. Specifically:


  • No audit of who created tokens and why: Engineers routinely generate personal access tokens without recording the purpose or required scope
  • No periodic review: Tokens persist indefinitely; access is never validated against current roles
  • No enforcement of least privilege: Tokens are granted blanket permissions ("repo access") rather than scoped to specific repositories or read-only operations
  • No real-time blocking: Commits with secrets are detected after-the-fact, not prevented before push

    • ### The Identity Problem


    The root issue is treating tokens as credentials, not as identity. An effective secrets management program requires:


    1. Token inventory: Document every token (human and machine), its purpose, permissions, and owner

    2. Scope minimization: Limit tokens to necessary repositories and operations (read-only for CI/CD, specific repo access for automations)

    3. Rotation schedules: Expire tokens quarterly or when ownership changes

    4. Access reviews: Quarterly verification that token holders still need access

    5. Real-time enforcement: Block commits with detected secrets before they're pushed (using git-guardian, pre-commit hooks, or server-side hooks)


    ## Recommendations


    ### For Development Teams


  • Use GitHub's built-in secret scanning (available at no additional cost with GitHub Enterprise)
  • Enable branch protection rules that block commits containing detected secrets
  • Prefer OIDC/Workload Identity over long-lived tokens; use GitHub Actions OIDC for CI/CD workflows instead of personal access tokens
  • Implement pre-commit hooks to scan staged files for secrets before commit
  • Document token purpose and scope in a shared registry; never create "just in case" tokens
  • Audit token usage logs (GitHub provides per-token activity logs) to detect anomalies

    • ### For Security Teams


  • Enforce automated secret scanning across all repositories (GitHub, GitLab, Bitbucket)
  • Conduct quarterly token audits: Require teams to justify each active token
  • Implement token expiration policies: Force rotation every 90 days for production access
  • Monitor token creation patterns: Alert on unusual token creation (e.g., a developer suddenly creating 10 tokens)
  • Integrate with SIEM: Forward secret-detection events to your security monitoring system
  • War-game token compromise: Simulate response to a leaked token to validate incident procedures

    • ### For Leadership


  • Fund secrets management infrastructure as a foundational security capability, not an afterthought
  • Allocate time for credential inventory: This unglamorous work prevents breaches
  • Measure token security metrics: Track token age, scope creep, and audit completion rates
  • Require security training on secrets: Many breaches stem from developer habits, not tools

    • ---


    ## HackWire Analysis


    The Novo Nordisk incident crystallizes a pattern we've observed across dozens of breaches: organizations confuse the symptom (exposed secrets) with the disease (broken identity governance). They deploy scanning tools and vaults, declare victory, then wonder why secrets keep leaking.


    The real issue is that GitHub tokens—and API keys, database passwords, SSH keys—function as *persistent identity credentials*. Once issued, they're almost never audited, scoped, or revoked. A developer creates a token in 2022 for a temporary automation task, forgets about it, and it sits in a repository for four years.


    What makes Novo Nordisk's case instructive is not that the token leaked—that's increasingly common—but what it reveals about the state of software engineering culture. Even at companies with sophisticated security teams and billions in revenue, the fundamentals are broken: No token inventory. No permission scope enforcement. No real-time blocking of commits with secrets.


    For defenders, the lesson is brutal but clear: Secrets management isn't solved by adding another tool. It's solved by treating tokens as identity artifacts that require the same governance as user accounts. That means inventory, least-privilege assignment, regular review cycles, and automated enforcement—not quarterly scanning followed by inaction.


    Organizations should demand that development teams operate token registries as rigorously as system administrators manage SSH keys. Until that cultural shift happens, leaks like Novo Nordisk's will remain predictable. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Tools](https://www.hackwire.news/category/tools) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)