Lieferanten & Softwareentwicklung · SUP-02
Verdächtige Software oder Abhängigkeit
Ein Programm, eine Bibliothek, ein Paket oder eine Erweiterung verhält sich anders als erwartet oder stammt aus einer zweifelhaften Quelle. Der Verdacht entsteht oft beim Installieren, beim Build oder durch eine Sicherheitswarnung zu einer Komponente, die bereits im Einsatz ist.
Erste 15 Minuten
Sofortmaßnahmen.
- Paket mit Tippfehler oder ungewohnter Schreibweise installiert
- Neue Version einer Bibliothek baut unerwartete Verbindungen auf
- Sicherheitswarnung zu einer genutzten Abhängigkeit
- Tool oder Erweiterung aus inoffizieller Quelle installiert
- 01
Nicht weiter bauen, nicht ausrollen und nichts veröffentlichen, was die verdächtige Komponente enthält.
- 02
Name, Version und Herkunft der Komponente notieren, ebenso wann und auf welchem System sie installiert wurde.
- 03
Den aktuellen Stand sichern: Lockfile, Build-Protokoll und Warnmeldung nicht verändern und nicht löschen.
- 04
Zugangsdaten, die auf dem betroffenen Rechner oder in der Pipeline verfügbar waren, nicht mehr verwenden, bis die IT entschieden hat.
- 05
Sofort melden, auch wenn sich die Warnung später als Fehlalarm herausstellen könnte.
Melden
Wen informieren, und wie.
Wen
IT-Verantwortliche oder IT-Dienstleister und die Leitung der Softwareentwicklung. Wurde bereits an Kunden ausgeliefert, zusätzlich die Geschäftsführung.
Wie
Über den internen Meldeweg aus dem Kontaktblatt. Komponente und Fundstelle genau benennen, keine Installationsdatei per Mail weiterleiten.
Was bereithalten
- Name, Version und Bezugsquelle der Komponente
- Auf welchen Rechnern, Servern oder Pipelines sie läuft
- Seit wann sie im Einsatz ist
- Ob sie in ausgelieferte Software oder Updates eingeflossen ist
- Was konkret auffällig war
Häufige Fehler
Nicht tun.
-
Die Komponente still entfernen oder ersetzen und den Fall damit für erledigt halten.
-
Den Build noch schnell abschließen, weil ein Termin ansteht.
-
Die verdächtige Datei an Kolleginnen und Kollegen schicken, damit sie sich das ansehen.
-
Die Datei bei einem Online-Virenscanner hochladen, wenn sie internen Code oder Daten enthalten könnte.
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 prüft, wo die Komponente überall eingesetzt wird, und isoliert betroffene Systeme und Pipelines.
-
Zugangsdaten und Schlüssel, die der Komponente zugänglich waren, werden gewechselt.
-
Ist die Komponente in ausgelieferte Software gelangt, entscheidet die Geschäftsführung über die Information der Kunden.
-
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
Der Angriff kommt über den regulären Installationsweg
Paketmanager, Erweiterungs-Marktplätze und Update-Mechanismen sind darauf gebaut, fremden Code schnell und ohne Rückfrage in die eigene Umgebung zu holen. Genau das nutzen Angreifer. Sie veröffentlichen Pakete, deren Namen einem bekannten Paket zum Verwechseln ähneln, übernehmen das Konto eines Maintainers oder schleusen Schadcode in eine neue Version einer verbreiteten Bibliothek ein.
Die Installation selbst löst dabei keinen Alarm aus. Schadcode in einer Abhängigkeit läuft mit denselben Rechten wie die Entwicklungsumgebung oder die Build-Pipeline, und dort liegen häufig Zugangsdaten zu Repositories, Cloud-Konten und Produktivsystemen.
Die Auslieferung entscheidet über die Tragweite
Solange eine verdächtige Komponente nur auf einem Entwicklerrechner liegt, betrifft der Vorfall das eigene Haus. Ist sie in einen Build, ein Release oder ein Update eingeflossen, das an Kunden gegangen ist, wird daraus möglicherweise ein Vorfall in der Lieferkette dieser Kunden.
Deshalb gehört die Auskunft, ob und wohin ausgeliefert wurde, an den Anfang der Meldung. Kunden, die selbst unter das NISG 2026 fallen, müssen nach § 32 die Sicherheit ihrer Lieferkette steuern. Ihr Softwarelieferant gehört dazu, und sie werden wissen wollen, seit wann der Vorfall bekannt war und was seither unternommen wurde.
Stilles Entfernen löscht die Spur
Der naheliegende Reflex ist, die Komponente zu deinstallieren, eine saubere Version einzutragen und weiterzuarbeiten. Damit verschwindet genau die Information, die die IT braucht: welche Version wann installiert war, was sie ausgeführt hat und welche Daten sie erreichen konnte.
Lockfiles, Build-Protokolle und die ursprüngliche Warnmeldung sind in diesem Fall die Belege. Sie bleiben unverändert, bis die IT den Stand gesichert hat.
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.