Ungepatchte Systeme gehören zu den häufigsten Ursachen für Sicherheitsvorfälle und vermeidbare Ausfälle. Technisch sind Patches meist verfügbar – organisatorisch fehlen aber oft Inventar, Priorisierung, Wartungsfenster, Automatisierung und ein Rollback‑Plan. Effektives Patch‑Management ist deshalb vor allem ein Prozess‑ und Betriebsmodell, nicht nur ein Tool.

Dieser Artikel beschreibt ein praxistaugliches Patch‑Management‑Setup: von Inventarisierung über risikobasierte Priorisierung bis zu gestaffelten Rollouts, Verifikation, Reporting und Zero‑Day‑Handhabung.

Warum Patch‑Management in der Praxis schwer ist

Typische Gründe:

Skalierung: Hunderte Systeme, tausende Packages, unterschiedliche Plattformen.

Betriebsfenster: 24/7‑Services mit sehr kleinen Wartungsfenstern.

Abhängigkeiten: Legacy‑Software, harte Versionbindungen, fehlende Tests.

Ownership: Unklar, wer Patch‑Risiko trägt (Ops? App‑Team? Security?).

Fehlende Observability: Nach Updates ist unklar, ob das System wirklich gesund ist.

Ohne Observability und Incident‑Prozess wird Patchen zur Angst‑Entscheidung:

Monitoring & Observability

SLA, SLO & Incident Response

Schritt 1: Inventar und Sichtbarkeit („Sie können nur patchen, was Sie kennen“)

Ein Patch‑Programm braucht ein verlässliches Systeminventar:

Hosts/VMs/Cluster, OS‑Versionen, Kernel‑Stände

installierte Pakete/Dependencies (inkl. EOL‑Stände)

Applikationszuordnung (welcher Service läuft wo?)

Kritikalität/Schutzbedarf (Priorisierung)

Vulnerability Scanner können die Sichtbarkeit erhöhen, ersetzen aber keine Ownership:

OpenVAS/Greenbone: https://www.greenbone.net/en/

Nessus: https://www.tenable.com/products/nessus

Schritt 2: Priorisierung – CVSS reicht nicht

CVSS ist ein Startpunkt, aber nicht ausreichend. Sinnvoll ist eine risikobasierte Priorisierung entlang dieser Fragen:

Ist die Schwachstelle exploitable (Proof‑of‑Concept, Exploit in the wild)?

Ist das System exponiert (Internet‑Facing, privilegierter Zugriff)?

Was ist der Impact (RCE, Privilege Escalation, Data Exfiltration)?

Welche Kompensationsmaßnahmen existieren (WAF, Segmentierung, Feature Toggle)?

Pragmatische Patch‑SLAs (Beispiel, je nach Kontext):

kritisch + exploitable + exposed: 24–72h

hoch: 7 Tage

mittel: 30 Tage

niedrig: im regulären Zyklus

Schritt 3: Rollout‑Strategie – gestaffelt statt „alles am Patchday“

Großflächige Updates „in einem Rutsch“ erhöhen Risiko. Bewährt haben sich gestaffelte Rollouts:

Canary‑Gruppe (wenige Systeme, repräsentativ)

Welle 1 (z. B. 10–20%)

Welle 2 (Rest)

Wichtig: Rollouts brauchen klare Stop‑Kriterien (Fehlerrate, Latenz, Health Checks) und einen Rollback‑Pfad.

Schritt 4: Automatisierung – damit Patchen Routine wird

Automatisierung reduziert Fehler und senkt Kosten:

Config Management für Baselines und Orchestrierung

- Automatisiertes Config-Management

IaC für reproduzierbare Umgebungen und kontrollierte Changes

- Infrastructure as Code

Beispiele für Plattformen/Mechanismen:

Windows: WSUS/SCCM (je nach Umgebung)

Linux: unattended upgrades, repo policies, zentrale Orchestrierung

Kubernetes/Container: Image‑Rebuilds + Rolling Deployments (statt „Paket im Container patchen“)

Schritt 5: Verifikation – „gepatcht“ heißt nicht „gesund“

Nach dem Patch ist vor dem Incident, wenn Health nicht messbar ist. Bewährt sind:

Smoke Tests nach jedem Rollout‑Schritt

SLO‑/Error‑Budget‑Signale als Guardrail

