Patch Management

Eine ungepatchte Sicherheitslücke hat ausgereicht, um 2017 mit WannaCry hunderttausende Systeme weltweit lahmzulegen. Der Patch existierte seit Wochen — nur eingespielt hatte ihn kaum jemand. Patch Management ist die systematische Antwort auf dieses Problem: der Prozess, mit dem Softwareupdates identifiziert, bewertet, getestet und ausgerollt werden. Für Unternehmen, die Individualsoftware betreiben, ist Patch Management keine optionale Best Practice, sondern eine Pflicht.
Ein großes Office. Ein IT-Support-Mitarbeiter sitzt am Notebook neben der Chefin. Er berät sie zum Patch Management.
© insta_photos

Was ist Patch Management?

Patch Management bezeichnet einen zentralen Prozess im IT-Service-Management, bei dem Softwareupdates — sogenannte Patches — identifiziert, bewertet, getestet und auf Produktivsystemen eingespielt werden. Das Ziel: Sicherheitslücken schließen, Fehler beheben und die Stabilität von Anwendungen gewährleisten.

Der Begriff „Patch” (englisch für Flicken) kommt aus einer Zeit, in der fehlerhafte Stellen in Lochkarten tatsächlich physisch überklebt wurden. Heute bezeichnet ein Patch ein Softwareupdate, das gezielt ein bestimmtes Problem behebt — im Unterschied zu einem vollständigen Release, das neue Funktionen und umfassende Änderungen enthält. Wie Patch Management in den größeren Kontext von ITSM-Prozessen eingebettet ist, zeigt unser Leitfaden zum IT-Service-Management.

Welche Patch-Typen gibt es?

Nicht jeder Patch ist gleich. Die Unterscheidung nach Typ bestimmt die Priorität und den Rollout-Prozess.

Sicherheitspatches schließen bekannte Schwachstellen (Vulnerabilities). Sie haben die höchste Priorität, weil jede Verzögerung das Angriffsfenster vergrößert. Kritische Sicherheitspatches — etwa mit einem CVSS-Score von 9.0 oder höher — sollten innerhalb von 24 bis 72 Stunden eingespielt werden.

Bugfix-Patches beheben funktionale Fehler, die den Betrieb beeinträchtigen, aber kein unmittelbares Sicherheitsrisiko darstellen. Ein Berechnungsfehler in einer Geschäftslogik, ein Darstellungsproblem in der Oberfläche oder ein Speicherleck, das die Performance langsam degradiert.

Hotfixes sind dringende Patches, die außerhalb des regulären Update-Zyklus deployt werden — typischerweise als Reaktion auf einen kritischen Produktionsfehler. Sie durchlaufen einen verkürzten Testprozess, weil die Dringlichkeit eine vollständige Testrunde nicht erlaubt.

Feature-Patches fügen neue Funktionalität hinzu oder erweitern bestehende. Sie sind in der Regel weniger dringend und können im normalen Release-Zyklus eingeplant werden.

Der Patch-Management-Prozess in fünf Schritten

1. Identifikation

Welche Patches sind verfügbar? Bei Standardsoftware informiert der Hersteller über neue Updates. Bei Individualsoftware müssen die Abhängigkeiten — Frameworks, Libraries, Laufzeitumgebungen — aktiv überwacht werden. Tools wie Dependabot, Snyk oder npm audit scannen die Abhängigkeiten automatisch und melden bekannte Schwachstellen.

2. Bewertung und Priorisierung

Nicht jeder Patch muss sofort eingespielt werden. Die Priorisierung richtet sich nach der Schwere der Schwachstelle (CVSS-Score), der Erreichbarkeit des betroffenen Systems (öffentlich vs. intern) und der Auswirkung auf den Geschäftsbetrieb. Ein Sicherheitspatch für eine öffentlich erreichbare Web-Applikation hat eine andere Dringlichkeit als ein Bugfix für ein internes Reporting-Tool.

3. Test

Vor dem Rollout auf die Produktionsumgebung wird der Patch in einer Staging-Umgebung getestet. Funktioniert die Anwendung noch wie erwartet? Sind Regressionen ausgeschlossen? Bei Individualsoftware ist dieser Schritt besonders wichtig, weil kein Hersteller die Kompatibilität mit der eigenen Codebasis garantiert. Automatisierte Tests — Unit-Tests, Integrationstests, End-to-End-Tests — verkürzen diese Phase erheblich.

4. Rollout

Der Patch wird auf der Produktionsumgebung eingespielt. Idealerweise geschieht das in einem definierten Wartungsfenster mit vorheriger Benachrichtigung der Nutzer. Bei kritischen Sicherheitspatches kann das Wartungsfenster verkürzt werden. Der Rollout sollte dokumentiert werden: Was wurde wann von wem eingespielt?

5. Verifizierung und Monitoring

Nach dem Rollout wird geprüft, ob der Patch korrekt angewendet wurde und die Anwendung stabil läuft. Monitoring-Systeme überwachen in den ersten Stunden und Tagen nach dem Update besonders aufmerksam Performance-Indikatoren und Fehlerquoten. Tritt ein Problem auf, muss ein Rollback-Plan bereitstehen.

Patch Management und Compliance

Patch Management ist nicht nur technisch sinnvoll, sondern in vielen Fällen rechtlich gefordert.

DSGVO (Art. 32): Unternehmen, die personenbezogene Daten verarbeiten, müssen „geeignete technische Maßnahmen” zum Schutz dieser Daten treffen. Dazu gehört, bekannte Schwachstellen in eingesetzter Software zeitnah zu schließen. Ein nachweislich funktionierender Patch-Management-Prozess ist im Fall einer Datenschutzverletzung ein starkes Argument gegenüber den Aufsichtsbehörden.

BSI-Grundschutz: Das Bundesamt für Sicherheit in der Informationstechnik fordert im Baustein OPS.1.1.3 explizit ein dokumentiertes Patch- und Änderungsmanagement. Für Betreiber kritischer Infrastrukturen und Behörden ist das keine Empfehlung, sondern Pflicht.

NIS-2: Die EU-Richtlinie verschärft die Anforderungen an das Schwachstellenmanagement. Betroffene Unternehmen müssen nachweisen, dass sie Patches systematisch erfassen und zeitnah einspielen.

Patch Management als Dienstleistung

Viele Unternehmen — insbesondere KMU ohne eigene IT-Sicherheitsabteilung — haben weder die Kapazität noch die Werkzeuge, um ein systematisches Patch Management selbst zu betreiben. Die Abhängigkeiten der eigenen Individualsoftware zu überwachen, Patches zu bewerten, zu testen und einzuspielen, erfordert kontinuierliche Aufmerksamkeit und technisches Know-how.

Genau hier liegt der Wert eines professionellen Wartungsvertrags: Der Dienstleister übernimmt das Patch Management als integralen Bestandteil der laufenden Wartung. Sicherheitsupdates werden systematisch erfasst, bewertet und nach Freigabe eingespielt — ohne dass der Auftraggeber jeden Patch einzeln beauftragen muss.

Der Unterschied zu einem reinen Tool-Kauf: Ein Schwachstellenscanner zeigt an, welche Patches fehlen. Ein Wartungsdienstleister spielt sie ein, testet die Anwendung und übernimmt die Verantwortung für die Stabilität. Das eine ist Diagnostik, das andere ist Behandlung.

Weiterführende Informationen