What Happened
Novo Nordisk experienced a security breach when an attacker accessed its systems through a leaked GitHub token. This token, a credential for automated systems to interact with the company's repositories, was exposed and exploited. The breach wasn't due to a complex exploit but because a machine identity was mishandled as a mere configuration issue rather than a critical security credential.
Timeline
While specific dates remain undisclosed, the attack followed a typical pattern:
Initial exposure: A GitHub token was leaked, likely through an accidental commit to a public repository, exposure in logs, or improper storage in configuration files.
Discovery by attacker: The token was discovered and validated, granting access to Novo Nordisk's development infrastructure.
Exploitation: The attacker accessed repositories, potentially viewing source code, exfiltrating data, or identifying additional attack vectors.
Detection: The breach was identified, though the time between exposure and detection is not publicly documented.
Which Controls Failed or Were Missing
The core failure was conceptual. Novo Nordisk's security program treated the GitHub token as a secret to be stored, rather than managing it as an identity with its own lifecycle, permissions, and audit trail.
Missing identity governance: The token lacked controls applied to human identities. There was no:
- Time-bound validity requiring regular rotation
- Least privilege scoping to specific repositories or actions
- Monitoring for unauthorized access
Inadequate secrets detection: No automated scanning caught the token before attacker access, indicating missing or misconfigured pre-commit hooks and absent monitoring of public exposure surfaces.
Lack of token rotation policy: The token remained valid long enough for exploitation. A mature secrets management program would rotate tokens automatically to limit exposure.
Insufficient access review: Machine identities often persist indefinitely without ownership to review their necessity, scope, or monitoring.
What the Standards Require
Multiple frameworks address this gap, but organizations often misinterpret them as tooling requirements rather than identity management mandates.
PCI DSS v4.0.1 Requirement 8.2.2 mandates unique identification for all system components, including service accounts and API tokens, not just human users. Your GitHub token is a system identity requiring the same rigor as developer credentials.
ISO/IEC 27001:2022 Control 5.16 (identity management) and Control 5.17 (authentication information) require controlled provisioning, regular review, and secure handling for both human and machine identities.
OWASP ASVS v4.0.3 Section 2.10 (Service Authentication) requires service credentials to use short-lived access tokens, be scoped to specific operations, and monitored for misuse.
NIST 800-53 Rev 5 IA-4 (identifier management) requires managing identifiers for systems and devices, not just people, preventing reuse, and disabling them after inactivity.
The standards clearly require identity lifecycle management for all credentials. The gap lies in implementation—buying a secrets vault is not enough.
Lessons and Action Items for Your Team
Reframe Your Secrets Program as Identity Management
Ask "who is this token, what does it need access to, and for how long" instead of "where should we store this token." Create an inventory of every service account, API token, and machine credential. Each needs:
- An owner responsible for its lifecycle
- A documented business purpose
- An expiration date or rotation schedule
- Scoped permissions following least privilege
- Logging and alerting for usage
Implement Token Hygiene Matching User Account Policies
If user passwords rotate every 90 days, GitHub tokens shouldn't last indefinitely. Configure GitHub's fine-grained personal access tokens with explicit expiration dates. For GitHub Apps, implement credential rotation in your deployment pipeline. Set reminders if automation isn't ready—manual rotation is better than none.
Scan for Secrets in Three Places
Pre-commit: Use tools like git-secrets, TruffleHog, or Gitleaks as pre-commit hooks to block local commits before reaching the repository.
In-repository: Scan your entire commit history. GitHub's secret scanning flags some patterns, but run your own scans for organization-specific credentials.
Runtime: Monitor applications for secrets logged, exposed in error messages, or visible in process listings to catch leaks through operational mistakes.
Build Token Monitoring into Your SIEM
Feed GitHub audit logs into your security monitoring. Alert on:
- Token usage from unexpected IPs or locations
- Access to unauthorized repositories
- High-volume operations suggesting automated exfiltration
- Token usage outside normal business hours
Conduct Machine Identity Access Reviews
Quarterly, review every service account and token like user access. Ask:
- Is this still needed?
- Does it still need this level of access?
- Who owns it?
- When did it last rotate?
The Novo Nordisk breach occurred because a GitHub token was managed as a configuration artifact instead of a security-critical identity. Your secrets management tools are necessary, but not sufficient. Treat every API key, service account, and access token as an identity with a lifecycle, permissions, and accountability to avoid similar vulnerabilities.
