Wer einen Online-Shop wartet, denkt bei Sicherheit zuerst an die bekannte Lücke: Ein CVE wird veröffentlicht, ein Patch erscheint, die Wartung spielt ihn ein. Die Shai-Hulud-Kampagnen haben diese Reihenfolge verschoben. Nicht die ungepatchte Schwachstelle im installierten Shopsystem war das Einfallstor, sondern die harmlos aussehende Patch-Version einer Abhängigkeit -- ausgeliefert über die offiziellen Registries, korrekt versioniert, unauffällig. Die Mini-Shai-Hulud-Kampagne umfasste über alle Wellen hinweg 1.055 kompromittierte Paket-Versionen über 502 Pakete und lief über npm, PyPI und Composer hinweg (Infosecurity Magazine) -- also genau die Ökosysteme, aus denen sich Shop-Themes, Build-Pipelines und Erweiterungen speisen. Der Schadcode lief zur Installationszeit und griff CI/CD-Secrets ab: Deploy-Zugänge, Zahlungs-API-Keys, Registry-Token. Dieser Beitrag behandelt Provenienz statt Panik -- also die Frage, woher Code kommt und unter welchen Bedingungen er in den Build darf. Anders als das CVE-Management für Online-Shops, das bekannte Schwachstellen im Bestand priorisiert, und anders als das Plugin-Audit gegen Ballast und Ladezeit geht es hier um bewusst bösartigen Code in der Lieferkette: um Pakete, für die es keine Schwachstellenmeldung gibt, weil sie keine Lücke hatten -- sie waren von Anfang an die Waffe.
Wenn das Update selbst zum Einfallstor wird
Die klassische Wartungslogik unterstellt, dass Aktualität und Sicherheit dasselbe sind: Je schneller ein Update eingespielt wird, desto kleiner das Zeitfenster für Angreifer. Für bekannte Schwachstellen gilt das unverändert. Das Bundesamt für Sicherheit in der Informationstechnik zählt im aktuellen Berichtszeitraum durchschnittlich 119 neue Software-Schwachstellen pro Tag -- rund 24 Prozent mehr als im Vorjahreszeitraum (BSI, Die Lage der IT-Sicherheit in Deutschland 2025). Wer diesen Strom ignoriert, sammelt Angriffsfläche an. Die Lieferkette dreht die Annahme allerdings an einer Stelle um: Wenn die bösartige Version selbst über den offiziellen Kanal kommt, beschleunigt zügiges Aktualisieren nicht den Schutz, sondern die Kompromittierung. Das Update ist dann nicht die Reaktion auf den Angriff, sondern sein Transportmittel.
Dass es sich dabei nicht um ein Randthema handelt, zeigt die aktuelle OWASP-Rangliste. Software Supply Chain Failures sind als eigene Kategorie auf Platz 3 der OWASP Top 10 eingezogen; in der begleitenden Community-Umfrage setzten 50 Prozent der Befragten die Kategorie sogar auf Platz 1 (OWASP Top 10:2025). Mit einer durchschnittlichen Vorfallrate von 5,72 Prozent steht sie an der Spitze aller Kategorien -- und zugleich sind ihr lediglich 11 CVEs zugeordnet (OWASP Top 10:2025). Diese Lücke zwischen hoher Vorfallrate und nahezu fehlender CVE-Abdeckung ist der Kern des Problems: Die Standardwerkzeuge der Schwachstellenverwaltung sehen diese Angriffe strukturell kaum.
Bei der Mini-Shai-Hulud-Kampagne wurde den kompromittierten Paketen folgerichtig kein einziger CVE-, GHSA- oder OSV-Eintrag zugewiesen (Cloud Security Alliance). Ein Wartungsprozess, der ausschließlich auf Schwachstellenmeldungen reagiert, hätte hier keinen Alarm ausgelöst. Die Pakete waren nicht verwundbar -- sie waren bösartig. Das ist der Unterschied, an dem sich die Wartungspraxis neu ausrichten muss: Die Frage lautet nicht mehr nur 'Ist eine Lücke bekannt?', sondern zusätzlich 'Woher kommt dieser Code, und warum vertrauen wir ihm?'.
Kein CVE, keine Meldung, kein Alarm
Wie Mini Shai-Hulud durch drei Ökosysteme lief
Der Ursprung liegt im September 2025. Die Cybersecurity and Infrastructure Security Agency veröffentlichte eine Warnung zu einem selbstverbreitenden Wurm im npm-Ökosystem, der über 500 Pakete kompromittiert hatte (CISA). Der Schadcode durchsuchte die Umgebung nach Zugangsdaten und zielte gezielt auf GitHub-Zugriffstoken sowie API-Schlüssel für Cloud-Dienste (CISA). Damit war das Muster gesetzt: Nicht der Shop war das Ziel, sondern die Werkbank, auf der er gebaut und ausgerollt wird.
Der eigentliche Bruch kam im April 2026. In einem Fenster von 48 Stunden am 29. und 30. April 2026 kompromittierte ein Akteur Pakete in npm, PyPI und Packagist/Composer gleichzeitig -- die erste Kampagne, die drei Paket-Ökosysteme in einer Operation bediente (Cloud Security Alliance). Die betroffenen Pakete kamen zusammen auf über 930.000 wöchentliche Downloads (Cloud Security Alliance). Der Schadcode, ein 11,7 MB großer obfuskierter Credential-Stealer, durchsuchte 134 verschiedene Dateipfade nach Zugangsdaten und legte die Beute in rund 1.800 Repositories ab (Cloud Security Alliance).
| Welle und Zeitpunkt | Umfang | Besonderheit |
|---|---|---|
| Shai-Hulud (September 2025) | über 500 Pakete (CISA) | selbstverbreitender Wurm, Ziel: GitHub-Token und Cloud-Schlüssel |
| Shai-Hulud 2.0 (Dezember 2025) | Hunderte Pakete (Microsoft Security) | Wechsel von postinstall auf preinstall |
| Mini Shai-Hulud (11. Mai 2026) | 373 Versionen / 169 Pakete (Unit 42) | erstmals npm und PyPI in einer koordinierten Operation |
| AntV-Welle (19. Mai 2026) | 639 Versionen / 323 Pakete (Infosecurity Magazine) | gesamtes Veröffentlichungsfenster rund eine Stunde |
| Gesamtkampagne | 1.055 Versionen / 502 Pakete (Infosecurity Magazine) | npm, PyPI und Composer zusammen |
Technisch entscheidend ist der Zeitpunkt der Ausführung. Der Schadcode lief im preinstall-Schritt und damit, bevor Tests oder Sicherheitsprüfungen überhaupt zum Zug kamen (Microsoft Security). Er ermittelte den Prozess des CI-Runners und las dessen Arbeitsspeicher aus -- wodurch die Maskierung von Secrets in den Build-Logs wirkungslos blieb, weil die Werte direkt aus dem Prozessspeicher stammten (Microsoft Security). Die Aufräumarbeiten nach einer einzigen Welle geben eine Vorstellung von der Reichweite: 640 bösartige Pakete wurden entfernt und 61.274 npm-Zugriffstoken mit Schreibrechten für ungültig erklärt (Microsoft Security). Auffällig ist die Auswahl: Der Schadcode filterte Automation-Token gezielt nach dem Merkmal, die Zwei-Faktor-Prüfung umgehen zu können (Cloud Security Alliance).
Der Angriff kommt weitgehend ohne Angreifer aus
Warum Shops mitten in der Lieferkette stehen
Ein moderner Online-Shop ist kein Monolith, sondern ein Bauwerk aus fremden Teilen. Der Shop-Kern und seine Erweiterungen kommen über Composer, der Storefront- und Theme-Build zieht Hunderte Pakete über npm, Bild- und Datenpipelines greifen auf PyPI zu. Genau diese drei Ökosysteme hat Mini Shai-Hulud bedient. OWASP weist ausdrücklich darauf hin, dass dabei nicht nur die direkten, sondern auch die transitiven Abhängigkeiten zu verfolgen sind (OWASP Top 10:2025) -- also die Pakete, die Ihre Pakete mitbringen und die in keiner Auswahlentscheidung je vorkamen. Wer eine Shopware-Wartung betreibt, verwaltet damit faktisch eine Lieferkette, nicht nur eine Installation.
Composer: Kern und Erweiterungen
Shop-System, Plugins und Bibliotheken kommen als Composer-Pakete. Ein einziges kompromittiertes Paket in dieser Kette läuft mit den Rechten des Deploy-Prozesses.
npm: Storefront und Theme-Build
Themes, Build-Werkzeuge und Frontend-Bibliotheken bringen die größte Zahl transitiver Abhängigkeiten mit -- und sind das bevorzugte Ziel der bisherigen Wellen.
CI/CD: Zugänge und Secrets
Die Pipeline hält, was der Angriff sucht: Deploy-Zugänge, Zahlungs-API-Keys, Registry-Token. Sie ist der eigentliche Tresor, nicht der Shop selbst.
Die Reichweite entsteht durch Popularität, nicht durch Nachlässigkeit. Bei der TanStack-Welle waren im Kompromittierungsfenster rund 520 Millionen kumulierte Downloads betroffen; allein eines der Pakete kommt auf über 12,7 Millionen wöchentliche Downloads (Unit 42). Die im April getroffenen SAP-CAP-Pakete summierten sich auf etwa 572.000 wöchentliche Downloads, ein weiteres Paket auf rund 360.000 (Cloud Security Alliance). Anfang Juni 2026 traf es zusätzlich 32 Pakete eines Enterprise-Namensraums mit etwa 80.000 wöchentlichen Downloads (Unit 42). Und im April 2026 warnte die Cybersecurity and Infrastructure Security Agency vor einer Kompromittierung des weit verbreiteten HTTP-Clients axios, über die ein Fernzugriffstrojaner ausgeliefert wurde (CISA). Es trifft also nicht die exotische Abhängigkeit vom Rand, sondern die Pakete, die in praktisch jedem Build stecken.
Lockfiles verbindlich machen
Die wirksamste Einzelmaßnahme ist zugleich die unspektakulärste: Der Build darf nicht selbst entscheiden, welche Version er zieht. Version-Ranges wie ^1.2.3 sind eine stehende Einladung -- sie erlauben jeder frisch veröffentlichten Patch-Version, unbemerkt in den nächsten Build zu rutschen. Die Cloud Security Alliance hält fest, dass das Pinnen von Abhängigkeiten auf kryptografische Hashes, wie es die Integritätsfelder in package-lock.json unterstützen, die Exposition gegenüber bösartigen Patch-Versionssprüngen beseitigt (Cloud Security Alliance). Microsoft Security empfiehlt entsprechend, bekannte gute Versionen zu pinnen und automatische Abhängigkeits-Upgrades zu vermeiden (Microsoft Security).
Damit das Lockfile verbindlich ist, muss die Pipeline den passenden Befehl verwenden. Unit 42 formuliert es unmissverständlich: package-lock.json einsetzen und in CI/CD npm ci statt npm install verwenden, damit während des Builds keine automatischen Aktualisierungen stattfinden (Unit 42). Für Composer gilt dieselbe Logik: composer install liest das Lockfile, composer update löst die Ranges neu auf und gehört deshalb auf den Entwicklungsrechner, nicht in den Deploy.
# Build gegen das Lockfile, nicht gegen die Version-Ranges
npm ci --ignore-scripts # installiert exakt package-lock.json
composer install --no-scripts \
--no-plugins \
--prefer-dist # installiert exakt composer.lock
# In der Pipeline nicht erlaubt: ermittelt Ranges neu und
# zieht damit jede frische Patch-Version ohne Kontrolle herein
# npm install
# composer update-
package-lock.jsonundcomposer.lockgehören versioniert ins Repository -- ein Lockfile im .gitignore ist ein blinder Build. - In CI/CD ausschließlich
npm ciundcomposer installverwenden;npm installundcomposer updatebleiben der bewussten Aktualisierung vorbehalten. - Version-Ranges für sicherheitsrelevante und zahlungsnahe Pakete auf exakte Versionen zurückbauen.
- Aktualisierungen als eigenen, prüfbaren Commit führen -- nicht als Nebenwirkung eines Deploys.
- Integritäts-Hashes im Lockfile nicht durch Werkzeuge überschreiben lassen, die sie neu berechnen, ohne die Quelle zu prüfen.
Install-Skripte im Build abschalten
Ein Paket zu installieren bedeutet in npm und Composer standardmäßig, fremden Code auszuführen -- vor jeder Prüfung. Genau hier setzt die Kampagne an: Der Schadcode lief im preinstall-Schritt und damit, bevor Tests oder Sicherheitsprüfungen greifen konnten (Microsoft Security). OWASP beschreibt für die Ursprungswelle dasselbe Muster: Der Angriff nutzte Install-Skripte zur Exfiltration und die erbeuteten npm-Token, um automatisch weitere bösartige Versionen zu veröffentlichen (OWASP Top 10:2025). Der Payload musste den Shop gar nicht erst erreichen -- er hatte sein Ziel bereits auf dem Build-Runner erreicht.
Die Gegenmaßnahme ist eine einzelne Konfigurationszeile. Die Cybersecurity and Infrastructure Security Agency empfiehlt, ignore-scripts=true in die .npmrc aufzunehmen, um zu verhindern, dass bei der Installation automatisch potenziell bösartige Skripte ausgeführt werden (CISA). Microsoft Security nennt dieselbe Maßnahme in Form von npm install --ignore-scripts (Microsoft Security). Für Composer entsprechen dem die Schalter --no-scripts und --no-plugins.
; Install-Skripte per Vorgabe nicht starten
ignore-scripts=true
; Nur Versionen zulassen, die mindestens sieben Tage
; offen sichtbar und damit kontrolliert waren (CISA-Empfehlung)
min-release-age=7
; Bezug nur noch aus dem eigenen Registry-Spiegel
registry=https://registry.intern.example.com/Ausnahmen bewusst und einzeln freigeben
Ein Cooldown-Fenster vor frischen Versionen
Bösartige Paketversionen haben eine kurze Halbwertszeit: Sie werden entdeckt, gemeldet und zurückgezogen. In der AntV-Welle war das gesamte Veröffentlichungsfenster nach rund einer Stunde geschlossen (Infosecurity Magazine). Wer eine frische Version nicht sofort übernimmt, lässt genau diese Entdeckungsphase für sich arbeiten -- ohne selbst etwas prüfen zu müssen. Die Cybersecurity and Infrastructure Security Agency empfiehlt dafür min-release-age=7 in der .npmrc, damit ausschließlich Pakete installiert werden, die mindestens sieben Tage öffentlich einsehbar und damit prüfbar waren (CISA). Unit 42 setzt die Schwelle pragmatischer an und rät, über eine private Registry jede Version zu blockieren, die in den letzten 24 bis 72 Stunden veröffentlicht wurde (Unit 42).
| Cooldown-Fenster | Was es abfängt | Einordnung |
|---|---|---|
| Keines | nichts | jede frische Version geht ungeprüft in den nächsten Build |
| 24 bis 72 Stunden | Wellen, die schnell auffallen und zurückgezogen werden | pragmatischer Kompromiss, Empfehlung von Unit 42 |
7 Tage (min-release-age=7) | Versionen ohne öffentliche Prüfphase | Empfehlung der CISA für npm |
| Manuelle Freigabe | alles, was nicht bewusst übernommen wurde | sinnvoll für zahlungs- und checkout-nahe Pakete |
Ein Cooldown ist kein Verzicht auf Sicherheitsupdates. Er trennt zwei Dinge, die in der Praxis oft vermischt werden: das dringende Schließen einer bekannten Lücke und das routinemäßige Mitziehen jeder neuen Version. Für den ersten Fall gibt es das bewusste, dokumentierte Vorziehen -- für den zweiten gibt es keinen Grund zur Eile.
Ein eigener Registry-Spiegel statt Direktbezug
Ein Cooldown-Fenster, eine Sperrliste oder eine Freigabe lassen sich nur dort durchsetzen, wo der Bezug tatsächlich stattfindet. Unit 42 formuliert die Konsequenz deutlich: Entwicklerrechner und CI-Runner sollten nicht direkt mit der öffentlichen Registry sprechen, sondern sämtlichen Verkehr über eine private Registry leiten (Unit 42). Für Composer ist das Gegenstück ein eigenes Repository, in dem die zugelassenen Pakete liegen und der öffentliche Standardindex bewusst eingeschränkt wird. Der Spiegel ist dabei nicht nur eine Kontrollstelle, sondern auch ein Gedächtnis: Er behält, was Sie einmal bezogen haben, selbst wenn ein Paket später aus der öffentlichen Registry verschwindet.
Ein Ort für Regeln
Cooldown, Sperrlisten und Freigaben greifen an einer Stelle, statt in jedem Repository und auf jedem Rechner einzeln konfiguriert zu werden.
Bezug bleibt reproduzierbar
Zurückgezogene oder gelöschte Pakete brechen den Build nicht, weil der Spiegel die bereits geprüfte Version weiterhin vorhält.
Sichtbarkeit, was hereinkommt
Der Spiegel protokolliert, welche Pakete und Versionen tatsächlich bezogen wurden -- die Grundlage jeder späteren Betroffenheitsanalyse.
Kleinere Angriffsfläche im Netz
Build-Runner brauchen keinen offenen Weg ins Internet, sondern nur den Weg zum Spiegel -- ungewöhnlicher Verkehr fällt dadurch eher auf.
SBOM als Inventar für die Betroffenheitsfrage
Wenn eine Welle bekannt wird, zählt eine einzige Frage: Sind wir betroffen? Ohne Inventar wird daraus eine manuelle Suche über Repositories, Lockfiles und Build-Server -- unter Zeitdruck, meist am Wochenende. Eine Software-Stückliste (SBOM) beantwortet die Frage in Minuten statt in Stunden. Unit 42 empfiehlt, für jedes Produktions-Release automatisch eine SBOM zu erzeugen, damit sich die Betroffenheit sofort analysieren lässt, sobald eine neue Kompromittierung veröffentlicht wird (Unit 42). Die Cybersecurity and Infrastructure Security Agency verlangt in ihren Vorgaben maschinenlesbare Formate, konkret SPDX oder CycloneDX (CISA), und Microsoft Security nennt die SBOM-Erzeugung als Bestandteil der Code-Prüfung (Microsoft Security).
- Für jedes Release eine SBOM erzeugen und aufbewahren -- nicht nur für den aktuellen Stand, sondern für jeden ausgelieferten Stand.
- Direkte und transitive Abhängigkeiten erfassen, denn OWASP verortet das Risiko ausdrücklich auch in den mitgebrachten Paketen (OWASP Top 10:2025).
- Maschinenlesbares Format wählen (SPDX oder CycloneDX), damit die Betroffenheitsfrage per Abfrage statt per Sichtprüfung beantwortet wird.
- Die SBOM zusammen mit dem Deploy-Zeitpunkt ablegen, damit sich rekonstruieren lässt, welcher Stand wann live war.
- Aufbewahrung an die Nachweispflichten koppeln -- die Dokumentation, die Sie ohnehin für Wartungsnachweise gegenüber der Cyber-Versicherung führen, entsteht hier gleich mit.
Die teuerste Stunde nach einer Supply-Chain-Meldung ist die, in der niemand sagen kann, ob das betroffene Paket überhaupt im Einsatz ist. Ein Inventar verwandelt eine Krisensitzung in eine Abfrage.
Token rotieren und Deploy-Zugänge trennen
Der Payload sucht keine Kundendaten, sondern Schlüssel. In einer einzigen Welle mussten 61.274 npm-Zugriffstoken mit Schreibrechten für ungültig erklärt werden (Microsoft Security) -- Token, mit denen sich im Namen ihrer Eigentümer neue Paketversionen veröffentlichen ließen. Dabei filterte der Schadcode Automation-Token gezielt nach dem Merkmal, die Zwei-Faktor-Prüfung umgehen zu können (Cloud Security Alliance). Genau das macht den Wurm möglich: Ein Token ohne zweiten Faktor ist ein Nachschlüssel zur Lieferkette. Die Cloud Security Alliance weist zusätzlich darauf hin, dass Builds, die durch Pull Requests ausgelöst werden und zugleich Zugriff auf Veröffentlichungs-Zugangsdaten haben, eine eigene Angriffsfläche schaffen (Cloud Security Alliance).
- Deploy-, Veröffentlichungs- und Lese-Zugänge trennen: Ein Build, der nur bauen soll, braucht keinen Schlüssel zum Veröffentlichen.
- Zahlungs-API-Keys aus der Build-Umgebung heraushalten -- sie gehören in die Laufzeitumgebung, nicht in die Pipeline.
- Nach jedem Verdacht rotieren: Cloud-Schlüssel, npm-Token, SSH-Schlüssel und CI/CD-Secrets, wie es die CISA für exponierte Zugangsdaten empfiehlt (CISA).
- Unnötige Rollen und Berechtigungen der CI/CD-Identitäten entfernen, wie es Microsoft Security nach den Vorfällen empfiehlt (Microsoft Security).
- Wo möglich kurzlebige, an Workflow und Branch gebundene Anmeldungen statt langlebiger Token verwenden (Cloud Security Alliance).
- Menschliche Zugänge separat härten -- der Zusammenhang zu MFA und Least-Privilege-Rollen im Shop-Backend ist derselbe: Ein Faktor allein trägt nicht.
Der Bezug zum Shop ist unmittelbar. Wer Deploy-Zugänge erbeutet, kann Code in die Auslieferung schreiben -- und damit dasselbe Ergebnis erzielen wie ein Web-Skimming-Angriff auf die Checkout-Seite, nur eine Ebene früher und ohne Umweg über eine Schwachstelle im Shop selbst.
Auffällige Patch-Bumps im Diff erkennen
Eine Erkenntnis der April-Welle verdient besondere Aufmerksamkeit: Die Kampagne kompromittierte auch Pakete mit gültigen Provenienz-Attestierungen auf SLSA Build Level 3 -- ein Beleg dafür, dass sich Kontrollen der Prozessintegrität aushebeln lassen (Cloud Security Alliance). Eine Signatur beweist, dass eine Version durch die vorgesehene Pipeline gelaufen ist. Sie beweist nicht, dass der Inhalt harmlos ist. Die Prüfung muss deshalb den Inhalt betreffen, nicht nur die Herkunftsbescheinigung.
- Neue Install-Hooks: Eine Patch-Version, die plötzlich ein
preinstall- oderpostinstall-Skript mitbringt, ist keine Fehlerkorrektur mehr. - Große, undurchsichtige Blobs: Die Payloads der Wellen waren rund 499 KB (Microsoft Security) beziehungsweise 11,7 MB gross (Cloud Security Alliance) -- eine Patch-Version, die um Megabytes wächst, gehört angesehen.
- Neue ausgehende Verbindungen: Die CISA empfahl, ausgehende Verbindungen zur genutzten Exfiltrationsdomain zu blockieren und Firewall-Protokolle auf Verbindungen zu auffälligen Domains zu prüfen (CISA).
- Wechsel der Laufzeit: Wenn ein Paket unvermittelt eine andere Laufzeitumgebung oder einen fremden Interpreter zum Installieren verlangt, ist das ein Signal.
- Versionssprung ohne Anlass: Eine Patch-Version ohne zugehörige Änderung im Änderungsprotokoll oder ohne passenden Commit im Quell-Repository ist erklärungsbedürftig.
Diese Prüfung ist Handarbeit -- aber nicht für jedes Paket. Sie lohnt sich dort, wo der Cooldown abgelaufen ist und eine Aktualisierung bewusst übernommen wird, und besonders bei den Paketen, für die Install-Skripte freigegeben sind. Die Kontrolle über die eigenen Ausgangskanäle gehört dabei zum selben Gedanken wie die DNS-Wartung mit DNSSEC, Registrar-Lock und Monitoring: Wer weiß, wohin seine Systeme sprechen dürfen, erkennt eher, wenn sie plötzlich woanders hinsprechen.
Der Reaktionsplan, wenn ein Paket kompromittiert ist
Ein Reaktionsplan für die Lieferkette unterscheidet sich von einem Notfallplan für einen gehackten Shop: Es geht zuerst um Zugangsdaten, dann um Code, und der Shop selbst kann dabei unauffällig weiterlaufen. Die Reihenfolge entscheidet, ob aus einem betroffenen Paket ein Vorfall wird.
- Build anhalten. Solange unklar ist, welche Version gezogen wird, produziert jeder weitere Lauf zusätzliche Exposition.
- Betroffenheit prüfen. SBOM und Lockfiles gegen die gemeldeten Paketversionen abfragen -- direkte und transitive Abhängigkeiten.
- Zugangsdaten rotieren. Cloud-Schlüssel, npm-Token, SSH-Schlüssel und CI/CD-Secrets erneuern, wie es die CISA für exponierte Zugangsdaten vorsieht (CISA).
- Konten und Repositories prüfen. Die CISA rät, auf unbekannte öffentliche Repositories, verdächtige Commits und unerwartete Änderungen an Workflow-Dateien zu achten, mit denen sich Persistenz einrichten lässt (CISA).
- Ausgehenden Verkehr prüfen. Firewall-Protokolle auf Verbindungen zu auffälligen Zielen sichten (CISA).
- Zurück auf den letzten bekannten guten Stand. Lockfile auf die geprüfte Version zurücksetzen und aus sauberer Umgebung neu bauen -- ein belastbarer Backup-Service macht diesen Schritt zu einer Entscheidung statt zu einer Rekonstruktion.
- Sauber neu ausrollen. Caches und Artefakte verwerfen, die aus dem betroffenen Fenster stammen.
- Dokumentieren. Zeitpunkte, betroffene Versionen, rotierte Zugänge und Maßnahmen festhalten -- die Grundlage jedes späteren Nachweises.
Wo dieser Ablauf im Ernstfall auf Zuruf organisiert wird, kostet er Stunden. Wo er vorbereitet ist, ist er eine Checkliste. Für den akuten Fall gilt dieselbe Logik wie beim Notfallplan für eine gehackte Website: Die Entscheidungen müssen vor dem Vorfall getroffen sein, nicht während er läuft -- und wenn es eng wird, zählt eine definierte Erreichbarkeit im Notfall-Support mehr als jede nachträgliche Analyse.
Herkunftsprüfung als Teil der Wartung
Aus alldem folgt eine unbequeme Ableitung: Das bloße Einspielen von Updates ohne Herkunftsprüfung wird selbst zum Risiko. Die Antwort darauf ist allerdings nicht, seltener zu aktualisieren -- bei durchschnittlich 119 neuen Schwachstellen pro Tag (BSI, Die Lage der IT-Sicherheit in Deutschland 2025) wäre das die deutlich schlechtere Wette. Die Antwort ist ein Verfahren: Updates weiterhin zügig, aber durch definierte Kontrollen hindurch. Lockfile statt Range, Install-Skripte aus, Cooldown vor der Übernahme, Bezug über den eigenen Spiegel, SBOM als Inventar, getrennte Token.
Kontrollierte Sicherheitsupdates
Bekannte Lücken werden weiterhin zügig geschlossen -- aber über einen Weg, auf dem die Herkunft der Version geprüft ist. Das ist der Kern unserer Sicherheitsupdates.
Staging vor Produktion
Eine Aktualisierung, die aus dem Cooldown kommt, läuft zuerst gegen eine Staging-Umgebung. Wie das in der Praxis aussieht, zeigt der Beitrag zu Staging-Umgebungen für sichere Updates; den Rahmen dafür liefern unsere Wartungsleistungen.
Beobachtung nach dem Deploy
Nach jedem Ausrollen zählt, ob der Shop sich verhält wie erwartet. Unser Monitoring achtet auf genau diese Abweichung -- auch dann, wenn keine Fehlermeldung erscheint.
Der Aufwand dafür ist überschaubar, aber er ist dauerhaft. Ein Lockfile pflegt sich nicht selbst, ein Cooldown will durchgesetzt, eine SBOM erzeugt und eine Ausnahmeliste gepflegt werden. Genau deshalb gehört Lieferketten-Sicherheit in einen SLA-Wartungsvertrag und nicht in ein einmaliges Projekt: Die Kampagnen der vergangenen Monate haben gezeigt, dass die nächste Welle nicht angekündigt wird und dass sie innerhalb einer Stunde durch drei Ökosysteme laufen kann. Was dann zählt, ist nicht, wie schnell Sie reagieren -- sondern welche Kontrollen bereits standen, bevor die Meldung kam.
Quellen und Studien