automatisierte Checks auf zentrale Funktionen (Login, Checkout, API‑Calls)

Für viele Teams ist das der Punkt, an dem CI/CD‑Standards helfen:

CI/CD-Pipeline-Aufbau

Schritt 6: Reboots, Kernel‑Updates und „downtime‑sensitive“ Systeme

Ein Klassiker sind Kernel‑ und Low‑Level‑Updates, die einen Reboot erfordern. Hier braucht es klare Betriebsregeln:

Wartungsfenster pro Service/Cluster

HA‑Design (Rolling Reboots, Failover)

Kommunikation und Stakeholder‑Freigaben, wo nötig

Live‑Patching kann in bestimmten Fällen helfen, ersetzt aber nicht das Gesamtkonzept:

Ksplice (Oracle): https://www.oracle.com/linux/support/ksplice/

KernelCare: https://www.tuxcare.com/kernelcare/

Schritt 7: Legacy und End‑of‑Life – sauber adressieren

EOL‑Systeme lassen sich nicht „wegpatchen“. Optionen:

Upgrade/Migration priorisieren (Roadmap, Abhängigkeiten)

Segmentierung, Monitoring, restriktive Zugriffe als Kompensation

virtual patching (WAF/IDS/IPS) als Zwischenlösung

Spätestens hier wird Security/Compliance‑Beratung relevant:

Security & Compliance Beratung

Reporting: Patch Compliance als Steuerungsgröße

Ein Patch‑Programm braucht Transparenz:

Patch Compliance pro Gruppe (kritisch/hoch/mittel)

Mean Time to Patch (MTTP)

Anteil EOL‑Systeme

wiederkehrende Ausnahmen (warum werden Systeme nicht gepatcht?)

Incident‑Korrelation (wie viele Incidents sind patch‑getrieben?)

Solche Reports sind auch hilfreich für Management und Audit‑Nachweise.

Zero‑Days: Notfallprozess statt Ad‑hoc‑Aktionismus

Für Zero‑Days sollte es ein vorab definiertes Vorgehen geben:

schnelle Risiko‑Einordnung (exposed? exploitable? kompensierbar?)

definierter Kommunikationsweg und Verantwortlichkeiten

gestaffelter Rollout mit engmaschiger Verifikation

Postmortem: Welche Controls hätten früher geholfen (z. B. Segmentierung, WAF)?

Container und Dependencies: Patchen heißt oft „neu bauen“

In containerisierten Umgebungen ist Patchen häufig kein „apt upgrade im Container“, sondern:

Base Images aktualisieren (oder wechseln), Images neu bauen und neu deployen,

Dependency Updates (z. B. Libraries) automatisieren und testen,

SBOM/Scans nutzen, um betroffene Artefakte schnell zu identifizieren,

Rollouts gestaffelt fahren (Canary/Rolling) und per Observability verifizieren.

Das reduziert Drift und macht Updates reproduzierbar – vorausgesetzt CI/CD und Image‑Standards sind etabliert.

FAQ

Wie setzt man Patch-SLAs sinnvoll fest?

Risikobasiert: Kritikalität, Exploitability und Exponiertheit sind wichtiger als „alles innerhalb von 7 Tagen“. Patch‑SLAs müssen zudem zum Wartungsfenster‑ und Rollout‑Modell passen, sonst werden sie systematisch gebrochen.

Was macht man mit End-of-Life Systemen?

EOL ist ein Risiko, das man aktiv managen muss: Upgrade/Migration priorisieren, segmentieren, Zugriffe reduzieren und Monitoring verschärfen. „Weiterlaufen lassen“ ohne Kompensation ist selten vertretbar.

Wie häufig sollte man patchen?

Regelmäßige, kleine Zyklen sind meist besser als seltene „Patch‑Großereignisse“. Ergänzt wird das durch einen Zero‑Day‑Prozess für kritische Fälle.

Fazit

Gutes Patch‑Management macht Updates planbar: Inventar und Ownership sind klar, Priorisierung ist risikobasiert, Rollouts sind gestaffelt, Verifikation ist automatisiert und Reporting macht Fortschritt sichtbar. So werden Security Updates zur Routine – und nicht zum wiederkehrenden „Downtime‑Drama“.

Wartung & Patch-Management: Systeme sicher halten