Novo Nordisk Vorfall zeigt Risiko der Entwicklungspipeline

Was ist passiert?

18. Juni 2026 - Die Cybersicherheitswelt ist erneut in Aufruhr über die Nachricht eines Sicherheitsvorfalls bei einem großen Namen. Diesmal steht Novo Nordisk im Rampenlicht, der dänische Pharmariese, bekannt für seine Medikamente zur Behandlung von Diabetes und Adipositas. Dieser Vorfall ist jedoch kein typischer Ransomware-Angriff oder ein Datenbank-Hack, bei dem die persönlichen Daten von Millionen von Benutzern gestohlen wurden. Diese Wunde kommt von viel tiefer, aus dem Herzen der modernen Softwareentwicklung: ein geleakter GitHub-Token.

Auf den ersten Blick mag das Ereignis wie ein einfacher Fehler erscheinen. Ein GitHub-Token – ein digitaler Schlüssel, der einem Entwickler oder einem automatisierten System gehört und Zugriff auf Code-Repositorys gewährt – wurde irgendwie preisgegeben. Aber dieser einfache Fehler öffnete die Türen zu Novo Nordisks hochsensiblem und kritischem System, das als Software-Entwicklungspipeline bekannt ist. Dies bedeutet, dass alle Prozesse, die zeigen, wie das Unternehmen seine digitalen Produkte erstellt, testet und vertreibt, potenziell offengelegt sind. Das ist vergleichbar damit, als ob nicht nur die fertigen Autos aus einer Autofabrik gestohlen würden, sondern die gesamte Montagelinie, die Roboterprogramme und die Produktionsgeheimnisse.

Dieser Vorfall ist auch ein Weckruf für eine Tatsache, die in Cybersicherheitskreisen oft diskutiert, aber in den Vorstandsetagen nicht ausreichend verstanden wird. Sicherheit endet nicht mit dem Kauf und der Installation teurer Tools. Das eigentliche Problem ist die Verwaltung, wer diese Tools wann und warum nutzt – mit anderen Worten, es geht um Identität.

Welche Daten wurden kompromittiert?

Novo Nordisk hat noch keine detaillierte Erklärung dazu abgegeben, welche genauen Daten von dem Leck betroffen sind. Bei solchen Vorfällen ziehen es Unternehmen oft vor, bis zum Abschluss der internen Untersuchung zu schweigen. Es ist jedoch nicht schwer, sich die Folgen eines geleakten GitHub-Tokens vorzustellen. Es kann einen Dominoeffekt auslösen.

Potenziell gefährdet sein könnten:

• Quellcode: Die Baupläne für die Software, Anwendungen und internen Systeme des Unternehmens. Dies ist einer der wertvollsten Teile des geistigen Eigentums des Unternehmens. Für Konkurrenten oder böswillige Akteure ist dieser Code wie eine Schatzkarte.
• Infrastrukturkonfigurationen: Dateien, die festlegen, wie Server, Datenbanken und Cloud-Dienste eingerichtet und verwaltet werden. Ein Angreifer mit diesen Informationen kann leicht andere Schwachstellen im System finden.
• Andere eingebettete Geheimnisse: Um Zeit zu sparen, betten Entwickler manchmal andere „Geheimnisse“ wie API-Schlüssel, Passwörter oder Zertifikate für den Zugriff auf andere Systeme direkt in den Code ein. Der anfänglich geleakte Token könnte eine Kettenreaktion auslösen, so wie ein Schlüssel den Schlüssel zu einem anderen Safe enthüllt.

Derzeit ist nicht bekannt, ob Kunden- oder Patientendaten direkt von diesem Leck betroffen sind. Die Möglichkeit eines Angriffs auf die Software-Lieferkette ist jedoch immer gegeben. Wenn Angreifer Zugang zur Codebasis des Unternehmens erlangt haben, besteht theoretisch das Risiko, dass sie bösartigen Code in zukünftige Produktupdates einschleusen. Die Untersuchung des Unternehmens in dieser Angelegenheit dauert an.

Wie ist der Angriff passiert?

Im Zentrum dieses Angriffs steht kein komplexer Exploit oder eine Zero-Day-Schwachstelle. Im Kern steht ein „Geheimnis“, das ein Eckpfeiler der modernen Softwareentwicklung ist: ein GitHub-Token. Die technischen Details des Angriffs wurden noch nicht mit der Öffentlichkeit geteilt, aber die Essenz des Vorfalls ist ziemlich klar.

Ein GitHub-Token ist eine Zeichenfolge, die einem Benutzer oder einem Automatisierungstool (wie einer CI/CD-Pipeline) die Berechtigung zum Zugriff auf Code-Repositorys auf GitHub gewährt. Es funktioniert wie ein Passwort, hat aber oft umfangreichere Berechtigungen und ist für die Kommunikation von Maschine zu Maschine konzipiert. Dieser Token wurde irgendwie preisgegeben, zum Beispiel indem er versehentlich in ein öffentliches Repository hochgeladen oder vom Computer eines Entwicklers gestohlen wurde.

Sobald die Angreifer diesen Token in die Hände bekamen, mussten sie kein System mehr „hacken“. Sie meldeten sich als legitimer Benutzer oder Dienst an – der Besitzer des Tokens. Dies ist der Punkt, der den Vorfall von einem „Tooling-Problem“ in ein „Identitätsproblem“ verwandelt.

