Aktualisiert am 40 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
PHP ist eine Programmiersprache. Laut W3Techs, einem Dienst, der misst, welche Technologien Websites verwenden, wird sie im Oktober 2026 von 69,3 % der Websites verwendet, deren serverseitige Sprache bekannt ist. Am 21. Oktober 2026 hat das PHP-Team außerplanmäßig neue Versionen der Sprache veröffentlicht. Sie schließen zwei kritische Sicherheitslücken, die ihre Entdecker PHP2Shell getauft haben. Mit wenigen Anfragen, ohne Konto und ohne Passwort, kann ein Angreifer den Server, auf dem eine Website gehostet wird, seinen eigenen Code ausführen lassen.
Wenn Ihre Website oder Ihre Anwendung auf PHP beruht, ist die Frage an Ihren Hosting-Anbieter oder Ihren Dienstleister einfach: Welche PHP-Version verwenden wir, und wann wird sie auf eine gepatchte Version umgestellt? Unser Artikel über die PHP-Sicherheitslücke vom Oktober 2026 erklärt, wer betroffen ist und was zu tun ist, Schritt für Schritt.
Am selben Tag haben auch GitLab und Node.js Patches für schwere Sicherheitslücken veröffentlicht. GitLab, eine Plattform, die den Code von Software hostet und dessen Tests und Deployment automatisiert, hat eine Lücke (CVE-2026-110264) geschlossen, die mit 10 von 10 bewertet ist und es ohne Konto und unter bestimmten Bedingungen erlaubte, Code auf selbst betriebenen Installationen auszuführen. Sie betraf alle Versionen seit 7.0. GitLab.com, die von GitLab gehostete Version, war bereits gepatcht.
Node.js, die Software, die JavaScript auf Servern ausführt, hat Versionen veröffentlicht, die vier Lücken mit hohem Schweregrad schließen; eine davon, in der Dekomprimierung von Daten im Brotli-Format, erlaubt es, Code aus der Ferne auszuführen. Diese Versionen aktualisieren außerdem die Liste der vertrauenswürdigen Zertifikate, nachdem eine Zwischenzertifizierungsstelle von eMudhra kompromittiert wurde.
Betreibt Ihr Unternehmen GitLab selbst, oder nutzen seine Anwendungen Node.js, stellt sich für diese Software dieselbe Frage: Welche Version verwenden wir, und wann wird sie auf eine gepatchte Version umgestellt?
Medien haben diese Patches und weitere Vorfälle der Woche unter dem Namen „Black October“ zusammengefasst, der in der Nacht vom 21. auf den 22. Oktober aufkam. SecurityToday, eine deutsche Nachrichtenseite zur IT-Sicherheit, sieht darin vor allem eine Häufung von Veröffentlichungen: Viele der in diesen Tagen bekannt gewordenen Angriffe hatten Wochen oder Monate früher begonnen.
Der Rest gilt für jede Anwendung, in welcher Sprache sie auch geschrieben ist. Diese Lücken sind nicht die ersten dieses Ausmaßes, und nichts deutet darauf hin, dass sie die letzten sein werden. Auf eine Lücke kann man sich in drei Punkten vorbereiten: was sie einem Angreifer zugänglich macht, wie lange es dauert, sie zu bemerken, und wie lange, sie zu beheben.
Die technischen Details stehen in den Abschnitten mit dem Titel „Für Ihr technisches Team“.
Mandiant, das Threat-Intelligence-Team von Google Cloud, misst jedes Jahr die Zeit zwischen der Veröffentlichung einer Lücke und ihrer ersten beobachteten Ausnutzung. Im Durchschnitt betrug diese Zeit 63 Tage in den Jahren 2018 und 2019, 44 Tage zwischen 2020 und Anfang 2021, 32 Tage in den Jahren 2021 und 2022 und dann nur noch 5 Tage im Jahr 2023 (Mandiant). In seinem Bericht M-Trends 2026 schätzt Mandiant, dass die erste Ausnutzung der Veröffentlichung der Lücke im Durchschnitt um sieben Tage vorausgeht. Die Ausnutzung findet häufig „noch vor der Veröffentlichung eines Patches“ statt (M-Trends 2026).
VulnCheck, ein Unternehmen, das Sicherheitslücken beobachtet, hat nur die Lücken betrachtet, deren Ausnutzung belegt ist. Im ersten Halbjahr 2026 wurden 23,43 % davon am Tag ihrer Veröffentlichung oder davor ausgenutzt. Content-Management-Systeme wie WordPress und seine Plugins (so heißen die Erweiterungen bei WordPress) sind die am stärksten angegriffene Kategorie: ein Drittel dieser Lücken (VulnCheck). Und laut dem Jahresbericht von Verizon über Datenschutzverletzungen, Ausgabe 2026, beginnen 31 % der Datenpannen mit einer Softwarelücke, noch vor gestohlenen Passwörtern (Verizon DBIR 2026).
Die Sicherheitsbehörden sind sich in einem Punkt einig: Die KI verkürzt die Zeit, die denen bleibt, die Patches einspielen. Im Mai kündigte das NCSC, das nationale Cybersicherheitszentrum des Vereinigten Königreichs, eine Welle von Updates für Lücken aller Schweregrade an, weil die KI in fähigen Händen erlaubt, die in Software angesammelten Schwächen „in großem Maßstab und in hohem Tempo“ auszunutzen. Im Juni änderte die CISA, die US-Behörde für Cybersicherheit, die Fristen, die sie den US-Bundesbehörden für das Einspielen von Patches setzt: Sie hängen nun vom Risiko ab (Erreichbarkeit aus dem Internet, belegte Ausnutzung, Auswirkung). Die kürzeste Frist beträgt drei Tage. Sie begründet diese Änderung mit der Nutzung von KI durch Angreifer, die die Zeit, die den Verteidigern bleibt, „noch weiter verkürzen könnte“. Daraus leiten wir eine Regel ab: Ein kritischer Patch wird noch am Tag seiner Veröffentlichung eingespielt, und das gelingt mit einer Art der Auslieferung, bei der jede Änderung bereits die Pipeline durchläuft.
Die KI dient auch dazu, Code zu schreiben, und mehrere dieser Behörden empfehlen, ihn zu kontrollieren. Im März 2026 warnte der Leiter des NCSC, dass unsichere Software, die „ohne menschliche Prüfung“ entsteht, Lücken verbreiten könnte. Das BSI, die Cybersicherheitsbehörde des Bundes, sieht in seinem Bericht über KI-Programmierassistenten das Risiko, dass man sich zu sehr auf diese Werkzeuge verlässt und den von ihnen erzeugten Code ungeprüft übernimmt, besonders bei unerfahrenen Entwicklern. Es empfiehlt, dass der erzeugte Code in der Regel von den Entwicklern geprüft wird, mit einem kritischen Blick auf Fehler des Werkzeugs und auf Sicherheitsrisiken. Für KI-Agenten gilt derselbe Grundsatz wie für den PHP-Prozess: nur die nötigsten Rechte (Details weiter unten).
Konkret raten wir einem Team, das mit KI entwickelt, jede Zeile, die das Werkzeug schreibt, gegenzulesen und sie wie den übrigen Code durch die Tests der Pipeline laufen zu lassen; vor dem Hinzufügen einer von der KI vorgeschlagenen Komponente zu prüfen, ob sie existiert und wer sie veröffentlicht; und einem Agenten nur die Rechte zu geben, die seine Aufgabe braucht. Für eine mit KI erstellte Anwendung beschreibt unser Artikel „Kann man mit KI eine App erstellen?“, was das Werkzeug allein schafft.
Ein KMU oder ein Start-up braucht keine Sicherheitsforscher im Team. Eine Lücke wie PHP2Shell zu finden erfordert Spezialisten, und ihre Suche fand vor der Veröffentlichung statt: Acht bis zehn Wochen liegen zwischen der ersten Meldung und dem Patch, nach den Zeitplänen von Wiz, einem Unternehmen für Cloud-Sicherheit, und Calif, einem Unternehmen für Sicherheitsforschung, dessen Forscher dem PHP-Team die ersten Lücken gemeldet haben (Wiz, Calif). Für den Rest legt das IT-Grundschutz-Kompendium des BSI Basis-Anforderungen fest, das Minimum dessen, was vernünftigerweise an Sicherheitsvorkehrungen umzusetzen ist. Wer die Fachkenntnis nicht hat, zieht unserer Ansicht nach einen Spezialisten für eine Bewertung hinzu und benennt im Unternehmen eine Ansprechperson für Sicherheit.
Dave Farley ist der Erfinder der Deployment-Pipeline, die oft CI/CD-Pipeline genannt wird. Continuous Delivery bedeutet, die Software jederzeit bereit für die Produktion zu halten, durch kleine, automatisch geprüfte Änderungen. Die Deployment-Pipeline ist die automatische Kette, die jede Codeänderung aufnimmt, testet, speichert und bereit macht, in Produktion zu gehen. Dave Farley hat zusammen mit Jez Humble das Buch Continuous Delivery geschrieben und ist Autor von Modern Software Engineering (Modernes Software-Engineering). In Continuous Delivery Pipelines schreibt er, dass Sicherheit den Rat von Spezialisten erfordern kann, aber „in der Verantwortung jedes Einzelnen im Team“ liegt. Die Spezialisten beraten; sie sollen keine „Gatekeeper“ sein, die jedes Deployment in die Produktion freigeben.
Was das Team, das die Anwendung entwickelt und wartet, tun kann, lässt sich in vier Zielen zusammenfassen, und keines davon verlangt, nach Lücken zu suchen:
Die Abschnitte „Begrenzen, was ein Angreifer über eine Lücke erreicht“ und „Sofort alarmiert werden“ behandeln die ersten beiden Ziele. Die Abschnitte über die Abhängigkeiten, über die Updates und über die Art der Auslieferung behandeln das dritte, der Abschnitt „Website gehackt oder Sicherheitslücke entdeckt“ das vierte. Die Deployment-Pipeline prüft außerdem jede Änderung am Code, um die Lücken zu finden, die sie einführen würde (Sicherheitstests in der Pipeline).
Laut M-Trends 2026 beträgt die mediane Zeit zwischen dem Eindringen eines Angreifers in ein System und seiner Entdeckung 14 Tage (M-Trends 2026). In dieser Zeit ist der Angreifer aktiv: Die ersten beiden Ziele verringern, was er erreichen kann und wie lange er unbemerkt bleibt.
Ein digitaler Dienst ist mehr als eine Website. Eine typische Webanwendung besteht aus mehreren Teilen: einem Eingangspunkt, der die Anfragen aus dem Internet empfängt und weiterleitet, dem Server, der den Code ausführt, einer Datenbank, Backups und den Konten der Personen, die das Ganze verwalten. Jeder dieser Teile lässt sich so einstellen, dass eine Lücke in einem davon nicht Zugang zu allen anderen verschafft. Das nennt man gestaffelte Verteidigung (Defense in Depth).
Jedem Programm nur die nötigsten Rechte geben. Der PHP-Prozess muss weder Administrator der Maschine sein noch den Code der Website ändern können. Das Konto, mit dem er sich mit der Datenbank verbindet, muss laut dem Sicherheitsleitfaden von WordPress nur Daten lesen und schreiben; die Rechte, zu löschen, die Struktur zu ändern oder Rechte zu vergeben, können ihm entzogen werden, wobei manche WordPress-Updates diese Struktur ändern müssen. Jez Humble und Dave Farley sagen es in Continuous Delivery: Die Standardeinstellungen von Betriebssystemen und Datenbanken eignen sich nicht für eine Anwendung in Produktion; es braucht Firewalls, deaktivierte unnötige Dienste und Datenbankbenutzer mit passend eingestellten Rechten.
Der Code darf sich über die Website nicht ändern lassen. Kann der PHP-Prozess nicht in die Verzeichnisse des Codes schreiben, kann ein Angreifer, der ihn übernimmt, dort nicht so leicht eine Web Shell ablegen, eine kleine Datei, mit der er zurückkehren und den Server über seinen Browser steuern kann. Bei einer WordPress-Website muss nur das Verzeichnis für hochgeladene Inhalte beschreibbar bleiben, und der Code-Editor im Administrationsbereich lässt sich deaktivieren.
Abschotten. Die Datenbank hat keinen Grund, aus dem Internet erreichbar zu sein: Nur der Anwendungsserver muss sich mit ihr verbinden können.
Vorgelagert filtern und die Grenzen des Filters kennen. Eine Web Application Firewall (WAF) prüft die Anfragen, bevor sie den Server erreichen, und blockiert diejenigen, die einem bekannten Angriff ähneln. Der Sicherheitsleitfaden von WordPress empfiehlt, eine zu installieren. Sie hat ihre Grenzen: Cloudflare fordert selbst dazu auf, den Patch einzuspielen, auch mit seinen Regeln gegen PHP2Shell. Eine Web Application Firewall verschafft Zeit; sie ersetzt den Patch nicht.
Sicherheitsheader mitschicken und auf der Live-Website prüfen. Mit jeder Seite kann der Server dem Browser mitteilen, was er damit tun darf: nur verschlüsselte Verbindungen verwenden, verweigern, dass eine andere Website die Seite in einem Frame anzeigt, Skripte nur von den vorgesehenen Adressen laden. OWASP, die maßgebliche Stiftung für die Sicherheit von Webanwendungen, empfiehlt diese Header und nennt Mozilla Observatory, um sie auf der Produktionswebsite zu prüfen. Der anspruchsvollste von ihnen, die Content Security Policy (CSP), begrenzt die Skripte, die eine Seite ausführen darf: Code, der in eine Zahlungsseite eingeschleust wurde, um Kartennummern zu kopieren, lässt sich dann schwerer ausführen. OWASP bezeichnet sie als „eine wirksame zweite Schutzschicht“, auf die man sich nicht allein verlassen sollte. Auf einer bestehenden Website wird sie schrittweise eingeführt, zunächst im Beobachtungsmodus, in dem der Browser meldet, was sie blockieren würde, ohne etwas zu blockieren.
Secrets aus dem Code holen. Passwörter und Zugangsschlüssel zu anderen Diensten (Zahlung, E-Mail-Versand, Speicher) sollten nicht in den Dateien des Codes stehen. MITRE ATT&CK empfiehlt eine Regel, die verbietet, Passwörter in Dateien zu speichern. In den Umgebungsvariablen des Servers oder in einem Secrets-Tresor bleiben sie für PHP lesbar, während es ausgeführt wird: Das schützt sie nicht, wenn der PHP-Prozess übernommen wird. Was man dadurch gewinnt, ist aus unserer Sicht, dass sie weder in der Historie des Codes noch in dessen Backups liegen und dass man sie ändern kann, ohne den Code anzufassen. Das zählt an dem Tag, an dem man sie alle ersetzen muss.
Festlegen, wo Secrets liegen. Secrets der Pipeline und der Produktion gehören in die geschützten Variablen der Continuous-Integration-Plattform oder in einen Secrets-Manager: GitLab verlangt, Tokens und Passwörter in den Projekteinstellungen zu speichern, nie in der Datei, die die Pipeline beschreibt. Auf dem Rechner eines Entwicklers raten wir, kein Secret im Klartext in einer Datei aufzubewahren: Der Passwort- oder Secrets-Manager übergibt es dem Programm in dem Moment, in dem es ausgeführt wird; fehlt ein solcher Manager, raten Jez Humble und Dave Farley, es verschlüsselt aufzubewahren. OWASP empfiehlt, Produktions-Secrets von Entwicklungs-Secrets zu trennen, und jedem nur die nötigsten Rechte zu geben: Ein Entwickler arbeitet mit Zugangsdaten für die Entwicklung, mit denen er nicht auf die Produktion zugreifen kann. Ein Token, das nicht mehr gebraucht wird, wird bei dem Dienst widerrufen, der es ausgestellt hat, statt in einer vergessenen Datei gültig zu bleiben.
Die Konten der Menschen schützen. Ein Angreifer braucht nicht immer eine Lücke: Ein wiederverwendetes Passwort genügt ihm. Das IT-Grundschutz-Kompendium des BSI verlangt, den Passwortgebrauch verbindlich zu regeln und zu prüfen, ob Passwörter als alleiniges Authentisierungsverfahren eingesetzt werden sollen oder ob weitere Authentisierungsmerkmale hinzukommen (ORP.4.A8). Konkret empfehlen wir einen Passwortmanager, damit jeder für jeden Dienst ein anderes Passwort hat, und eine Zwei-Faktor-Authentifizierung für die Konten, die Zugang zur Produktion, zum Hosting und zum Code geben.
Manuelle Änderungen in der Produktion verbieten. In Continuous Delivery Pipelines setzt Dave Farley ein Ziel: „jeden menschlichen Schreibzugriff auf Produktionssysteme entfernen“. Jede Änderung läuft über die Deployment-Pipeline. In Continuous Delivery fügen die beiden Autoren hinzu, dass die Produktion für Außenstehende wie für Mitarbeitende des Unternehmens gesperrt sein muss, Betriebsteams eingeschlossen. Ohne das weiß niemand mehr, wer was wann getan hat, wenn etwas schiefgeht.
Offline-Backups aufbewahren und testen. Ein Backup, das vom kompromittierten Server aus erreichbar ist, kann zusammen mit dem Rest verschlüsselt oder gelöscht werden. Das IT-Grundschutz-Kompendium des BSI empfiehlt, die Speichermedien der Datensicherung räumlich getrennt von den gesicherten IT-Systemen aufzubewahren (CON.3.A12). Ein Backup, das nie wiederhergestellt wurde, hat nicht bewiesen, dass es funktioniert.
user festlegt (php.net). Mit php_admin_value und php_admin_flag gesetzte Einstellungen lassen sich nicht durch ini_set() ändern. PHP-FPM nicht auf einer von außen erreichbaren Adresse anbieten.expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…) sowie Session-Cookies mit secure, httponly und use_strict_mode. Die PHP-Dokumentation warnt jedoch selbst, dass disable_functions „umgangen werden kann“ und dass open_basedir nur „ein zusätzliches Sicherheitsnetz, bei Weitem nicht vollständig“ ist, das den Zugriff auf Unix-Sockets nicht einschränkt. Diese Einstellungen erschweren den weiteren Verlauf eines Angriffs; sie verhindern ihn nicht, und PHP2Shell wird ausgelöst, bevor die Anwendung ausgeführt wird.Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, frame-ancestors in der CSP (oder X-Frame-Options), Referrer-Policy, Permissions-Policy. Die CSP beginnt als Content-Security-Policy-Report-Only, solange die legitimen Skripte erfasst werden.Steht die Verteidigung, muss man noch gewarnt werden, wenn sie überwunden wird. Das Ziel ist dreifach: wissen, dass etwas Ungewöhnliches passiert, den Zugang kappen und dann herausfinden, woher der Angriff kommt. In Continuous Delivery verlangen Jez Humble und Dave Farley, dass die Betriebsteams bei einem Vorfall „sofort informiert“ werden und über die Werkzeuge verfügen, seine Ursache zu finden. Sie nennen auch einen häufigen Fehler: Fehler zu ignorieren, statt sie zu protokollieren, wodurch man sie nicht erkennen kann.
Eine Monitoring-Lösung überwacht bestimmte Signale, und ihre Logs liegen getrennt vom überwachten Server. Die Betriebsteams verfolgen den Zustand der Server ständig auf Dashboards wie Grafana oder Kibana, die Messwerte und Logs zusammenführen und einen Alarm auslösen, wenn ein Schwellenwert überschritten wird. Diese Signale sollten einen Alarm auslösen:
Der Webserver startet ein Programm. Ein Webserver liefert Seiten aus; er hat keinen Grund, einen Kommandozeileninterpreter oder ein Download-Werkzeug zu starten. Tut er es doch, wird oft eine Web Shell benutzt (MITRE ATT&CK).
Der Server verbindet sich mit unbekannten Adressen. Software, die Kryptowährung schürft, ein Fernsteuerungswerkzeug oder ein Datenabfluss brauchen alle ausgehende Verbindungen. Wir empfehlen, ausgehende Verbindungen des Servers standardmäßig zu blockieren, außer zu den Diensten, die die Anwendung braucht: Das schränkt auch den Einsatz dieser Werkzeuge ein.
Eine Codedatei ändert sich. In der Produktion ändert sich der Code nur bei einem Deployment. Eine neue .php-Datei in den Verzeichnissen der Website außerhalb eines Deployments ist ein Zeichen für ein Eindringen. WordPress empfiehlt, die Integrität der Dateien zu überwachen, und erinnert daran, dass ein Angriff „immer Spuren hinterlässt, in den Logs oder in den Dateien“.
Ein neues Administratorkonto taucht auf. Wir raten, das Verzeichnis der privilegierten Konten aktuell zu halten. Ein Administratorkonto, das außerhalb jedes Verfahrens angelegt wurde, ist ein Signal, dem man nachgehen muss.
Die Fehler häufen sich. Wir raten, die Fehler der Webdienste (403, 404 und 500) sowie unerwartete Abschaltungen zu protokollieren.
Die Logs außerhalb des Servers aufbewahren. Ein Angreifer, der den Server kontrolliert, kann seine Spuren in den dort liegenden Logs löschen. Wir raten daher, die Logs auf einem anderen System zu zentralisieren.
Einige freie Werkzeuge, als Beispiel genannt:
/etc ab (Falco-Dokumentation).Eine Anwendung wird nicht vollständig von denen geschrieben, die sie entwickeln. Sie stützt sich auf Komponenten, die andere veröffentlichen: die Abhängigkeiten. Werkzeuge installieren und aktualisieren sie, Composer für PHP, npm oder pnpm für JavaScript. Und sie wird in einer Umgebung ausgeführt, PHP selbst, die das System des Servers, der Hoster oder das Image bereitstellt, mit dem sie deployt wird.
In Continuous Delivery sind Jez Humble und Dave Farley unmissverständlich: Ein Projekt muss immer „die genaue Version der externen Bibliotheken“ angeben, die es verwendet. Ohne das, schreiben sie, lässt sich nicht exakt nachbauen, was in Produktion ist. Aus unserer Sicht weiß man dann auch nicht, ob man einer Lücke ausgesetzt ist.
Weniger installierte Komponenten bedeuten weniger mögliche Lücken: Die OWASP empfiehlt, unnötige Abhängigkeiten zu entfernen. Und eine Komponente, die ihr Autor aufgegeben hat, erhält keinen Patch mehr: Sie wird ersetzt.
Akzeptiert ein Projekt „jede Version ab dieser“, gelangt eine neu veröffentlichte Version beim nächsten Update in die Anwendung, ohne dass jemand sie ausgewählt hätte. Das ist derzeit die Standardeinstellung von npm (npm), und Composer empfiehlt es für Bibliotheken, die von anderen Projekten wiederverwendet werden sollen (Composer). Die Details der Schreibweise stehen im Kasten „Für Ihr technisches Team: Abhängigkeiten“ weiter unten.
Nicht alle neuen Versionen werden gleich behandelt. Der Patch für eine schwere Lücke wird installiert, sobald er veröffentlicht ist: Abwarten heißt, die Tür offen zu lassen. Die anderen neuen Versionen können ein paar Tage warten, denn bösartiger Code gelangt über gerade erst veröffentlichte Versionen hinein. 2018 übernahm ein Angreifer die Pflege des Pakets event-stream und fügte Code hinzu, der es auf die Bitcoin-Wallets der Anwendung Copay abgesehen hatte (npm). Im September 2025 wurde das Konto des Maintainers von chalk, debug und rund zwanzig weiteren JavaScript-Paketen mit einer gefälschten E-Mail zum Zurücksetzen des Passworts gekapert; laut StepSecurity, einem Unternehmen für IT-Sicherheit, wurden diese Pakete damals milliardenfach pro Woche heruntergeladen (StepSecurity). Wenige Tage später hatte der Wurm Shai-Hulud, der sich selbstständig von Paket zu Paket verbreitete, mehr als 500 davon kompromittiert; die CISA empfahl daraufhin, die Abhängigkeiten auf sichere Versionen festzulegen, die vor dem 16. September 2025 veröffentlicht wurden (CISA).
Daraus ergeben sich sechs Praktiken.
Die exakte Version eintragen, in der Datei, die die Abhängigkeiten deklariert. Die Anwendung erhält dann eine neue Version, wenn jemand es entscheidet, nicht wenn sie veröffentlicht wird. Mit einem Lockfile, das zusammen mit dem Code versioniert wird (nächste Praxis), wirkt ein Versionsbereich nur im Moment eines Updates. Er ist also an sich keine Lücke: Die exakte Version ist eine Teamregel, die jedes Update zu einer bewussten Entscheidung macht. Für eine PHP-Anwendung genügt composer.lock, um genau nachzubauen, was in Produktion ist; exakte Versionen in composer.json bleiben optional. Derzeit lehnt die Pipeline unserer eigenen Website jede Abhängigkeit ab, die ohne exakte Version deklariert ist.
Das Lockfile aufbewahren, zusammen mit dem Code. Diese Datei hält die exakte Version jeder installierten Komponente fest, einschließlich der Komponenten, von denen Ihre Komponenten abhängen, und die Dokumentation von Composer empfiehlt, sie zusammen mit dem Code des Projekts zu versionieren (Composer).
Aus dieser Datei installieren und nur nach Entscheidung aktualisieren. Die Pipeline installiert genau die Versionen aus dem Lockfile. Ein Update wird Komponente für Komponente entschieden und getestet.
Abwarten, bevor man eine gerade erst veröffentlichte Version übernimmt. Der Paketmanager pnpm bietet diese Wartezeit an, seit seiner Version 11 derzeit standardmäßig auf einen Tag eingestellt, „um das Risiko zu verringern, kompromittierte oder fehlerhafte Pakete zu installieren“. Seine Dokumentation gibt an, dass bösartige Versionen in der Regel in weniger als einer Stunde entdeckt und entfernt werden (pnpm). Der Patch für eine schwere Lücke unterliegt dieser Wartezeit nicht: Er wird installiert, sobald er veröffentlicht ist, nachdem geprüft wurde, dass er tatsächlich vom Hersteller angekündigt wurde.
Installationsskripte blockieren, außer den freigegebenen. Ein JavaScript-Paket kann bei seiner Installation jeden beliebigen Befehl ausführen, und OWASP rät, diese Skripte abzuschalten. Derzeit blockiert pnpm sie standardmäßig, außer für die Pakete, die das Team einzeln freigegeben hat (pnpm). Composer führt bei PHP nur die Skripte des Projekts selbst aus und lädt kein Plugin, das seine Liste allow-plugins nicht nennt (Composer): Es genügt, diese Einstellung nicht zu lockern.
Auch die Version der Sprache festlegen und prüfen, dass jede Umgebung sie verwendet. Die Laufzeitumgebung, PHP oder Node.js, wird wie eine Abhängigkeit behandelt. Jez Humble und Dave Farley verlangen, auf Umgebungen zu testen, die der Produktion so ähnlich wie möglich sind, mit derselben installierten Software. Wir raten daher, dass das Projekt die Sprachversion der Produktion festlegt und die Pipeline fehlschlägt, wenn eine Umgebung eine andere verwendet. Auch diese Version muss aktuell gehalten werden: Das NIST, das US-amerikanische Institut für Normen und Technologie, verlangt in seinem Secure Software Development Framework (SSDF), aktuelle Versionen von Compilern, Interpretern und Build-Werkzeugen zu verwenden.
Das umgekehrte Risiko gibt es auch: seine Versionen festlegen und sie nie wieder aktualisieren. Nach unseren Berechnungen auf Basis der Zahlen von W3Techs verwendete im Oktober 2026 fast die Hälfte der PHP-Websites eine Version, die das PHP-Team nicht mehr pflegt. Eine fest eingetragene Version schützt nur, wenn regelmäßig aktualisiert wird: oft, ein Update nach dem anderen und getestet. Jez Humble und Dave Farley machen daraus ein allgemeines Prinzip: „Wenn es wehtut, tun Sie es öfter, und holen Sie den Schmerz nach vorne.“ Ein Update, das jede Woche gemacht wird, ändert wenig auf einmal; ein Update, das zwei Jahre lang aufgeschoben wird, wird zur Großbaustelle.
Jeden Tag werden neue Lücken in Code veröffentlicht, der sich selbst nicht verändert hat. Eine Prüfung, die nur bei einer Änderung gestartet wird, übersieht die Lücken, die in der Zwischenzeit veröffentlicht wurden. Composer, das Werkzeug, das die Komponenten einer PHP-Anwendung verwaltet, kann die installierten Komponenten mit den Sicherheitshinweisen abgleichen, die auf Packagist, dem wichtigsten Repository für PHP-Komponenten, veröffentlicht werden, und meldet auch aufgegebene Komponenten (Composer). Täglich von einem geplanten Job der Pipeline gestartet, meldet diese Prüfung eine Lücke, sobald ihr Sicherheitshinweis veröffentlicht ist. In Continuous Delivery Pipelines fordert Dave Farley, dass Sicherheit in der Pipeline getestet wird, ab der ersten Stage, und nicht als separate Kontrolle behandelt wird.
Einmal pro Woche listet eine weitere Prüfung die Komponenten auf, für die es eine neue Version gibt. Diese Erinnerung verhindert den Rückstand von zwei Jahren.
Eine geplante Prüfung kann auch aufhören, ausgeführt zu werden, ohne dass es jemand bemerkt, und ihr Schweigen sieht dann wie eine gute Nachricht aus. Wir raten daher, jeder geplanten Prüfung einen Heartbeat zu geben, ein Lebenszeichen: Ein Alarm geht los, wenn die erwartete Prüfung nicht stattgefunden hat. Keine Sicherheitsreferenz schreibt das vor; es stützt sich auf den Alarm, den Jez Humble und Dave Farley in Continuous Delivery vorsehen, den Alarm dafür, dass „ein erforderliches Ereignis nicht eingetreten ist“.
Nicht jede Warnung verlangt dieselbe Reaktion. Zwei Angaben entscheiden über die Dringlichkeit. Zuerst die Ausnutzung: Eine bereits ausgenutzte Lücke geht einer schwereren vor, die noch nicht ausgenutzt wird. Die CISA führt die Liste der ausgenutzten Lücken: Sie setzt den US-Bundesbehörden Fristen, um sie zu beheben, und empfiehlt jeder Organisation, sie „sofort“ anzugehen. FIRST, die internationale Organisation, die die CVSS-Skala für den Schweregrad herausgibt, veröffentlicht außerdem täglich das EPSS, eine Schätzung der Wahrscheinlichkeit, dass eine Lücke innerhalb von dreißig Tagen ausgenutzt wird.
Dann der Schweregrad: Die meisten Sicherheitshinweise geben einen CVSS-Wert von 0 bis 10 an, den FIRST in fünf Stufen einteilt: keine (0), niedrig (0,1 bis 3,9), mittel (4 bis 6,9), hoch (7 bis 8,9) und kritisch (9 bis 10) (CVSS 4.0). Die Lücken von PHP2Shell sind mit 9,2 bewertet: kritisch. Dieser Wert vergleicht den Schweregrad einer Lücke mit dem der anderen; er misst nicht das Risiko für Ihr Unternehmen.
In der Praxis raten wir, jede Lücke, die bereits ausgenutzt wird oder kritisch ist, noch am Tag der Veröffentlichung des Patches zu beheben: Damit weiten wir die Empfehlung der CISA aus, die für ausgenutzte Lücken gilt. Die anderen folgen dem normalen Rhythmus der Updates, eines nach dem anderen.
Manche Warnungen werden nicht sofort bearbeitet: Der betroffene Teil der Komponente wird von der Anwendung nie aufgerufen, oder es gibt noch keinen Patch. Das NIST verlangt, den Grund jeder solchen Ausnahme festzuhalten und alle genehmigten Ausnahmen regelmäßig neu zu bewerten. Wir geben jeder Ausnahme ein Ablaufdatum, an dem die Pipeline fehlschlägt und neu über die Ausnahme entschieden wird: Keine Referenz schreibt dieses Datum vor, es ist unsere Art, die Neubewertung durchzusetzen, die das NIST verlangt.
Diese Werkzeuge haben eine Grenze, und PHP2Shell zeigt sie. Sie prüfen die Bibliotheken, die die Anwendung deklariert, nicht die Sprache, die sie ausführt. Eine Prüfung der Komponenten ohne Warnung sagt nichts über PHP2Shell aus. Die PHP-Version wird gesondert überwacht: Das PHP-Team veröffentlicht die Liste der unterstützten Versionen und einen Feed seiner Releases. Wir raten auch, das Ende der Wartung von Software vorauszuplanen: PHP 8.2 erhält nach dem 31. Dezember 2026 keine mehr.
Eine composer.json mit exakten Versionen (Komponentennamen als Beispiel):
{
"require": {
"vendor/component-a": "2.3.1",
"vendor/component-b": "5.0.4"
}
}
Statt "^2.3.1", das jede Version von 2.3.1 bis ausschließlich 3.0.0 akzeptieren würde (Composer). Derzeit trägt npm standardmäßig ^ ein: ^1.2.3 akzeptiert jede Version ab 1.2.3 und vor 2.0.0 (node-semver). Bei npm sorgt save-exact=true in .npmrc dafür, dass standardmäßig die exakte Version eingetragen wird (npm).
Ein Beispiel für eine GitLab-Pipeline, zur Veranschaulichung und an Ihr Projekt anzupassen: eine Prüfung bei jedem Push, ein täglicher und ein wöchentlicher Job, jeder durch einen eigenen GitLab-Zeitplan ausgelöst (Zeitpläne, Regeln).
# Beispiel zur Veranschaulichung, an Ihr Projekt anzupassen
stages: [commit, audit]
.php:
# Image Ihres Projekts mit PHP und Composer, per Digest festgelegt
image: registry.example/php-composer@sha256:<digest>
commit:
extends: .php
stage: commit
script:
# Prüft, ob composer.json und composer.lock zueinander passen
- composer validate --strict
# Schlägt fehl, wenn eine Komponente, ob für Produktion oder Entwicklung, einen Sicherheitshinweis hat
- composer audit --locked
# Installiert genau die Versionen aus dem Lockfile
- composer install --no-interaction --prefer-dist
rules:
- if: $CI_PIPELINE_SOURCE == "push"
daily-audit:
extends: .php
stage: audit
script:
# Dieselbe Prüfung jeden Tag, ohne Codeänderung; schlägt auch bei aufgegebenen Komponenten fehl
- composer audit --locked --abandoned=fail
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"
weekly-reminder:
extends: .php
stage: audit
script:
# Listet verfügbare neue Versionen auf, ohne die Pipeline fehlschlagen zu lassen: Das ist die Erinnerung
- composer outdated --direct
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
composer.lock, bei npm package-lock.json) wird zusammen mit dem Code versioniert. Die Pipeline führt composer install aus, das genau die Versionen aus dieser Datei installiert; composer update berechnet die Versionen neu und schreibt die Datei um: Es dient nur einem beschlossenen Update, zum Beispiel composer update vendor/component-a (Composer).minimumReleaseAge bei pnpm, min-release-age bei npm (Namen der Einstellungen im Oktober 2026). Bei Composer raten wir, diese Wartezeit über eine Teamregel einzuhalten oder über das Werkzeug, das die Updates vorschlägt.composer audit gibt einen Exit-Code ungleich null zurück, wenn eine Komponente von einem Hinweis betroffen ist: Der Job wird rot, und das ist der Alarm. --locked liest das Lockfile, auch ohne vendor-Verzeichnis (Composer): Das Beispiel führt die Prüfung deshalb vor composer install aus, und der Job bricht ab, bevor eine Komponente mit Sicherheitshinweis installiert wird. Das Beispiel prüft auch die Entwicklungskomponenten: Sie werden in der Pipeline ausgeführt, die Zugriff auf den Code und die Secrets für das Deployment hat.php enthalten, daher das Image des Projekts im Beispiel.@sha256:…): Laut der Docker-Dokumentation erhält man dann immer dasselbe Image, und sie warnt, dass das Image keine Updates mehr erhält, „die Sicherheitspatches enthalten können“ (Docker). Das Festlegen ist daher nur sinnvoll, wenn der Digest regelmäßig aktualisiert und von der Pipeline getestet wird.integrity), und die Installation schlägt fehl, wenn das heruntergeladene Paket nicht passt. Bei einem Skript oder einem Stylesheet, das von einer anderen Domain geladen wird, sorgt das Attribut integrity (Subresource Integrity) dafür, dass der Browser eine veränderte Datei ablehnt (MDN). Die OWASP empfiehlt, die Prüfung der Hashes und Signaturen heruntergeladener Pakete zu aktivieren. Renovate oder Dependabot können diese Updates als Merge Requests vorschlagen; sie deployen selbst nichts (Renovate, Dependabot).https://www.php.net/feed.atom). OSV-Scanner von Google liest derzeit composer.lock und in einem Container-Image die Pakete von Alpine sowie von Debian oder Ubuntu: Es kann ein PHP erkennen, das vom System des Images installiert wurde.allowBuilds die Pakete auf, die bei der Installation ein Skript ausführen dürfen (pnpm); für npm ignore-scripts=true in .npmrc (OWASP). Für Composer nennt allow-plugins nur die nötigen Plugins, nie true für alle (Composer).require.php in composer.json und composer check-platform-reqs, das fehlschlägt, wenn die PHP-Version oder eine Erweiterung der Umgebung nicht passt; mit config.platform wählt Composer die Abhängigkeiten für die PHP-Version der Produktion (Composer). Für Node.js lässt das Feld engines der package.json mit engine-strict=true die Installation auf einer anderen Version fehlschlagen.audit.ignore in composer.json hält für jeden ignorierten Hinweis den Grund fest (Composer).Für Software, die man installiert und unverändert nutzt (Windows, macOS, ein Smartphone, ein Browser, eine Office-Anwendung), raten wir, die automatischen Updates zu aktivieren, wie es das NCSC fordert. Bei einer WordPress-Website raten wir von den automatischen Updates ab, die WordPress selbst einspielt.
Eine Anwendung, die man entwickelt oder aus Komponenten zusammensetzt, wird nur nach bewusster Entscheidung aktualisiert. Der Anforderungskatalog Cyber Essentials des NCSC nimmt die individuell entwickelten Komponenten von Webanwendungen von seinem Geltungsbereich aus und empfiehlt für sie „gründliche Entwicklung und Tests“. Die OWASP empfiehlt in den OWASP Top 10 2025, der Liste der kritischsten Risiken für Webanwendungen, „die Version jeder Abhängigkeit bewusst zu wählen und nur bei Bedarf zu aktualisieren“, und „Updates nicht auf allen Systemen gleichzeitig auszurollen“. Ihre Top 10 der CI/CD-Sicherheitsrisiken empfehlen, die Werkzeuge nicht so zu konfigurieren, dass sie immer die neueste Version eines Pakets beziehen. Wir raten, jedes Update, ob der Sprache oder einer Komponente, durch die Deployment-Pipeline und ihre automatisierten Tests laufen zu lassen.
Dieser Ansatz setzt voraus, dass sich jemand um die Wartung kümmert. Automatisiert werden die Alarme: ein Alarm, wenn eine Lücke die eingesetzten Versionen betrifft, ein Alarm, wenn auf dem Server etwas Ungewöhnliches passiert, der in dem Moment warnt, in dem es geschieht. Ein Mensch entscheidet, wann aktualisiert wird, und spielt den Patch für eine kritische oder bereits ausgenutzte Lücke ohne Wartezeit ein.
Für eine WordPress-Website oder eine PHP-Anwendung hängt es vom Hosting ab, ob der Hoster PHP aktualisiert oder Sie selbst. Bei WordPress aktualisiert man Plugins und Themes eines nach dem anderen.
Jede Änderung am Code kann ebenfalls eine Lücke einführen: Die Pipeline prüft daher den Code, den das Team schreibt, so wie sie die Abhängigkeiten prüft. Dave Farley, weiter oben zitiert, verlangt außerdem, gängige Penetrationstests zu automatisieren. Das NIST empfiehlt eine statische Analyse, die den Code automatisch prüft, und dynamische Schwachstellentests, die in die automatisierten Tests eingebunden sind.
Die statische Analyse liest den Code, ohne ihn auszuführen, und findet Codemuster, die bekanntermaßen Lücken verursachen. Semgrep, eines von mehreren Open-Source-Werkzeugen, hat Regeln für PHP wie für JavaScript. Diese Werkzeuge melden auch Fälle, die gar keine Lücken sind (Fehlalarme): Jemand muss jede Meldung prüfen, und das NIST verlangt, die gefundenen Probleme festzuhalten und einzuordnen.
Dynamische Tests senden Anfragen an die Anwendung, während sie ausgeführt wird, so wie es ein Besucher täte. Der Baseline-Scan von ZAP, einem Open-Source-Werkzeug für Sicherheitstests von Webanwendungen, führt keinen echten Angriff aus: Er beobachtet die Antworten der Website und meldet zum Beispiel einen fehlenden Sicherheitsheader. Laut seiner Dokumentation eignet er sich für eine Pipeline und sogar für eine Produktionswebsite. Ein aktiver Scan, der echte Angriffe sendet, wird nur auf einer Testumgebung ausgeführt, nie auf der Produktion.
Fuzzing schickt dem Programm unerwartete oder zufällige Daten, um zu sehen, ob es sie falsch verarbeitet. Das NIST nennt es unter seinen Beispielen. Unserer Ansicht nach ist es für eine gewöhnliche Webanwendung nicht nötig; sinnvoll ist es für Code, der von außen empfangene Daten liest und interpretiert, etwa ein Dateiformat.
Prüfen, dass kein Secret in den Code gelangt. Wir raten zu einem Werkzeug zur Erkennung von Secrets, etwa gitleaks, das jede Änderung prüft, bevor sie committet und gepusht wird; die Pipeline durchsucht danach die gesamte Historie des Codes, falls diese erste Prüfung umgangen wurde. OWASP empfiehlt, Secrets zu erkennen, noch bevor eine Änderung committet wird, und dafür mehr als ein Werkzeug einzusetzen. Ein versehentlich committetes Secret wird widerrufen und ersetzt: OWASP verlangt, dass ein offengelegter Schlüssel sofort widerrufen wird.
Alles Vorangegangene beruht auf derselben Fähigkeit: einen Patch noch am selben Tag in Produktion zu bringen, ohne etwas kaputt zu machen. Diese Fähigkeit lässt sich am Tag der Warnmeldung nicht improvisieren. Sie hängt davon ab, wie die Software im Alltag ausgeliefert wird.
Erfahrungsgemäß kommt eine kritische Lücke in einer Organisation, in der jedes Deployment in die Produktion selten ist (ein Abend pro Quartal, Tests von Hand, mehrere Personen im Einsatz), außer der Reihe. Man muss außerhalb des Zeitplans eine Notfallkorrektur aufsetzen, die Personen zusammenholen, die deployen können, die Tests von Hand wiederholen, ein Wartungsfenster reservieren, manchmal die Zustimmung eines Gremiums einholen. Der Patch wird zum Projekt, und in der Zwischenzeit bleibt die Anwendung ungeschützt. Dieser Auslieferungsrhythmus verleitet dazu, direkt auf dem Server von Hand zu korrigieren. In Continuous Delivery lehnen Jez Humble und Dave Farley diese Abkürzung unumwunden ab: Bei einem kritischen Fehler „umgehen Sie unter keinen Umständen Ihren Prozess“. Sie erinnern auch daran, dass es manchmal besser ist, zur vorherigen Version zurückzukehren, als eine Korrektur zu deployen. Eine von Hand in der Produktion vorgenommene Korrektur ist nicht getestet, kann das Problem verschlimmern und wird oft nirgends festgehalten.
Das Problem geht über ein einzelnes Framework hinaus. Es betrifft alle prädiktiven Ansätze, das V-Modell ebenso wie die als agil präsentierten Frameworks, sobald eine Funktion mit zugleich festgelegtem Umfang, Budget und Termin zugesagt und dann in einen Zeitplan eingetragen wird, der auf Schätzungen beruht. SAFe (Scaled Agile Framework) zum Beispiel plant die Arbeit in Intervallen von acht bis zwölf Wochen, mit Zielen und Lieferterminen für jedes davon. Diese Organisationen sehen Notfallkorrekturen vor, die Vorrang vor allem anderen haben. Jede davon bleibt dennoch eine Ausnahme vom Zeitplan: Sie nimmt einen weniger erprobten Weg als die geplanten Lieferungen und verschiebt, was zugesagt war. In Accelerate erinnern Nicole Forsgren, Jez Humble und Gene Kim daran, dass kurze Durchlaufzeiten auch wichtig sind, „wenn ein Fehler oder ein Ausfall auftritt und wir schnell und mit großer Sicherheit eine Korrektur ausliefern müssen“.
Dabei nimmt die ungeplante Arbeit immer mehr Raum ein: mehr veröffentlichte Lücken, also mehr Patches, die nicht warten können. Die KI schafft die Schwächen dieser Organisationen nicht: Sie nutzt sie schneller aus. Amazon schreibt: „Eine Frist von 7 oder 30 Tagen geht von einer Schonfrist aus, die es nicht mehr gibt“, und das NCSC fordert die Organisationen auf, sicherzustellen, dass ihre „Prozesse und ihre Risikobereitschaft häufige Updates in großem Umfang zulassen“.
Aus unserer Sicht gefährdet diese prädiktive Arbeitsweise vor allem die Organisationen, die an ihr festhalten: Jeder dringende Patch bringt einen Zeitplan durcheinander, der keinen Platz für ihn vorgesehen hatte, und in der Zwischenzeit bleibt das System ungeschützt. In einem adaptiven Ansatz entwickelt sich der Umfang nach den Prioritäten, und mit Continuous Delivery zieht der Patch an allem anderen vorbei und nimmt noch am selben Tag denselben Weg wie jede andere Änderung. In ihrer Umfrage stellen die Autoren von Accelerate fest, dass die leistungsstärksten Organisationen in der Softwareauslieferung doppelt so häufig wie die anderen angeben, ihre Ziele bei Rentabilität und Marktanteil übertroffen zu haben.
Um einen Patch einzuspielen, muss man das System deshalb nicht Experten für Cybersicherheit überlassen. Das gehört zur täglichen Arbeit des Teams, das die Anwendung entwickelt: Es aktualisiert die betroffene Komponente, die Deployment-Pipeline prüft die Änderung mit den automatisierten Tests und bringt sie dann in Produktion. DORA fordert, Sicherheit „in die tägliche Arbeit“ über den gesamten Lebenszyklus der Softwareauslieferung zu integrieren, denn „Sicherheit liegt in der Verantwortung aller“.
Mit Continuous Delivery, praktiziert im Rahmen eines adaptiven Ansatzes, bei dem die Software laufend anhand ihrer Nutzung angepasst wird, ist derselbe Patch eine Änderung wie jede andere. Jez Humble definiert Continuous Delivery als „die Fähigkeit, Änderungen aller Art, einschließlich neuer Funktionen, Konfigurationsänderungen, Bugfixes und Experimente, sicher, schnell und nachhaltig in Produktion oder in die Hände der Nutzer zu bringen“ (continuousdelivery.com). Dave Farley stellt klar, dass die Deployment-Pipeline „der EINZIGE Weg in die Produktion“ ist: Jede Änderung durchläuft sie, das PHP-Update wie die neue Funktion. Die Änderung durchläuft dieselben automatisierten Tests und geht dann in Produktion. Da jede Änderung diesen Weg nimmt, ist das Verfahren bereits erprobt, wenn ein Patch kommt.
Diese Disziplin verändert auch die Art, das Projekt zu steuern. Eine kritische Lücke wird nicht für das Ende der Woche eingeplant: Sie hat Vorrang vor allem anderen, noch am selben Tag. Ein Team, das die Disziplin von Continuous Delivery einhält, kann seine Prioritäten innerhalb eines Tages ändern, je nachdem, was eintrifft, weil nichts von dem, was gerade in Arbeit ist, die Auslieferung des Patches in die Produktion blockiert.
Damit nichts, was noch in Arbeit ist, den Patch aufhält, empfehlen Jez Humble und Dave Farley, dass alle ihre Änderungen auf dem Hauptzweig einchecken und dass man „neue Funktionalität verbirgt, bis sie fertig ist“: Das ist Trunk-Based Development, bei dem alle ihre Arbeit in einen einzigen Branch integrieren, mehrmals am Tag. Ein dringender Patch folgt dann demselben Weg wie alles andere, ohne auf das Ende einer Funktion warten zu müssen. Um eine unfertige Funktion zu verbergen, genügt eine Konfigurationseinstellung; dieselben Autoren verlangen, diese Einstellungen zu entfernen, sobald sie ihren Zweck erfüllt haben. Es ist eine Praxis von Continuous Delivery, mit der sich Sicherheitsrahmenwerke nicht befassen.
Wir raten, die Anwendung von der Pipeline nur einmal bauen zu lassen und dann dasselbe Archiv auf jede Umgebung zu deployen. „Jedes Mal, wenn Sie den Code kompilieren, riskieren Sie, einen Unterschied einzuführen“, schreiben Jez Humble und Dave Farley. Die Regel gilt auch für PHP, das nicht kompiliert wird. Das Archiv enthält den Code, die von Composer installierten Komponenten und die statischen Dateien; es geht in Produktion, und auf dem Server selbst wird nichts installiert. Nach jedem Deployment prüft ein Smoke Test, ein kurzer Test, ob die Anwendung antwortet. Ein Rollback bedeutet dann, das vorherige Archiv erneut zu deployen, was dieselben Autoren oft als den einfachsten Weg bezeichnen. Die Daten setzen dem Grenzen: Eine Datenbank, die die neue Version verändert hat, kehrt nicht von selbst in ihren vorherigen Zustand zurück.
DORA (DevOps Research and Assessment), das Forschungsprogramm von Google Cloud zur Entwicklung und Auslieferung von Software, misst, was diese Praxis verändert. DORA misst die Zeit bis zum Einspielen eines Patches nicht direkt. Die nächstliegende Kennzahl ist die Durchlaufzeit einer Änderung, von dem Moment, in dem sie in den Code eingecheckt wird, bis zu dem Moment, in dem sie in Produktion ist. In Modern Software Engineering stellt Dave Farley eine verwandte Frage: Wie lange dauert es, bis eine Änderung von einer einzigen Zeile von der Idee zur funktionierenden Software gelangt? Aus unserer Sicht ist diese Zeit auch die Zeit, die es braucht, um den nächsten Sicherheitspatch einzuspielen. Die Forschung von DORA zeigt regelmäßig, dass „Geschwindigkeit und Stabilität keine Zielkonflikte sind“ (DORA). Laut einer Zusammenfassung des Berichts 2024, veröffentlicht von Octopus Deploy, einem Anbieter von Deployment-Werkzeugen, bringen die leistungsstärksten Teams eine Änderung in weniger als einem Tag in Produktion und erholen sich von einem fehlgeschlagenen Deployment in weniger als einer Stunde (Octopus Deploy, DORA-Bericht 2024).
Gremien zur Freigabe von Änderungen gleichen eine langsame Auslieferung nicht aus. In Modern Software Engineering zitiert Dave Farley die im Buch Accelerate veröffentlichten Forschungsergebnisse: „Die Freigabe durch eine externe Instanz, etwa einen Vorgesetzten oder ein Change Advisory Board, erhöht die Stabilität der Produktionssysteme schlicht nicht […] Sie ist sogar schlechter, als überhaupt keinen Freigabeprozess für Änderungen zu haben.“
Auch bei der Sicherheit gibt es eine Frist. Die OWASP warnt in ihrer Rangliste 2025 der zehn kritischsten Risiken für Webanwendungen vor einem monatlichen oder vierteljährlichen Patch-Rhythmus: Die Exposition „tritt häufig in Umgebungen auf, in denen das Einspielen von Patches eine monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle ist, was Organisationen tage- oder monatelang für bereits behobene Lücken angreifbar lässt“. Die Zeit bis zur Ausnutzung ist auf wenige Tage gefallen. Bei Angriffen, die manchmal beginnen, bevor der Patch veröffentlicht ist, reicht ein monatlicher Rhythmus als Ziel nicht mehr aus. Die Prüfung der Patches zwingt nicht dazu, einen Monat zu warten: Automatisierte Tests in der Pipeline leisten sie bei jeder Änderung.
Jamie Dimon, Vorstandschef von JPMorgan Chase, hat im Oktober 2026 auf zwei Risiken hingewiesen: KI-Agenten, die auf den Bankkonten ihrer Nutzer handeln, und KI-Werkzeuge, die Hunderte schwerer Lücken in Open-Source-Code aufdecken, was ganze Branchen „völlig schutzlos“ lasse. Derzeit gewährt seine Bank externen KI-Agenten auf den Konten ihrer Privatkunden nur Lesezugriff.
Bei den Lücken, die die KI früher aufdeckt, setzt Continuous Delivery bei der Dauer bis zum Einspielen des Patches an. Schon 2010 verlangten Jez Humble und Dave Farley in Continuous Delivery, schnell eine neue Version veröffentlichen zu können, „falls kritische Fehler oder Sicherheitslücken entdeckt werden“. Sie verlangten auch, dass die Produktion „vollständig gesperrt“ ist, damit nur die Deployment-Pipeline dort Änderungen vornehmen kann. Mit diesen Praktiken und denen aus dem Abschnitt über die Art der Auslieferung geht der Patch für eine von einer KI gefundene Lücke wie jede andere Änderung in Produktion. Aus unserer Sicht verkürzt Continuous Delivery die Zeit, in der eine Lücke, für die es bereits einen Patch gibt, bei Ihnen ausnutzbar bleibt; Lücken zu finden und Angriffe zu stoppen ist Sache der übrigen Praktiken, die dieser Artikel beschreibt.
Das andere Risiko, das Jamie Dimon beschreibt, ist eine Frage der Zugriffsrechte: ob ein Agent tatsächlich für die Person handelt, die ihn autorisiert hat, bei einer Bank wie bei jeder anderen Anwendung. Die OWASP zählt „übermäßige Autonomie“ zu den Risiken von KI-Anwendungen, und das NCSC fordert, auf Agenten das Prinzip der minimalen Rechte anzuwenden. Wenn Ihre Anwendung KI-Agenten für Ihre Nutzer handeln lässt, raten wir wie die OWASP, ihnen nur die nötigsten Rechte zu geben, sie im Kontext des betreffenden Nutzers handeln zu lassen und Aktionen mit großer Tragweite von einem Menschen freigeben zu lassen.
An dem Tag, an dem eine Lücke Ihre Software betrifft, umfasst das Vorgehen acht Schritte. Es stützt sich auf unsere Praxis und auf den Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“ des IT-Grundschutz-Kompendiums des BSI. Lesen Sie diese Schritte am besten vorher, und legen Sie fest, wer was übernimmt.
Die ersten drei Schritte hängen von der Lücke ab. Bei PHP2Shell heißt das: klären, ob Sie betroffen sind, aktualisieren oder isolieren, dann nach Spuren eines Eindringens suchen. Die folgenden fünf gelten für jede Lücke.
4. Beweise sichern, bevor man aufräumt. Wir raten, die Logs der Firewall, des Reverse Proxys und der betroffenen Server zu sichern und eine vollständige Kopie der angegriffenen Maschine und ihres Arbeitsspeichers anzufertigen. Wer vor dieser Kopie eine saubere Version neu deployt, vernichtet genau die Spuren, die zeigen würden, was passiert ist.
5. Alle Secrets ändern, die auf dem Server lagen. Wir raten, die Datenbankpasswörter zu ändern, die Schlüssel der Anwendung (Schlüssel und Salts von WordPress, APP_KEY von Laravel, Verschlüsselungsschlüssel von Magento), die Zugangsschlüssel zu Drittdiensten (Zahlung, E-Mail-Versand, Speicher), die Konten für den Nachrichtenversand, die auf dem Server vorhandenen Deployment-Token, die privaten Schlüssel der Zertifikate und die Administratorkonten, und die offenen Sessions zu beenden. Die neuen Secrets werden in einer sauberen Umgebung erzeugt und nur auf dem Server deployt, der im nächsten Schritt neu aufgebaut wird, nie auf dem noch kompromittierten Server. CosmicSting hat es gezeigt: Ein vor dem Patch gestohlener Schlüssel bleibt danach gültig, und Sansec empfiehlt, den Verschlüsselungsschlüssel zu ersetzen und den alten ungültig zu machen. Ändert man den Schlüssel der Anwendung, werden alle Nutzer abgemeldet; das ist so gewollt. Vorsicht dagegen bei Daten, die mit dem alten Schlüssel verschlüsselt wurden: Sie werden unlesbar, es sei denn, der alte Schlüssel bleibt zum Entschlüsseln verfügbar oder die Daten werden mit dem neuen neu verschlüsselt. Laravel erlaubt es, frühere Schlüssel zum Entschlüsseln zu behalten (APP_PREVIOUS_KEYS), und Adobe stellt für Magento ein Verfahren zum Schlüsselwechsel und einen Befehl zum Neuverschlüsseln der Daten bereit.
6. Wurde der Server kompromittiert, aus einer sauberen Quelle neu aufbauen. Wir raten davon ab, das alte Server-Image oder den alten Code wiederherzustellen, die die Web Shell enthalten können. Mit einer Pipeline baut man den Server und die Anwendung aus dem Code-Repository neu auf, in einer sauberen Version, mit dem Patch. Die Daten sollten aus unserer Sicht aus einem Backup wiederhergestellt werden, das älter ist als der früheste mögliche Zeitpunkt des Eindringens. Hier machen die getesteten Offline-Backups den Unterschied. Wir raten danach zu einer schrittweisen Wiederinbetriebnahme, nachdem sichergestellt ist, dass die Lücke behoben ist.
7. Melden. Könnten personenbezogene Daten eingesehen, verändert oder vernichtet worden sein, muss der Vorfall innerhalb von 72 Stunden der zuständigen Datenschutz-Aufsichtsbehörde Ihres Bundeslandes gemeldet werden; diese Frist schreibt die DSGVO vor. Melden Sie den Schaden auch Ihrer Versicherung. Für Unterstützung raten wir, einen qualifizierten Dienstleister für die Reaktion auf Sicherheitsvorfälle hinzuzuziehen. Im Notfall erreichen Sie die Polizei unter der 110.
8. Lehren ziehen. Die Frage stellen: Was haben wir gelernt? Wie lange hat es gedauert, den Patch einzuspielen, und warum? Für diese Zeit misst DORA die nächstliegende Kennzahl, weiter oben vorgestellt: Je kürzer sie im Alltag ist, desto früher nach seiner Veröffentlichung wird der nächste Patch eingespielt. Was hat es ermöglicht, oder hätte es ermöglicht, den Angriff zu bemerken?
Ein Sicherheitspatch ist eine Änderung wie jede andere: Er durchläuft dieselbe Pipeline wie der Rest. Wir suchen nicht nach Lücken; diese Suche ist Sache der Forscher. Unsere Aufgabe ist es, zu begrenzen, was ein Angreifer über die nächste Lücke erreichen kann, alarmiert zu werden, sobald sie ausgenutzt wird, und ihren Patch einzuspielen, sobald er veröffentlicht ist.
Dasselbe Team entwickelt, testet, deployt und wartet Ihre Software laufend, in derselben Pipeline. Jedes Produktions-Deployment durchläuft eine Deployment-Pipeline: Sicherheit und Barrierefreiheit werden automatisch geprüft, bevor eine Änderung die Produktion erreicht, und die Performance wird in der Produktion überwacht. Wir bringen eine Änderung nach der anderen in Produktion, nachdem die Pipeline sie geprüft hat. Bei einem Vorfall kehren wir zur vorherigen Version zurück.
Für die Anwendungen, die wir entwickeln, setzen wir mit einer Deployment-Pipeline Folgendes um. Jede Abhängigkeit ist mit ihrer exakten Version eingetragen. Eine gerade erst veröffentlichte Version wird erst nach drei Tagen übernommen, außer dem Patch für eine schwere Lücke: Dann heben wir diese Wartezeit im Einzelfall auf und installieren ihn, sobald er veröffentlicht ist. Jeden Morgen prüft ein geplanter Job, ob eine bekannte Lücke die eingesetzten Komponenten betrifft. Wir richten auch das Monitoring der Server ein, mit Alarmen für die weiter oben beschriebenen Signale. Ein Update von PHP oder einer Komponente durchläuft dieselbe Pipeline wie der Rest.
Sicherheitspatches und Abhängigkeitsaktualisierungen gehören zur Wartung, die in unserem Angebot inbegriffen ist: individuelle Software mit festem Monatsbudget, mit einer Null-Regressions-Garantie.
Außerdem bieten wir Audits der Software-Produktionskette und Schulungen für technische Teams an. Das Audit prüft, ob eine in Ihrer Software entdeckte Sicherheitslücke noch am selben Tag behoben und an Ihre Kunden ausgeliefert werden kann, und was noch umzusetzen ist.
Ein Sicherheitsupdate erreicht die Produktion noch am Tag seiner Veröffentlichung, wenn jede Änderung dort bereits in kleinen Schritten ankommt. Unser Artikel über Continuous Delivery und Continuous Deployment erklärt, wie das funktioniert, und unser Artikel über den prädiktiven oder adaptiven Ansatz, warum diese Art der Auslieferung zu einem adaptiven Ansatz gehört.
Wenn Sie eine Anwendung übernehmen möchten, deren Sprache oder Komponenten nicht mehr gepflegt werden, erklärt unsere Seite zur Übernahme und Modernisierung von Anwendungen, wie wir vorgehen.
Sie möchten eine Anwendung entwickeln lassen oder wieder in den Griff bekommen? Sprechen wir darüber?
save-prefix, save-exact, min-release-age).allow-plugins, platform, audit) und „Scripts“.
Was ist Schatten-IT? Die Definition des britischen Cybersicherheitszentrums, Beispiele (Excel, KI-Werkzeuge), die Risiken für das Unternehmen und warum die Antwort ein Werkzeug ist, das zur Arbeit passt.
Sollte man die automatischen Updates von WordPress aktivieren oder deaktivieren? Wir raten von denen ab, die WordPress selbst und ohne jeden Test bei Plugins und Themes einspielt. Ein Hoster, der jedes Update vor dem Einspielen testet, kann sie übernehmen; ohne ihn aktualisieren Sie ein Plugin nach dem anderen und prüfen dann die Website.
Am 21. Oktober 2026 hat PHP zwei kritische Sicherheitslücken geschlossen, zeitgleich mit GitLab und Node.js. Wer betroffen ist, was noch am selben Tag zu tun ist, und wie sich der Schaden einer Lücke begrenzen lässt.