Vor zehn Jahren galten Plattformen wie GitHub weithin als einfache Entwicklertools – als praktischer Ort zum Speichern von Quellcode. Heute dreht sich in IT-Teams alles um sie. Automatisierungslösungen, CI/CD-Pipelines und Infrastructure as Code (IaC) sind dort gespeichert. Kurz gesagt: Diese Plattformen sind zum Innovationsmotor moderner Unternehmen geworden.
Infolgedessen hat sich die Art und Weise, wie Software entwickelt und bereitgestellt wird, grundlegend verändert. Mit dieser immensen Wertkonzentration geht jedoch eine rasch wachsende Angriffsfläche einher. Ihre DevOps-Umgebungen sind das Tor zur Produktion – und sie sind zu einem bevorzugten Ziel für Cyber-Kriminelle geworden.
Die Aufmerksamkeit der Branche gilt oft nahezu ausschließlich der Datenexfiltration, doch nun nimmt eine noch größere Gefahr Gestalt an: Angreifer zerstören, überschreiben oder löschen wichtige Entwicklerdaten unwiderruflich, um den Betrieb lahmzulegen. Daher kann es verheerende Folgen haben, diese kritischen Daten ungeschützt zu lassen. Wenn ein Angreifer Ihre Repositorys oder Ihren Release-Verlauf löscht, sitzt Ihr gesamtes Entwicklerteam untätig herum, wodurch Produktivitätsverluste in Höhe von Tausenden von Euro pro Stunde entstehen. Für Unternehmen, die in der EMEA-Region tätig sind, steht noch mehr auf dem Spiel: Ein schwerwiegender CI/CD-Angriff kann gleichzeitig die gemäß NIS2 geltenden Meldepflichten für Vorfälle auslösen, die Einhaltung der Rechenschaftspflichten im Rahmen der DSGVO infrage stellen und – bei Finanzdienstleistern – Lücken in der IT-Kontinuität offenlegen, die eigentlich mit DORA gezielt geschlossen werden sollten.
Hier sind die wichtigsten zerstörerischen Angriffsmuster, die wir derzeit in der Praxis beobachten – und warum eine proaktive Wiederherstellungsstrategie der einzige Weg ist, sie zu überstehen.
Angriffsmuster 1: Böswilliges Löschen von Artefakten und Releases
Bei dem jüngsten Angriff auf die Lieferkette von Trivy hat die Hackergruppe TeamPCP nicht nur Daten gestohlen, sondern auch den Softwarebereitstellungszyklus aktiv sabotiert. Durch die Manipulation veränderbarer GitHub-Action-Tags gelangten die Angreifer unbemerkt in CI/CD-Pipelines und stahlen Personal Access Tokens (PATs) mit einer langen Gültigkeitsdauer.
Mit diesen äußerst privilegierten Zugangsdaten löschten sie absichtlich 178 legitime Softwareversionen. Angriffe dieser Art zielen darauf ab, möglichst schwerwiegende Störungen zu verursachen. Unternehmen, die diese gelöschten Artefakte nicht umgehend wiederherstellen können, sind gezwungen, ihre Software-Lieferkette komplett neu aufzubauen. Während sie damit beschäftigt sind, können sie weder an Produkt-Updates noch an kritischen Bug-Fixes arbeiten. Zu den betrieblichen Schäden kommt noch eine Compliance-Dimension hinzu: Gemäß NIS2 müssen schwerwiegende Vorfälle innerhalb von 24 Stunden nach ihrer Feststellung den nationalen Behörden gemeldet werden. Wenn die Artefakte selbst gelöscht wurden, ist es ohne ein unabhängiges, wiederherstellbares Backup nahezu unmöglich, das Ausmaß und die Auswirkungen eines Vorfalls zu ermitteln – doch diese müssen gemeldet werden.
Angriffsmuster 2: Überschreiben des Commit-Verlaufs durch „Force-Push“
Die Versionshistorie wird oft fälschlicherweise als Sicherungskopie betrachtet. Der Python-Angriff „ForceMemo“ von GlassWorm hat genau gezeigt, warum dies ein gefährlicher Trugschluss ist.
Bei dieser Kampagne nutzten die Angreifer Zugangsdaten, die bei einem früheren Angriff auf VS-Code gestohlen worden waren, um sich Zugang zu den GitHub-Accounts von Hunderten von Entwicklern zu verschaffen. Dabei schleusten sie nicht nur Malware in Django-Anwendungen und PyPI-Pakete ein, sondern missbrauchten auch die Option „Force-Push“, um legitime Commits in den Standard-Code-Branches mit ihren eigenen, bösartigen Änderungen zu überschreiben und in die Repositorys übertragen. Ein Force-Push überschreibt faktisch den wahren historischen Änderungsverlauf in einem Repository. Sollte ein Angreifer in Ihre GitHub-Organisation eindringen, kann er Ihren Versionsverlauf vollständig löschen, sodass Ihnen keine native Möglichkeit bleibt, den beschädigten Code auf eine ältere, unbeschädigte Version zurückzusetzen. Abgesehen von den betrieblichen Auswirkungen untergräbt dies unmittelbar den in der DSGVO festgelegten Grundsatz der Integrität und Vertraulichkeit: Unternehmen sind nicht mehr in der Lage nachzuweisen, welche Daten sich in ihrer Umgebung befanden, wann diese geändert wurden oder wer dafür verantwortlich war – genau jenen Nachverfolgbarkeitsnachweis, den Regulierungsbehörden und Datenschutzbehörden im Rahmen der Rechenschaftspflichten gemäß Artikel 5 erwarten.
Angriffsmuster 3: Heimliche Löschung und Beseitigung von Spuren
Manche Löschungen dienen nicht der Sabotage, sondern der Verwischung von Spuren. Bei dem groß angelegten npm-Angriff auf „Axios“ haben mutmaßlich im Auftrag der nordkoreanischen Regierung agierende Hacker den axios-Maintainer-Account geknackt und missbraucht, um eine schädliche Version der äußerst beliebten JavaScript-Bibliothek zu veröffentlichen.
Um die Persistenz aufrechtzuerhalten und unbemerkt zu bleiben, hatten die Hacker einen plattformübergreifende Remote-Access-Trojaner (RAT) entwickelt, der nach der Installation aktiv seine eigenen forensischen Spuren löschte und sich selbst durch saubere Dateien ersetzte. Wenn Angreifer die Spuren ihrer eigenen schädlichen Abhängigkeiten systematisch löschen, sind historische, unveränderliche Backups die einzige Möglichkeit für Sicherheitsteams, vergangene Abhängigkeitsbäume zu überprüfen und genau festzustellen, wann die Umgebung kompromittiert wurde. Im Hinblick auf die Einhaltung der DSGVO ist dies über den unmittelbaren Vorfall hinaus von Bedeutung: Wenn personenbezogene Daten durch Software-Pipelines fließen, müssen Unternehmen nachweisen können, dass ihre Umgebungen zu jedem Zeitpunkt angemessen gesichert waren. Wenn die entsprechenden forensischen Protokolle unwiderbringlich gelöscht werden, ist ein solcher Nachweis nicht mehr möglich.
Angriffsmuster 4: Vollständige Übernahme der Umgebung
Wenn Angreifer Administratorrechte auf höchster Ebene erlangen, wird die Gefahr einer vollständigen Löschung der gesamten Umgebung zur Realität.
Die Anfangsphasen konnten wir bei dem unbefugten Zugriff auf den Cisco-Quellcode beobachten, bei dem die Gruppe TeamPCP gestohlene CI/CD-Zugangsdaten nutzte, um in interne Entwicklungsumgebungen einzudringen. Dasselbe Risiko besteht jedoch auch auf Projektmanagement-Plattformen. Vor Kurzem ermöglichte eine kritische Stored-XSS-Sicherheitslücke in Jira Work Management es weniger privilegierten Benutzern, Super-Admins in eine Falle zu locken und die vollständige Kontrolle über die Organisation zu übernehmen. So könnte ein Angreifer Unternehmensprojekte, Workflow-Konfigurationen und Software-Tracking-Daten im Handumdrehen plattformweit unwiederbringlich löschen. Für Finanzdienstleister ist genau dieses Szenario der Grund, warum die DORA-Anforderungen an die IT-Kontinuität eingeführt wurden: Unternehmen, die ihre DevOps-Infrastruktur nicht von einem getesteten und validierten Wiederherstellungspunkt aus in einen bekanntermaßen einwandfreien Zustand zurückversetzen können, müssen nicht nur mit einem Betriebsausfall, sondern auch mit behördlichen Sanktionen rechnen.
„Ihre DevOps-Pipeline ist der Motor Ihres Unternehmens. Deshalb muss sie unbedingt vor Zerstörung – und vor Compliance-Risiken – geschützt werden.“
Sicherung des Innovationsmotors: Rubrik DevOps Protection
Der Schutz Ihres Quellcodes, Ihrer Projektmanagementdaten und Ihrer Automatisierungspipelines ist zu wichtig, um erst im Nachhinein daran zu denken. Die ausschließliche Nutzung konventioneller Methoden – sei es die native Versionshistorie oder instabile CLI-Skripte – setzt Unternehmen erheblichen Risiken aus. Für Unternehmen in der EMEA-Region, die nicht nur mit Bedrohungen, sondern auch mit Kontrollen durch Behörden rechnen müssen, sind diese Risiken nicht tragbar.
Rubrik bringt denselben automatisierten und cyberresilienten Datenschutz auf Unternehmensniveau, dem Sie bereits Ihre Cloud- und SaaS-Workloads anvertrauen, direkt in Ihre DevOps-Umgebungen.
Logisch isolierte, unveränderliche Backups: Wir schützen Ihr kritisches geistiges Eigentum mit vollständig von Rubrik verwalteten, logisch isolierten und unveränderlichen Backups. Selbst wenn ein Angreifer Ihren GitHub-Administrator-Account vollständig unter seine Kontrolle bringt, kann er Ihre Wiederherstellungsdaten weder verschlüsseln noch verändern oder löschen. Diese Unveränderlichkeit hebelt nicht nur Angriffe aus, sondern gibt gleichzeitig Compliance- und Rechtsabteilungen ein manipulationssicheres Verlaufsprotokoll an die Hand – genau das, was die Rechenschaftspflichten gemäß DSGVO und die Prüfungsverpflichtungen nach NIS2 erfordern.
SLA-gesteuerter automatisierter Schutz: Werfen Sie Ihre komplexen Skripte über Bord. Rubrik erkennt neue Repositorys automatisch und wendet Schutzmaßnahmen in großem Maßstab an, wodurch sichergestellt wird, dass Ihre Daten kontinuierlich und ohne manuellen Eingriff gesichert werden – und erfüllt damit die in NIS2, Artikel 21 definierten Anforderungen an das Backup-Management sowie die gemäß DORA, Artikel 12 geltenden Backup-Richtlinien, ohne zusätzlichen betrieblichen Aufwand zu verursachen.
Schnelle, flexible Wiederherstellung: Flexible Wiederherstellung bei jeder Art von Katastrophe oder Cyber-Szenario. Ganz gleich, ob Sie nach einem böswilligen Force-Push eine detaillierte Wiederherstellung auf Repository-Ebene benötigen oder nach einem plattformweiten Ausfall eine mandanten- und plattformübergreifende Wiederherstellung durchführen müssen – Sie können Ihren Code und Ihre Konfigurationen schnell und präzise genau dort wiederherstellen, wo sie benötigt werden. Diese Geschwindigkeit ist nicht nur für den Betrieb von entscheidender Bedeutung, sondern auch, um die strengen Wiederherstellungsvorgaben des DORA-Rahmenwerks zur IT-Kontinuität zu erfüllen und die von NIS2 geforderten Nachweise innerhalb des 24-Stunden-Meldezeitraums zu erbringen.
Einheitliche Unternehmens-Governance: Sie erhalten eine zentrale Übersicht, in der Ihre Entwicklerdaten zusammen mit Ihren Microsoft 365-, AWS- und lokalen Workloads angezeigt werden – mit der Transparenz und den Nachweismöglichkeiten, die die Rechenschaftspflichten der DSGVO und die Überwachungspflichten gemäß NIS2 erfordern.
Eine strategische Notwendigkeit: Stärken Sie Ihre „Code-to-Cloud“-Pipeline
Warten Sie nicht darauf, dass ein Angreifer das wertvollste geistige Eigentum Ihres Unternehmens mit einem Klick auf „Löschen“ vernichtet. Die Bedrohungslage hat sich weiterentwickelt, und für Unternehmen, die in der EMEA-Region tätig sind, gilt dasselbe für die Compliance-Vorschriften. Ihre Datenschutzstrategie muss mit beiden Entwicklungen Schritt halten.
Sehen Sie sich das On-Demand-Webinar Sichern Sie Ihren Innovationsmotor an und entdecken Sie in einer Demo, wie Rubrik DevOps Protection Ihre GitHub-Umgebung vom Code bis zur Cloud schützen kann. Oder nehmen Sie an unseren praktischen Workshops teil, um zu erfahren, wie Sie Azure DevOps und Ihre GitHub-Infrastruktur mit Rubrik vor Datenverlust, Datenbeschädigung und Cyber-Bedrohungen schützen können.
In diesem Dokument angeführte unveröffentlichte Services oder Funktionen sind derzeit nicht verfügbar. Ob und wann diese allgemein bereitgestellt werden, liegt im Ermessen von Rubrik. Die genannten Services und Funktionen stellen keine Lieferversprechen, Zusagen oder Verpflichtungen von Rubrik dar und können nicht Bestandteil eines Vertrags sein. Kunden sollten ihre Kaufentscheidung auf Services und Funktionen stützen, die derzeit allgemein verfügbar sind.