Die meisten Organisationen gehen das Geheimnismanagement mit der Einstellung an: „Kaufen wir ein Tool wie HashiCorp Vault oder AWS Secrets Manager, legen unsere Geheimnisse dort ab, und wir sind sicher.“ Das eigentliche Problem ist jedoch, wer auf diesen Tresor zugreifen kann. Wenn Sie den Schlüssel zum Tresor (in diesem Fall den GitHub-Token) herumliegen lassen, spielt es keine Rolle, wie sicher der Tresor ist. Der Novo-Nordisk-Vorfall zeigt, dass die Identitäten von Menschen und Maschinen, die auf diese Geheimnisse zugreifen, genauso kritisch sind wie die Geheimnisse selbst. Ein Token ist nicht nur ein Passwort; es ist eine Identität. Und wenn diese Identität gestohlen wird, wird der Angreifer zu Ihnen.

Wer ist betroffen?

Die Auswirkungen dieses Lecks breiten sich in Wellen aus.

• Novo Nordisk: Das Unternehmen selbst ist das größte Opfer. Es könnte mit schwerwiegenden Konsequenzen wie Diebstahl geistigen Eigentums, Reputationsschaden, behördlichen Untersuchungen und potenziellen Geldstrafen konfrontiert sein. Ganz zu schweigen von den sofortigen Investitionen, die sie tätigen müssen, um ihre Softwareentwicklungsprozesse zu sichern.
• Investoren und Partner: Bedenken hinsichtlich der Sicherheitslage des Unternehmens könnten zu Volatilität der Aktienkurse und einem Vertrauensverlust bei Geschäftspartnern führen.
• Die Entwicklergemeinschaft: Dieses Ereignis dient als Warnung für Softwareentwickler weltweit. Es ist eine schmerzhafte Lektion, die zeigt, wie ein versehentlich in eine Zeile gut gemeinten Codes eingefügtes Geheimnis zu katastrophalen Ergebnissen führen kann.
• Potenziell Patienten und Kunden: Wenn der Vorfall zu einem Angriff auf die Software-Lieferkette wird, der zur Einschleusung von bösartigem Code in Produkte führt, könnten auch die Endbenutzer der Produkte von Novo Nordisk gefährdet sein. Obwohl dies vorerst nur eine Möglichkeit ist, ist es das erschreckendste Szenario für solche Lecks.

Was können Sie tun?

Sowohl einzelne Entwickler als auch Unternehmen sollten aus diesem Vorfall lernen. Was können Sie also tun?

Wenn Sie ein Entwickler sind:

• Niemals Geheimnisse fest im Code verankern: Dies ist die erste und wichtigste Regel. Datenbankpasswörter, API-Schlüssel, Token... nichts davon gehört in Ihren Code. Halten Sie sie getrennt.
• Verwenden Sie Umgebungsvariablen: Der grundlegendste Weg, Geheimnisse von Ihrem Code zu trennen, besteht darin, sie in der Umgebung zu definieren, in der die Anwendung ausgeführt wird. Dies verhindert, dass Geheimnisse zusammen mit dem Code gespeichert werden.
• Scannen Sie Ihren Code: Bevor Sie Ihren Code in ein Repository pushen, verwenden Sie Tools, die versehentlich committete Geheimnisse erkennen. Open-Source-Tools wie `git-secrets` oder die nativen Scan-Funktionen von Plattformen können dabei helfen.
• Prinzip der geringsten Privilegien: Gewähren Sie Ihren Token nur die minimalen Berechtigungen, die für ihre Aufgabe erforderlich sind. Wenn ein Token nur Code lesen muss, geben Sie ihm keine Schreib- oder Löschberechtigungen.

Wenn Sie ein Unternehmen leiten oder in einem Sicherheitsteam sind:

• Betrachten Sie das Geheimnismanagement als Identitätsproblem: Der Kauf eines teuren Geheimnistresors reicht nicht aus. Etablieren Sie strenge Richtlinien für Identitäts- und Zugriffsmanagement (IAM), die regeln, wer (Mensch oder Maschine) wann, von wo und warum auf diesen Tresor zugreift.
• Setzen Sie auf Automatisierung: Richten Sie Systeme ein, die den Code automatisch nach Geheimnissen durchsuchen, bevor Entwickler ihn in ein Repository pushen können (integrieren Sie es in Ihre CI/CD-Pipeline). Wenn ein Geheimnis entdeckt wird, blockieren Sie den Push automatisch.
• Rotieren Sie Geheimnisse regelmäßig: Passwörter und Schlüssel sollten nicht ewig gültig sein. Rotieren Sie Ihre Geheimnisse automatisch in regelmäßigen Abständen. So ist selbst bei einem Leck das Zeitfenster für einen Angreifer sehr begrenzt.
• Schulung, Schulung, Schulung: Schulen Sie Ihre Entwickler kontinuierlich in sicheren Codierungspraktiken und im Geheimnismanagement. Machen Sie Sicherheit zu einem Teil Ihrer Kultur, in der sie in der Verantwortung aller liegt.

Was das Unternehmen sagt

Novo Nordisk hat den Vorfall bestätigt und erklärt, dass sofortige Maßnahmen zur Eindämmung des Lecks ergriffen wurden. In einer ersten Erklärung teilte das Unternehmen mit, dass eine interne Untersuchung eingeleitet wurde und in Zusammenarbeit mit führenden Cybersicherheitsfirmen durchgeführt wird. In der Erklärung hieß es: „Sobald wir von dem Vorfall Kenntnis erlangten, haben wir den Zugriff für den geleakten Token sofort widerrufen und eine umfassende Untersuchung eingeleitet, um den Umfang der Auswirkungen zu bestimmen. Unsere derzeitige Priorität ist es, die vollständige Sicherheit unserer Systeme und Daten zu gewährleisten.“ Das Unternehmen fügte hinzu, dass es weitere Informationen veröffentlichen werde, sobald die Untersuchung fortschreitet.

Quelle

https://www.darkreading.com/cyber-risk/novo-nordisk-breach-exposes-dev-pipeline-risk