# Novo Nordisk Breach Exposes the Myth of "Secrets Management"


A leaked GitHub authentication token from pharmaceutical giant Novo Nordisk has illuminated a critical blind spot in enterprise security posture: organizations treat secrets management as a *tooling problem* when it's fundamentally an *identity and access control problem*. The exposure reveals not just technical negligence, but a systemic misunderstanding of how credentials should be provisioned, rotated, and audited in modern software development environments.


## The Threat


Novo Nordisk, one of the world's largest pharmaceutical manufacturers, experienced a breach involving a GitHub personal access token (PAT) that was exposed in its development infrastructure. The leaked token provided unauthorized access to the company's source code repositories, software development pipeline, and potentially the systems those applications connect to.


The scope of exposure remains significant:

  • Direct access: Repository code, configuration files, and development history
  • Secondary exposure: Hardcoded credentials within repositories (a common secondary discovery)
  • Pipeline compromise: Potential access to CI/CD workflows, build systems, and deployment processes
  • Third-party risk: Visibility into dependencies, libraries, and supply chain integrations

    • The incident was discovered and disclosed through security research communities, following the typical pattern of exposed secrets: token appears in public or semi-public locations, researchers scan and identify it, vendor is notified, incident response begins.


    ## Background and Context


    ### Why GitHub Tokens Matter


    GitHub personal access tokens (PATs) and organization tokens are not casual credentials—they represent high-privilege identity within the development ecosystem. A valid GitHub token grants:

  • Full repository access (read/write)
  • Access to organizational resources
  • Ability to modify code, tags, and deployment configurations
  • Potential to inject malicious code into supply chain
  • Access to secrets stored in GitHub Actions and repository variables

    • In pharmaceutical and biotech companies, source code repositories often contain:

  • Research data and algorithms
  • Security configurations for medical devices
  • Integration details with healthcare systems
  • Regulatory documentation and compliance records
  • Intellectual property with massive market value

    • ### The Secrets Management Misconception


    The industry's response to credential exposure typically follows this pattern:


    | What Companies Do | What They Should Do |

    |---|---|

    | Deploy a secrets vault (HashiCorp Vault, AWS Secrets Manager, etc.) | Implement identity-based access control with short-lived credentials |

    | Rotate credentials on a fixed schedule | Rotate credentials when identity contexts change (role, project, clearance) |

    | Scan code for hardcoded secrets | Audit who has access and why they need it |

    | Encrypt secrets at rest | Verify least-privilege provisioning and usage patterns |


    Novo Nordisk's breach likely involved a token that existed because someone needed access—but after that need expired, the token remained valid, discoverable, and exploitable. This is the identity problem masquerading as a tooling problem.


    ## Technical Details


    ### How Secrets Exposure Typically Occurs


    The leaked GitHub token likely surfaced through one of these vectors:


    1. Repository commit history: Developers accidentally committed the token to a public or private repository

    2. CI/CD logs: Token appeared in build logs, GitHub Actions output, or deployment artifacts

    3. Configuration files: Token stored in .env, config.json, or similar files checked into version control

    4. Memory dumps or crash reports: Shared debugging artifacts containing credentials

    5. Internal documentation or wiki: Credentials documented for "easy reference"


    ### The GitHub Token Lifecycle Problem


    A typical exposure reveals the fundamental failure:


    Token created → Embedded in script/config → Committed to repo → 
