Lieferanten & Softwareentwicklung · SUP-05
Entwicklungsumgebung kompromittiert
Es gibt Anzeichen, dass ein Entwicklerrechner, ein Build-Server oder eine Pipeline von Unbefugten genutzt oder verändert wurde. Über diese Systeme laufen Code, Zugangsdaten und Releases. Ein Eingriff kann damit bis in die Software reichen, die Kunden installieren.
Erste 15 Minuten
Sofortmaßnahmen.
- Commits oder Änderungen, die niemand im Team gemacht hat
- Pipeline-Konfiguration ohne Freigabe verändert
- Unbekannte SSH-Schlüssel oder Tokens im Konto
- Build-Ergebnis weicht vom geprüften Quellcode ab
- 01
Keine Releases, Deployments oder Updates mehr auslösen, bis die IT die Umgebung geprüft hat.
- 02
Einen betroffenen Rechner vom Netzwerk trennen, aber nicht ausschalten und nicht neu aufsetzen.
- 03
Von dieser Umgebung aus keine Passwörter mehr ändern und keine weiteren Anmeldungen durchführen.
- 04
Auffällige Commits, Konfigurationsänderungen und Schlüssel notieren, ohne sie zu entfernen.
- 05
Sofort melden. Der Verdacht genügt.
Melden
Wen informieren, und wie.
Wen
IT-Verantwortliche oder IT-Dienstleister und die Leitung der Softwareentwicklung sofort. Bei möglicher Auslieferung an Kunden zusätzlich die Geschäftsführung.
Wie
Telefonisch oder über den internen Meldeweg aus dem Kontaktblatt, nicht über Konten oder Rechner aus der betroffenen Umgebung.
Was bereithalten
- Welche Rechner, Server oder Pipelines betroffen sind
- Welche Auffälligkeit wann bemerkt wurde
- Welche Zugangsdaten in der Umgebung verfügbar waren
- Welche Releases seit dem möglichen Beginn erstellt wurden
- Ob Software oder Updates an Kunden ausgeliefert wurden
Häufige Fehler
Nicht tun.
-
Verdächtige Commits zurücksetzen oder Schlüssel löschen, bevor die IT den Stand gesichert hat.
-
Den Rechner neu aufsetzen, um schnell weiterarbeiten zu können.
-
Ein dringendes Release trotzdem freigeben.
-
Den Verdacht nur im Team besprechen und die Meldung aufschieben.
Nach der Meldung
Was danach passiert.
Ab hier übernehmen IT, Datenschutz und Geschäftsführung. Für dich ist der Vorfall mit der Meldung abgeschlossen.
-
Die IT stoppt betroffene Pipelines, sichert Spuren und klärt, seit wann die Umgebung verändert wurde.
-
Alle Zugangsdaten, Schlüssel und Signaturzertifikate der Umgebung werden gewechselt.
-
Releases seit dem möglichen Beginn werden mit dem geprüften Quellcode abgeglichen. Über die Information der Kunden entscheidet die Geschäftsführung.
-
Wesentliche und wichtige Einrichtungen nach NISG 2026 prüfen, ob ein erheblicher Cybersicherheitsvorfall vorliegt, der nach § 34 zu melden ist.
Zum Aushängen
Dieses Playbook als PDF.
Eine A4-Seite, gebrandet und druckbar, ohne Anmeldung. Für die Ablage im Team, das Onboarding oder den Aushang neben dem Arbeitsplatz.
PDF · 1 Seite · ohne Anmeldung
Hintergrund
Die Entwicklungsumgebung hält viele Schlüssel
Auf Entwicklerrechnern und in Build-Pipelines liegen Zugänge, die anderswo streng getrennt sind: Schreibrechte auf Repositories, Schlüssel für Cloud-Konten, Deployment-Rechte für Produktivsysteme und häufig das Zertifikat, mit dem die eigene Software signiert wird. Wer diese Umgebung kontrolliert, kann Code verändern und ihn anschließend über den regulären, vertrauenswürdigen Weg ausliefern.
Deshalb reicht ein solcher Vorfall weiter als ein kompromittierter Büro-PC. Er betrifft potenziell jede Installation der eigenen Software beim Kunden.
Releases anhalten, bevor die Ursache klar ist
Der Termindruck in der Entwicklung erzeugt den Reflex, das anstehende Release noch auszuliefern und den Verdacht danach zu prüfen. Genau das kann aus einem internen Vorfall einen Vorfall bei jedem Kunden machen.
Ein angehaltenes Release kostet einige Tage. Ein manipuliertes Update erreicht dagegen alle, die es installieren, und lässt sich nicht zurückholen. Diese Abwägung trifft die Geschäftsführung, auf Grundlage der Meldung.
Der Rechner bleibt, wie er ist
Ein kompromittierter Rechner enthält die Spuren, aus denen sich rekonstruieren lässt, wie der Angreifer hineinkam, wie lange er da war und was er verändert hat. Wer ihn neu aufsetzt, verliert diese Antworten. Ohne sie lässt sich nicht sagen, welche Releases betroffen sind.
Die Trennung vom Netzwerk stoppt die weitere Ausbreitung und erhält diese Spuren. Alles Weitere entscheidet die IT.
Erstgespräch
Sicherheit braucht ein Gegenüber, kein Tool.
Im 30-Minuten-Erstgespräch klären wir, wo dein Unternehmen steht und welcher nächste Schritt sinnvoll ist.