Kurz gesagt: Ein Patch-Management-Prozess legt fest, wie Updates vom Eingang bis zum Nachweis laufen: in welche Klasse ein Patch fällt, in welchem Fenster er eingespielt wird, wie getestet und zurückgerollt wird, wer neu startet und wie der Erfolg belegt wird. Routineupdates laufen planbar im Takt, Notfallpatches folgen einem vorher vereinbarten Schnellweg. So wird aus Feuerwehreinsätzen ein wiederholbarer Ablauf.
Wenn jeder Patch ein Notfall ist
Am Abend des 21.10.2026 lief in vielen Unternehmen dasselbe Muster ab. Die Patches waren da, das BSI drängte, und die Fragen begannen: Dürfen wir jetzt einfach aktualisieren? Wer testet? Wer startet die Dienste neu? Wer sagt der Geschäftsführung Bescheid, dass der Shop kurz weg ist? Und wie beweisen wir hinterher, dass es geklappt hat?
In Unternehmen ohne Prozess muss das alles im Moment geklärt werden. In Unternehmen mit Prozess steht die Antwort schon fest. Der Unterschied liegt nicht in der Technik, sondern in Absprachen, die vorher getroffen wurden.
Die Bausteine eines Patch-Management-Prozesses
Ein tragfähiger Prozess unterscheidet zuerst, wie dringend ein Patch ist. Drei Klassen genügen meist:
| Klasse | Typischer Anlass | Fenster | Test | Freigabe |
|---|---|---|---|---|
| Routine | Fehlerbehebungen, Sicherheitsupdates mit geringem Risiko | fester monatlicher Termin | Staging, Standardtests | IT, nach Plan |
| Dringend | hohe Einstufung, System öffentlich erreichbar | kurzfristig vorgezogen | verkürzt, wichtigste Abläufe | IT-Leitung |
| Notfall | kritische Lücke, Angriffe gemeldet, z. B. PHP2Shell | sofort | Rauchtest nach dem Einspielen | vorab erteilte Notfallfreigabe |
Wer welche Klasse vergibt, sollte ebenso feststehen wie die Kriterien dafür. Die Bewertung selbst gehört zum vorgelagerten Schritt, siehe Schwachstellenmanagement für den Mittelstand.
Wichtig ist die vorab erteilte Notfallfreigabe. Die Geschäftsführung entscheidet einmal in Ruhe, dass bei Notfallpatches sofort gehandelt werden darf, auch wenn das eine kurze Unterbrechung bedeutet. Im Ernstfall muss dann niemand nachts eine Zustimmung einholen.
Ebenso wichtig sind die Rollen. Für jedes System sollte feststehen, wer Updates einspielt, wer fachlich testet, ob der Shop oder das Portal danach funktioniert, und wer informiert wird. Bei ausgelagerten Systemen gehören Hoster und Agentur ausdrücklich dazu, mit Namen und Erreichbarkeit. Das feste Wartungsfenster sollte intern bekannt sein, damit Vertrieb und Kundenservice wissen, wann kurze Unterbrechungen möglich sind.
Messen Sie außerdem, wie lange Ihr Prozess tatsächlich braucht: von der Veröffentlichung eines Patches bis zum belegten Abschluss, getrennt nach Klasse. Diese eigenen Werte zeigen, wo es hakt, und machen Verbesserungen sichtbar. Ein Prozess, dessen Dauer niemand kennt, lässt sich kaum steuern.
Der Ablauf eines Patches in acht Schritten
Jeder Patch, gleich welcher Klasse, durchläuft dieselben Stationen. Nur Tempo und Testtiefe unterscheiden sich.
- Eingang: Meldung oder verfügbares Update wird erfasst, mit Datum und Quelle.
- Einstufung: Klasse festlegen, betroffene Systeme laut Inventar bestimmen.
- Vorbereitung: Backup oder Snapshot, Rückweg beschreiben, Beteiligte informieren.
- Test: in Staging oder auf einem weniger kritischen System zuerst.
- Einspielen: im vereinbarten Fenster, System für System.
- Neustart: alle betroffenen Dienste und Prozesse, nicht nur die Pakete.
- Nachweis: Paketstand, Changelog-Eintrag und Prozessstart festhalten.
- Kontrolle: Funktion prüfen, bei Sicherheitslücken zusätzlich auf Spuren eines früheren Einbruchs achten.
Schritt 6 wird erstaunlich oft vergessen. PHP lädt seinen Code beim Start der Prozesse. Solange alte PHP-FPM-Worker oder Apache-Prozesse mit mod_php laufen, arbeiten sie mit dem alten, verwundbaren Stand weiter. Warum das so ist und wie man richtig neu startet, steht unter Nach dem Update: PHP-FPM und alle Worker neu starten.
Nachweise, die später zählen
Ein Patch ohne Beleg ist im Zweifel nicht eingespielt, jedenfalls gegenüber Kunden, Versicherern oder Prüfern. Halten Sie je System fest, welcher Paketstand installiert ist, ob die CVE-Nummern im Changelog stehen und wann die laufenden Prozesse gestartet wurden. Auf Debian- und Ubuntu-Systemen helfen dabei lesende Befehle wie diese (Paketname an Ihr System anpassen):
# Enthält das installierte Paket die Korrekturen?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Wann wurden die laufenden PHP-FPM-Prozesse gestartet?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Liegt der Startzeitpunkt der Prozesse vor der Installation des Pakets, fehlt der Neustart. Ausführlich beschreibt das CVE-Nummern im Paket-Changelog nachweisen.
Ein Patch schließt eine Lücke für die Zukunft. Er entfernt keine Schadsoftware, die vorher eingeschleust wurde, und beweist nicht, dass vorher nichts passiert ist. Bei Notfallpatches gehört eine Spurensuche deshalb fest zum Ablauf.
Automatisieren, wo es sicher ist
Automatische Sicherheitsupdates für Betriebssystempakete nehmen viel Routinearbeit ab. Sie entlasten aber nur, wenn Backups vorhanden sind, jemand die Ergebnisse liest und auch die betroffenen Dienste neu gestartet werden. Wie man das unter Linux einrichtet und welche Grenzen es gibt, beschreibt Automatische Sicherheitsupdates auf Linux-Servern.
Container brauchen einen eigenen Weg. Dort wird nicht im laufenden System aktualisiert, sondern das Image mit der korrigierten PHP-Version neu gebaut und ausgerollt. Ein Patch-Prozess, der nur Server kennt, übersieht diese Systeme leicht. Nehmen Sie deshalb auch Build-Pipelines und Image-Registries in die Liste der Patchwege auf, mit einer verantwortlichen Person und demselben Nachweis wie bei klassischen Servern: Welche PHP-Version läuft im ausgerollten Container, und seit wann?
Anwendungen, CMS und Plugins brauchen meist einen eigenen, getesteten Weg, weil Updates dort häufiger Funktionen ändern. Der feste Monatstermin ist dafür der richtige Ort. Wichtig ist am Ende, dass alle Wege in derselben Dokumentation zusammenlaufen: ein Ort, an dem man sieht, welches System auf welchem Stand ist.
Wie hilft PHP SOS konkret?
- Wir schreiben mit Ihnen die Patchklassen, Fenster und Freigaben auf, passend zu Ihren Systemen und Ihrer Organisation.
- Wir richten automatische Sicherheitsupdates mit Neustartprüfung und Benachrichtigung ein, wo das sinnvoll ist.
- Wir übernehmen Notfallpatches einschließlich Neustart, Nachweis und Spurensuche über unseren PHP-Patch-Service.
- Wir führen die Nachweise je System so, dass Sie sie Kunden, Versicherern oder Prüfern vorlegen können.
Fazit: Patch-Management wirkt unspektakulär, solange es funktioniert. Genau das ist das Ziel: Wenn die nächste kritische Meldung kommt, läuft ein eingeübter Ablauf, und niemand muss improvisieren.
Häufige Fragen
Was ist der Unterschied zwischen Patch-Management und Schwachstellenmanagement?
Schwachstellenmanagement erfasst und bewertet Lücken und entscheidet, was zu tun ist. Patch-Management setzt die Entscheidung um: Updates testen, einspielen, Dienste neu starten und den Erfolg belegen. Beide greifen ineinander.
Sollten Sicherheitsupdates automatisch eingespielt werden?
Für Betriebssystempakete ist das oft sinnvoll, sofern Backups bestehen und nach dem Lauf geprüft wird. Wichtig ist, dass auch die betroffenen Dienste neu starten. Bei PHP bleiben sonst alte Prozesse mit dem verwundbaren Code im Speicher.
Wie belege ich, dass ein Patch wirklich wirkt?
Mit dem installierten Paketstand und den CVE-Nummern im Paket-Changelog, dem Zeitpunkt der Installation und dem Startzeitpunkt der laufenden Prozesse, der nach der Installation liegen muss.
Was tun, wenn ein Update etwas kaputt macht?
Dafür gibt es den Rückweg: ein Backup oder Snapshot vor dem Update und ein beschriebener Ablauf zum Zurückrollen. Bei Sicherheitsupdates sollte das Zurückrollen die Ausnahme sein und mit einer Übergangsmaßnahme verbunden werden.