Repository cloned to local machines → Copied in CI/CD → 
Logged in build output → Scraped by security tools → 
Exploited by attackers (window: hours to months)

    Each step represents a failure of identity governance, not secret storage:

  • The token should never exist without a defined owner and purpose
  • The token should expire automatically when the purpose completes
  • The token should be auditable so usage can be verified
  • The token should trigger alerts when unexpected patterns occur

    • ### Real-World Attack Surface


    With a valid GitHub PAT, an attacker can:


    | Attack Vector | Impact |

    |---|---|

    | Modify source code | Inject backdoors into medical software |

    | Alter CI/CD pipelines | Compromise build artifacts and deployments |

    | Access organizational secrets | Retrieve API keys, database credentials, deployment tokens |

    | Trigger deployments | Push malicious code to production environments |

    | Access private repositories | Steal regulatory documentation, research data, IP |

    | Create branch protection bypasses | Circumvent code review and approval workflows |


    For a pharmaceutical company, this extends to:

  • Medical device software integrity
  • Clinical data systems
  • Regulatory submission documentation
  • Healthcare system integrations (EHR/EMR connections)

    • ## Background: The Pharma Security Imperative


    Pharmaceutical companies operate under unique regulatory frameworks:

  • FDA oversight: 21 CFR Part 11 requires auditable access control
  • HIPAA compliance: Health information connected to development systems
  • International regulations: GDPR, health data protection laws in multiple jurisdictions
  • Drug approval cycles: Code changes affect regulatory submissions and approval timelines

    • A compromise of the development pipeline doesn't just expose intellectual property—it potentially affects patient safety and regulatory standing.


    ## Implications for Organizations


    ### Immediate Risks


    1. Supply chain injection: Modified code deployed to customers without detection

    2. Regulatory impact: FDA may require investigation into code integrity during affected product cycles

    3. Competitive exposure: Research data and algorithms available to competitors

    4. Legal liability: Breach notification, potential shareholder litigation, patient notification obligations


    ### Systemic Exposure


    The incident should trigger organizations to ask:

  • How many GitHub tokens exist in our environment with indefinite lifetime?
  • Who actually uses each token and what happens when they leave the company?
  • Are we auditing token usage or just assuming they're secure?
  • How quickly can we revoke access if a token is compromised?
  • What's our process for provisioning access vs. what actually happens?

    • ### Industry Pattern


    Novo Nordisk is not an isolated case. Similar token exposure incidents have affected:

  • Technology companies with exposed AWS credentials
  • Financial institutions with leaked API tokens
  • Healthcare providers with compromised service account credentials

    • The common thread: credentials that outlive their purpose remain valid indefinitely.


    ## Recommendations for Defenders


    ### Immediate Actions


    1. Audit GitHub token inventory: Enumerate all PATs and organization tokens; document creation date, owner, and intended purpose

    2. Implement rotation policy: Auto-rotate or force re-authentication for tokens older than 90 days

    3. Enable token scanning: GitHub's secret scanning and third-party tools (Truffle Hog, GitGuardian) should be mandatory

    4. Review access logs: Audit all token usage against legitimate business purposes

    5. Revoke unused tokens: Any token without documented, active use should be deleted


    ### Strategic Shifts


    | Focus Area | Action |

    |---|---|

    | Identity Model | Shift from "credential management" to "ephemeral identity provisioning" |

    | Access Pattern | Use short-lived tokens (15 min - 1 hour) generated on-demand instead of persistent credentials |

    | Audit Trail | Log every token creation, usage, and deletion; alert on anomalous patterns |

    | Automation | Decouple humans from token management; use OAuth, OIDC, or service principals instead |

    | Regulation | Treat GitHub tokens with same rigor as production database credentials |


    ### Technical Implementation


  • GitHub App authentication: Replace PATs with fine-grained GitHub App tokens with minimal scope
  • Workload identity: Use OIDC or similar mechanisms to provision short-lived credentials to CI/CD workflows
  • Credential federation: Let infrastructure providers (AWS, GCP, Azure) handle credential lifecycle
  • Usage monitoring: Deploy behavioral analytics to detect unusual API activity

    • ## HackWire Analysis


    The Novo Nordisk breach exposes an uncomfortable truth that most security organizations refuse to acknowledge: we've abdicated responsibility for managing identity to tools and platforms that were never designed to make identity decisions.


    Secrets management tools like Vault and AWS Secrets Manager are *storage* solutions, not *governance* solutions. They keep secrets from being logged or exposed, but they don't answer the fundamental question: *Should this identity exist right now?* And yet organizations deploy these tools, congratulate themselves on "security hardening," and move on—while persistent credentials continue to accumulate in their environments like technical debt.


    The leaked GitHub token didn't materialize because Novo Nordisk lacked a secrets vault. It existed because somewhere, someone needed repository access for a specific task, received a permanent credential to fulfill it, and then that credential remained valid long after the task completed. That's not a tooling problem—that's an identity governance failure. And until organizations stop conflating "we encrypted our credentials" with "we control who has access," incidents like this will continue.


    The pharmaceutical industry should pay special attention. Unlike most software companies, pharma has existing regulatory frameworks (FDA 21 CFR Part 11) that already mandate auditable access control. The supply chain implications of compromised development infrastructure are not abstract—they directly affect drug manufacturing, clinical trial data, and ultimately patient safety. Novo Nordisk should be a wake-up call for every pharma security team to inventory their credentials, understand *why* each one exists, and implement time-bound access models that require active justification rather than passive retention.


    The lesson for all industries: a secrets vault is a tax on poor identity hygiene, not a cure for it. Treat every credential as temporary unless you can articulate exactly why it needs to persist.


    — HackWire Editorial


    ## Recommendations


    For development teams:

  • Audit all personal access tokens; delete any without documented active use
  • Implement token rotation in your onboarding/offboarding workflows
  • Use environment variables and CI/CD secrets managers instead of hardcoded credentials
  • Enable GitHub's secret scanning on all repositories (public and private)

    • For security teams:

  • Establish a credential inventory: what tokens exist, who owns them, when they expire
  • Implement OAuth or GitHub App authentication to replace long-lived PATs
  • Deploy automated scanning in your CI/CD pipeline to catch exposed secrets before commit
  • Create alert rules for unusual GitHub API activity

    • For compliance and risk management:

  • Review how credential compromise impacts regulatory obligations (FDA, HIPAA, GDPR)
  • Establish incident response procedures specific to development infrastructure breaches
  • Audit third-party access to development systems and repositories
  • Document the business justification for every production access credential

    • ## 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/)