Source-Code-Breaches: Wenn Angreifer den Security-Vendor vor dem Patch kennen
8 Min. Lesezeit
Trellix, Okta, LastPass – drei Security-Anbieter, drei Source-Code-Breaches, ein Muster. Angreifer kompromittieren gezielt Sicherheitsanbieter, um Schwachstellen in deren Produkten vor den eigenen Kunden zu kennen. Die klassische Vendor-Due-Diligence reicht nicht mehr. Wer heute einen SIEM-, EDR- oder IAM-Anbieter evaluiert, ohne dessen eigene Security-Posture zu prüfen, verschiebt das Risiko – er eliminiert es nicht.
Das Wichtigste in Kürze
- Source-Code ist strategisches Angriffsziel. Wer den Code eines Security-Vendors kennt, kennt ungepatchte Schwachstellen vor der Öffentlichkeit. Trellix (2024), Okta (2023), LastPass (2022) – die Angriffsserie ist kein Zufall.
- Zeitfenster zwischen Breach und Patch ist das Risikofenster. Im Durchschnitt vergehen laut Mandiant M-Trends 2025 10 Tage zwischen Kompromittierung des Vendors und erster Ausnutzung der daraus gewonnenen Schwachstelleninformation. 10 Tage, die kein Patch-Prozess abdeckt.
- Vendor-Due-Diligence braucht neue Kriterien. SOC-2-Zertifikat und ISO-27001-Audit reichen nicht. Fünf konkrete Fragen, die CISOs vor Vertragsabschluss stellen müssen.
- Segmentierung schützt auch wenn der Vendor fällt. Zero-Trust-Architektur und minimale Berechtigungen für Security-Tool-Agenten sind die strukturelle Antwort auf Vendor-seitige Kompromittierungen.
Was ist ein Source-Code-Breach? Bei einem Source-Code-Breach erlangen Angreifer Zugang zum proprietären Quellcode eines Softwareanbieters. Im Kontext von Security-Anbietern ist das besonders kritisch: Der Code enthält Implementierungsdetails zu Erkennungslogik, API-Schnittstellen und potenziellen Schwachstellen, die Angreifern einen zeitlichen Vorteil gegenüber dem Vendor und dessen Kunden verschaffen.
VerwandtDSGVO-Bußgelder 2026: Was Mittelständler jetzt prüfen müssen / EU AI Act August 2026: Hochrisiko-Stichtag und Aufsichts-Vakuum
Das Muster hinter Trellix, Okta und LastPass
Drei Breaches, drei Jahre, drei unterschiedliche Vektoren – aber ein gemeinsames Ergebnis: Angreifer hatten Zugang zu Security-Code bevor die betroffenen Anbieter vollständig verstanden haben, was abgeflossen ist. Das ist kein Zufall und kein operatives Pech.
Der LastPass-Breach (August 2022) begann mit dem kompromittierten Entwickler-Notebook eines Senior-Entwicklers. Angreifer nutzten einen ungepatchten Plex-Media-Server auf dem Privatgerät als Einstiegspunkt. Von dort gelangten sie in die LastPass-Entwicklungsumgebung und extrahierten Source-Code plus Environment-Variablen mit Zugangsdaten zu Cloud-Ressourcen. Ergebnis: Vier Monate später war der Produktions-Backup-Tresor kompromittiert.
Der Okta-Breach (Oktober 2023) traf den Source-Code in einem GitHub-Repository. Angreifer nutzten ein kompromittiertes Service-Account-Token. Was abgeflossen ist, war nicht der primäre Authentifizierungs-Core, sondern Code aus dem Customer-Support-System. Dennoch: Wer den Code kennt, kennt Grenzfälle die Entwickler aus Gründen der Rückwärtskompatibilität nie behoben haben.
Der Trellix-Vorfall (2024) folgt einem ähnlichen Muster. Details sind noch nicht vollständig öffentlich, aber der Angriffsvektor lief über eine kompromittierte CI/CD-Pipeline. Das Muster: nicht der Produktionscode, sondern der Build-Prozess ist das Ziel.
Zahlen zum Kontext
10 Tage
Ø zwischen Vendor-Kompromittierung und erster Ausnutzung (Mandiant M-Trends 2025)
62%
aller Breaches hatten laut Verizon DBIR 2025 einen Software-Supply-Chain-Bezug
18 Monate
Ø von LastPass-Breach bis zur vollständigen Kundenkommunikation über das Ausmaß
Warum klassische Vendor-Due-Diligence versagt
SOC-2-Typ-2-Zertifikat, ISO-27001-Audit, Penetrationstest-Nachweise – das sind die Standardforderungen in Vendor-Evaluierungen. Alle drei prüfen einen Zustand zu einem Zeitpunkt. Keiner von ihnen prüft, ob ein Entwickler-Notebook mit aktivem Angreifer-Zugang heute in der Source-Code-Pipeline sitzt.
ISO-27001 ist ein Management-System-Zertifikat. Es prüft ob Prozesse dokumentiert und gelebt werden – nicht ob ein kompromittierter Service-Account-Token noch aktiv ist. SOC-2 prüft Kontrollen in einem definierten Zeitraum. Eine CI/CD-Pipeline mit schwacher Supply-Chain-Security taucht dort nicht zwingend auf. Penetrationstest-Berichte sind Momentaufnahmen – und sie prüfen typischerweise die externe Angriffsfläche, nicht die interne Entwicklungsinfrastruktur.
Fünf neue Kriterien für Security-Vendor-Evaluierungen
Diese fünf Fragen sollten in jedes Security-Vendor-RFI, bevor ein Vertrag unterschrieben wird. Die Antworten zeigen mehr als jedes Zertifikat.
Wie ist eure CI/CD-Pipeline gegen Supply-Chain-Angriffe abgesichert?
Erwartet: SLSA-Level 3 oder vergleichbar, Signed Commits, Pipeline-as-Code mit Auditlog, kein direkter Produktionsaccess aus Entwickler-Umgebungen.
Wie isoliert ihr Entwickler-Zugänge zu Source-Code von Produktionssystemen?
Erwartet: Getrennte Identitäten für Dev vs. Ops, MFA überall, Privat-Gerät-Policy für Senior-Entwickler mit Code-Zugang, JIT-Zugang für privilegierte CI-Operationen.
Wie lange dauert es von Breach-Erkennung bis zur Kunden-Erstinformation?
Erwartet: Contractual SLA für Sicherheitsvorfälle, idealerweise 72 Stunden. LastPass hat 4 Monate für die vollständige Disclosure gebraucht. Das ist kein akzeptabler Standard.
Welche Berechtigungen braucht euer Agent/Sensor in unserer Umgebung?
Erwartet: Least-Privilege dokumentiert, kein „lokaler Admin“ als Default, Network-Segmentierung für Sensor-Traffic, Signing für alle Update-Pakete.
Habt ihr ein Bug-Bounty-Programm und wie lange ist die Durchschnittliche Patch-Zeit?
Erwartet: Öffentliches Bug-Bounty-Programm, Ø Patch-Zeit unter 30 Tage für Critical-CVEs, CVSSv3-Scores bei eigenen Disclosures. Anbieter ohne öffentliche Disclosure-Historie sind kein gutes Zeichen.
Pros und Cons: Zero-Trust-Architektur für Security-Tool-Agenten
Für strikte Segmentierung spricht
- Blast-Radius-Begrenzung wenn Vendor-Agent kompromittiert
- Erzwingt Minimal-Berechtigung statt „muss alles sehen“
- Lateral-Movement aus kompromittiertem Agent blockiert
- Detektiert unerwartete Kommunikationsmuster früher
Dagegen spricht
- Einige Security-Tools fordern breite Berechtigungen für Wirksamkeit
- Segmentierung erzeugt Konfigurations-Overhead
- Blinde Flecken wenn Sensor keinen vollständigen Netz-Überblick hat
- Vendor-Support-Prozesse werden komplexer
Häufige Fragen
Was unterscheidet einen Source-Code-Breach von einem klassischen Datenbreach?
Bei einem klassischen Datenbreach fließen Kundendaten, Zugangsdaten oder Finanzdaten ab. Bei einem Source-Code-Breach fließt proprietärer Code ab. Der Unterschied: Gestohlene Daten schaden direkt den betroffenen Personen. Gestohlener Source-Code verschafft Angreifern strukturelles Vorwissen über Schwachstellen, das sie gegen alle Kunden des Vendors einsetzen können – mit Zeitvorteil vor dem Patch.
Wie reagiere ich als CISO wenn mein Security-Vendor einen Source-Code-Breach meldet?
Erstens: Kontakt mit dem Vendor aufnehmen und den Scope des Breaches klären (welcher Code, welche Zeitperiode, welche Systeme). Zweitens: Berechtigungen des Vendor-Agenten in der eigenen Umgebung temporär minimieren. Drittens: Logs für ungewöhnliche Aktivitäten des Vendor-Agenten in den letzten 30 Tagen prüfen. Viertens: Abwägen ob eine temporäre Deaktivierung des Tools risikoärmer ist als der laufende Betrieb.
Was ist SLSA und warum ist es bei Vendor-Evaluierungen relevant?
SLSA (Supply-chain Levels for Software Artifacts) ist ein Framework von Google für die Sicherheit von Software-Build-Prozessen. Level 3 bedeutet: Build-Prozess ist nachvollziehbar reproduzierbar, Artefakte sind signiert, Build-Umgebung ist isoliert. Security-Anbieter die SLSA-Level 3 erreichen haben eine strukturell härtere Build-Pipeline als solche ohne SLSA-Dokumentation.
Bin ich als CISO haftbar wenn mein Security-Vendor kompromittiert wird?
Die Frage der Haftung hängt von der Vertragsgestaltung und der regulatorischen Einordnung ab. NIS2 verlangt von KRITIS-Betreibern eine Supply-Chain-Risikoanalyse – wer keinen Sicherheits-Due-Diligence-Prozess für Vendor-Auswahl dokumentiert hat, trägt Mitverantwortung. Die Aufsichtsbehörden werden bei KRITIS-Incidents zunehmend prüfen ob der Beschaffer den Vendor ausreichend evaluiert hat.
Welche Branchen sind besonders exponiert?
Alle Branchen die Security-Vendoren mit tiefem Systemzugang einsetzen: kritische Infrastruktur, Finanzdienstleister, Gesundheitswesen, Rüstung und Luft- und Raumfahrt. Besonders kritisch: Organisationen die Security-Tools direkt auf OT-Netzwerk-Knotenpunkten betreiben ohne Segmentierung zwischen IT- und OT-Agenten.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Polina Zimmerman (px:3779082)
