Supply-Chain-Angriff auf TanStack: Wie Hacker 170 private GitHub-Repositories von CrowdSec kopierten
Ein realer Vorfall aus der Cybersicherheitsbranche zeigt, wie gefährlich offengelassene Zugangsdaten ausgeschiedener Mitarbeiter sein können – und welche Lehren deutsche Unternehmen daraus ziehen müssen.
Was ist passiert? Der Vorfall im Überblick
Am 18. September gab das französische Cybersicherheitsunternehmen CrowdSec bekannt, dass ein Angreifer am 22. Mai rund 170 private GitHub-Repositories des Unternehmens kopiert hatte. Das Erschreckende: Der Angreifer nutzte dafür das Konto eines Mitarbeiters, der das Unternehmen kurz zuvor verlassen hatte – dessen GitHub-Zugriff war nie deaktiviert worden.
Wie gelang der Angreifer an die Zugangsdaten? Der Laptop des ausgeschiedenen Mitarbeiters war im Mai Opfer eines Supply-Chain-Angriffs auf das beliebte JavaScript-Framework TanStack geworden. Bei diesem Angriff wurden bösartige Versionen der TanStack-npm-Pakete in die offiziellen Repositories eingeschleust. Diese manipulierten Pakete enthielten Schadcode, der systematisch Zugangsdaten und Tokens vom betroffenen System stahl – darunter offenbar auch die GitHub-Credentials des ehemaligen Mitarbeiters.
Dieser Vorfall ist kein isoliertes Ereignis. Er steht exemplarisch für eine wachsende Angriffswelle, die sich gegen die Software-Lieferkette richtet – und die Konsequenzen können auch deutsche Unternehmen direkt treffen.
Technischer Hintergrund: Was ist ein Supply-Chain-Angriff auf npm?
Um das Ausmaß des Vorfalls zu verstehen, lohnt ein kurzer Blick auf die technischen Grundlagen.
Was ist npm und warum ist es ein attraktives Angriffsziel?
npm (Node Package Manager) ist das weltweit größte Software-Paket-Ökosystem für JavaScript und Node.js-Anwendungen. Millionen von Entwicklerinnen und Entwicklern weltweit laden täglich Pakete aus dem npm-Registry herunter und integrieren sie in ihre Projekte. TanStack ist dabei ein weit verbreitetes Framework für die Entwicklung moderner Webanwendungen und Datentabellen.
Genau diese enorme Verbreitung macht npm zu einem hochattraktiven Ziel für Cyberkriminelle. Das Prinzip eines Supply-Chain-Angriffs (Lieferkettenangriff) funktioniert folgendermaßen:
- Ein Angreifer kompromittiert ein populäres, vertrauenswürdiges Paket
- Schädlicher Code wird in eine neue, legitim aussehende Version eingeschleust
- Entwickler installieren die kompromittierte Version – oft automatisiert
- Der Schadcode wird auf den Entwicklermaschinen ausgeführt und stiehlt Daten
Im Fall von TanStack wurden gezielt Credentials und API-Tokens abgegriffen – also die wertvollsten Zugangsdaten, die Entwickler typischerweise auf ihren Systemen gespeichert haben.
Das eigentliche Sicherheitsproblem: Vergessene Zugänge
Der zweite kritische Schwachpunkt in diesem Vorfall ist struktureller Natur: Das Konto des ausgeschiedenen Mitarbeiters war nie deaktiviert worden. Damit konnte der Angreifer, nachdem er die gestohlenen GitHub-Tokens in seinem Besitz hatte, ungehindert auf 170 private Repositories zugreifen und diese kopieren.
Dieses Versäumnis – fehlende oder verzögerte Offboarding-Prozesse – ist erschreckend weit verbreitet, auch in deutschen Unternehmen.
NIS2-Relevanz: Was bedeutet das für deutsche Unternehmen?
Der CrowdSec-Vorfall ist nicht nur technisch interessant – er hat unmittelbare regulatorische Relevanz für Unternehmen in Deutschland, insbesondere seit der Umsetzung der NIS2-Richtlinie (Network and Information Security Directive 2) in nationales Recht.
Betroffene Unternehmen unter NIS2
Seit der Umsetzung der NIS2-Richtlinie in deutsches Recht über das BSIG (BSI-Gesetz) unterliegen zahlreiche Unternehmen aus kritischen und wichtigen Sektoren strengen Cybersicherheitspflichten. Dazu zählen unter anderem:
- Energie, Transport, Gesundheit, Finanzwesen (Wesentliche Einrichtungen)
- Digitale Infrastruktur, IKT-Dienstleister, Post und Kurierdienste (Wichtige Einrichtungen)
Relevante NIS2-Pflichten im Kontext dieses Vorfalls
| Anforderung | NIS2-Bezug | Versäumnis im CrowdSec-Vorfall |
|---|---|---|
| Identitäts- und Zugriffsmanagement | Art. 21 Abs. 2 NIS2-RL | GitHub-Konto des Ex-Mitarbeiters nicht deaktiviert |
| Sicherheit der Lieferkette | Art. 21 Abs. 2 lit. d | Kompromittiertes npm-Paket (TanStack) |
| Incident Detection & Response | Art. 21 Abs. 2 lit. b | Zeitverzögerung bei Erkennung und Meldung |
| Sicherheit beim Personal | Art. 21 Abs. 2 lit. i | Kein strukturiertes Offboarding-Protokoll |
Meldepflichten gegenüber dem BSI
Sollte ein vergleichbarer Vorfall ein NIS2-pflichtiges deutsches Unternehmen treffen, gelten strenge Meldefristen:
- 24 Stunden: Erste Meldung (Frühwarnung) an das BSI nach Kenntniserlangung
- 72 Stunden: Vollständige Incident-Meldung mit Bewertung des Schweregrads
- 1 Monat: Abschlussbericht mit Ursachenanalyse und Gegenmaßnahmen
Verstöße gegen diese Pflichten können zu Bußgeldern von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes führen. Für Geschäftsführer gilt zudem eine persönliche Haftung für die Umsetzung geeigneter Cybersicherheitsmaßnahmen.
5 praktische Schutzmaßnahmen für Ihr Unternehmen
Der CrowdSec-Vorfall lässt sich in der Praxis auf viele deutsche Unternehmen übertragen. Hier sind fünf konkrete Maßnahmen, die Sie jetzt umsetzen sollten:
1. Strukturiertes Offboarding-Protokoll einführen
Jedes Unternehmen benötigt einen verbindlichen Prozess für das Ausscheiden von Mitarbeitern, der explizit alle digitalen Zugänge erfasst:
- Vollständige Inventarisierung aller Accounts (Cloud, GitHub, SaaS, VPN, interne Systeme)
- Sofortige Deaktivierung aller Zugänge am letzten Arbeitstag
- Automatisierte Workflows via IAM-System (Identity and Access Management)
- Regelmäßige Audits zur Überprüfung verwaister Accounts
2. Software-Composition-Analysis (SCA) einsetzen
Um Supply-Chain-Angriffe über kompromittierte Pakete zu erkennen, sollten Sie in Ihrer Entwicklungsumgebung SCA-Tools einsetzen:
- Tools wie OWASP Dependency-Check, Snyk oder Socket.dev scannen npm-Pakete auf bekannte Schwachstellen und Anomalien
- Integration in CI/CD-Pipelines als automatisierter Gate-Check
- Lockfiles (
package-lock.json) nutzen und regelmäßig auf unerwartete Änderungen prüfen - Paket-Updates nie blind einspielen – Changelogs und Diffs prüfen
3. Prinzip der minimalen Rechtevergabe (Least Privilege) konsequent anwenden
Zugriffsrechte sollten immer nur so weit wie nötig vergeben werden:
- Entwickler benötigen selten Zugriff auf alle privaten Repositories
- GitHub Teams und Branch-Protection-Rules gezielt einsetzen
- Regelmäßige Access Reviews durchführen (mindestens halbjährlich)
- Kurzlebige Tokens (Short-lived tokens) statt dauerhafter API-Keys verwenden
4. Multi-Faktor-Authentifizierung (MFA) überall erzwingen
Gestohlene Passwörter und Tokens verlieren ihren Wert, wenn MFA konsequent durchgesetzt wird:
- MFA als organisationsweite Pflicht in GitHub, GitLab und allen Cloud-Diensten
- Hardware-Sicherheitsschlüssel (z. B. YubiKey) für privilegierte Zugänge
- FIDO2/Passkeys als phishing-resistente Alternative zu SMS-OTP
5. Entwickler-Endpunkte als hochwertige Angriffsziele behandeln
Entwicklermaschinen haben oft umfangreiche Zugänge zu sensiblen Systemen und verdienen daher besondere Aufmerksamkeit:
- EDR-Lösungen (Endpoint Detection & Response) auch auf Entwickler-Laptops
- Regelmäßige Schulungen zu Social Engineering und Phishing für Entwicklerteams
- Secrets und Tokens niemals im Klartext auf dem Dateisystem speichern – stattdessen Secret-Manager wie HashiCorp Vault oder die integrierten Lösungen von AWS/Azure/GCP verwenden
- Credential-Scanning in Git-Repositories aktivieren (GitHub Advanced Security, GitGuardian)
Fazit: Lieferkettensicherheit und Zugriffsmanagement sind keine Optionen mehr
Der CrowdSec-Vorfall zeigt eindrücklich, dass selbst Cybersicherheitsunternehmen die Grundprinzipien der IT-Sicherheit vernachlässigen können – mit erheblichen Folgen. Für deutsche Unternehmen, die unter NIS2 fallen, sind Maßnahmen wie strukturiertes Offboarding, Lieferkettensicherheit und konsequentes Zugriffsmanagement keine optionalen Best Practices mehr, sondern gesetzliche Pflichten.
Die gute Nachricht: Viele dieser Maßnahmen lassen sich mit überschaubarem Aufwand umsetzen und bieten sofortigen Schutz. Entscheidend ist, dass sie systematisch und nachvollziehbar implementiert werden – denn genau das werden BSI und andere Aufsichtsbehörden im Ernstfall prüfen.
💡 Tipp für IT-Verantwortliche
Die Umsetzung von NIS2-Anforderungen – insbesondere im Bereich Zugriffsmanagement, Lieferkettensicherheit und Incident Reporting – lässt sich deutlich effizienter gestalten, wenn Sie auf spezialisierte NIS2-Compliance-Software setzen. Solche Plattformen helfen dabei, Maßnahmen zu dokumentieren, Prozesse zu automatisieren, Fristen für Meldepflichten im Blick zu behalten und den Nachweis gegenüber Behörden zu erbringen. Wenn Ihr Unternehmen noch kein strukturiertes Compliance-Management hat, ist jetzt der richtige Zeitpunkt, damit anzufangen.
Quellen: The Hacker News, CrowdSec Security Advisory (September 2026), BSI IT-Grundschutz, ENISA Threat Landscape 2024, NIS2-Richtlinie (EU) 2022/2555, BSIG (BSI-Gesetz)