Die israelische Application-Security- und DevSecOps-Spezialistin Checkmarx untersucht derzeit einen umfangreichen Supply-Chain-Sicherheitsvorfall, bei dem unternehmensbezogene Daten im Dark Web veröffentlicht wurden. Der Fall zeigt exemplarisch, wie angreifbar selbst Security-Anbieter sind, wenn Angreifer in die Software-Lieferkette eindringen.
GitHub-Datenleck von Checkmarx: Was bisher bekannt ist
Nach aktuellem Stand der internen Ermittlungen stammen die im Dark Web aufgetauchten Informationen vermutlich aus einem GitHub-Repository von Checkmarx. Der Zugriff soll im Rahmen einer Supply-Chain-Attacke erfolgt sein, die auf den 23. März 2026 datiert wird.
Checkmarx betont, dass dieses Repository physisch und logisch von produktiven Kundenumgebungen getrennt ist und dort keine Kundendaten gespeichert werden. Ein digitales Forensik-Team analysiert derzeit Umfang und Inhalt der kompromittierten Daten, um genau zu bestimmen, welche Informationen exfiltriert wurden.
Als Sofortmaßnahme wurde der Zugriff auf das betroffene GitHub-Repository gesperrt, außerdem werden Richtlinien für Zugriffsrechte, Schlüsselverwaltung und Token-Nutzung überprüft und verschärft. Das Unternehmen kündigte an, alle betroffenen Kunden unmittelbar zu informieren, sollte sich herausstellen, dass doch kundenrelevante Informationen in den Leak eingeflossen sind.
LAPSUS$, TeamPCP und die Veröffentlichung im Dark Web
Zusätzliche Aufmerksamkeit erhielt der Vorfall, als der Dienst „Dark Web Informer“ auf der Plattform X (ehemals Twitter) auf einen Eintrag hinwies, der der bekannten Cybergang LAPSUS$ zugeschrieben wird. In diesem Listing wird Checkmarx als eine von drei neuen „Opfern“ der Gruppe geführt.
Laut Beschreibung umfasst das Datenset angeblich Quellcode, eine Mitarbeiterdatenbank, API-Schlüssel sowie Zugangsdaten für MongoDB- und MySQL-Instanzen. Eine unabhängige Bestätigung dieser Angaben liegt derzeit nicht vor, und Checkmarx hat den genauen Umfang der entwendeten Informationen noch nicht offiziell verifiziert – ein übliches Bild in frühen Phasen komplexer Cyberermittlungen.
Parallel dazu hat eine weitere Gruppe, TeamPCP, die Verantwortung für die ursprüngliche Supply-Chain-Kompromittierung übernommen. Ihr wird vorgeworfen, in die Entwicklungs- und Veröffentlichungsprozesse von Checkmarx eingegriffen und so die Basis für den späteren Datenabfluss geschaffen zu haben.
Angriffspfad über Trivy, GitHub Actions und VS-Code-Erweiterungen
Der Vorfall steht im Zusammenhang mit einem früheren Angriff auf Trivy, ein weit verbreitetes Open-Source-Tool zur Sicherheitsanalyse von Containern und Cloud-Infrastrukturen. Angreifer manipulierten dabei zwei GitHub-Actions-Workflow-Dateien sowie zwei über den Open-VSX-Marktplatz verteilte VS-Code-Erweiterungen von Checkmarx.
In die veränderten Komponenten integrierten die Täter einen Credential Stealer, der gezielt Entwicklergeheimnisse wie Zugriffstoken, Passwörter, API-Schlüssel und vertrauliche Umgebungsvariablen abgriff. Solche Werkzeuge ermöglichen es, sich mit legitimen Anmeldedaten seitlich durch unterschiedliche Systeme zu bewegen und weitere Ziele in der Lieferkette zu kompromittieren.
Im weiteren Verlauf wurde offenbar auch ein Docker-Image von Checkmarx KICS, zwei zusätzliche Visual-Studio-Code-Erweiterungen und ein weiterer GitHub-Actions-Workflow manipuliert – jeweils mit vergleichbarer Spionagefunktionalität. Ermittlungen zufolge führte dies zu einem kaskadierenden Effekt, der temporär auch das npm-Paket „Bitwarden CLI“ als nachgelagertes Element der Supply Chain in Mitleidenschaft zog.
Warum Software-Supply-Chain-Angriffe so gefährlich sind
Supply-Chain-Angriffe zielen nicht primär auf die sichtbare, produktive IT einer Organisation, sondern auf Entwicklungs-, Build- und Distributionsprozesse. Gelingt die Kompromittierung, können Angreifer manipulierten Code oder Malware „im Gepäck“ legitimer Updates ausliefern, ohne sofort entdeckt zu werden.
Internationale Vorfälle wie SolarWinds oder die Kompromittierung einzelner npm- und PyPI-Pakete haben bereits gezeigt, dass ein einzelner erfolgreicher Angriff auf die Lieferkette Tausende von Unternehmen gleichzeitig betreffen kann. Besonders kritisch sind Plattformen wie GitHub Actions, weil sie eng mit Deployments, Secrets und Cloud-Infrastrukturen verzahnt sind.
Zentrale Schutzmaßnahmen für DevSecOps-, CI/CD- und Entwicklungsteams
1. Strenges Geheimnis- und Schlüsselmanagement
Unternehmen sollten Secret-Manager einsetzen, Schlüssel und Token regelmäßig rotieren und keine Passwörter oder API-Keys im Quellcode oder in öffentlichen Repositories ablegen. Automatisierte Scans auf hartkodierte Geheimnisse gehören in jeden modernen DevSecOps-Workflow.
2. Härtung von CI/CD-Pipelines und GitHub Actions
Berechtigungen in CI/CD-Systemen müssen konsequent nach dem Prinzip der geringsten Privilegien vergeben werden. Drittanbieter-Actions, Build-Skripte und Container-Images sind vor dem Einsatz zu prüfen, und wo möglich sollten signierte Artefakte und Verifikation der Integrität (z.B. mittels Sigstore oder Cosign) genutzt werden.
3. Transparenz durch SBOM und kontinuierliches Monitoring
Eine Software Bill of Materials (SBOM) schafft Transparenz über alle Abhängigkeiten in Anwendungen. Ergänzend helfen Integritätsprüfungen, Telemetrie und Anomalieerkennung dabei, ungewöhnliche Build-Prozesse, verdächtige Netzwerkverbindungen oder manipulierte Komponenten frühzeitig zu identifizieren.
4. Offenheit, schnelle Meldung und klare Kommunikation
Eine transparente Incident-Response-Strategie mit zügiger Veröffentlichung technischer Details, Indicators of Compromise (IoCs) und konkreten Handlungsempfehlungen reduziert den Gesamtschaden für die betroffene Lieferkette. Gleichzeitige Schulungen von Entwicklungsteams zu Secure Coding und Threat Modeling stärken langfristig die Resilienz.
Der Fall Checkmarx macht deutlich, dass Supply-Chain-Sicherheit ein zentraler Pfeiler moderner Cybersicherheit ist – auch und gerade für Security-Anbieter. Organisationen sollten jetzt ihre DevSecOps- und CI/CD-Prozesse überprüfen, Zugriffsrechte und Secret-Management konsolidieren und die Überwachung ihrer Software-Lieferkette ausbauen. Wer diese Hausaufgaben frühzeitig erledigt, senkt signifikant das Risiko, in der nächsten groß angelegten Supply-Chain-Kampagne selbst zum Einfallstor für Angreifer zu werden.
