Patch-Typen: Security, Bugfix, Feature, Hotfix
Wenn Microsoft am zweiten Dienstag im Monat „Patch Tuesday" durchführt oder Linux-Server apt update ausführen, fließen unterschiedliche Arten von Code-Änderungen aus den Repositorys auf die produktiven Systeme. Manche schließen Sicherheitslücken (höchste Dringlichkeit, oft mit eigenen CVE-Nummern), andere beheben Fehlfunktionen, andere bringen neue Funktionen, manche werden zwischen den Wartungs-Terminen außerplanmäßig herausgegeben. Die Unterscheidung dieser Patch-Typen ist nicht nur akademisch – sie bestimmt, wie schnell ein Patch eingespielt werden muss, welcher Change-Typ nötig ist und welche Tests vorher laufen sollen. Diese Lektion zeigt dir die vier Hauptkategorien und ein paar weniger bekannte Varianten, erklärt das Versionsnummern-Schema SemVer, das Patches eindeutig adressierbar macht, und arbeitet die Dringlichkeitslogik heraus – kritischer Security-Patch in Stunden, Feature-Update in Wochen.
1) Die vier Hauptkategorien
Klick die Patch-Typen an, um Details zu sehen:
2) Versionsnummern – Semantic Versioning
Eine Versionsnummer ist kein Zufalls-Etikett. Die meisten ernstzunehmenden Produkte folgen Semantic Versioning (SemVer): drei Zahlen, getrennt durch Punkte, jede mit eindeutiger Bedeutung. Wenn du das verstehst, weißt du sofort, ob ein Update nur kosmetisch ist oder potenziell etwas kaputtmacht. Klick die Versionssegmente an:
3) Wie schnell muss welcher Patch raus?
Die Dringlichkeit unterscheidet sich dramatisch. Faustregel: je näher am Security-Ende, desto schneller. Das ist eine Frage der CIA-Triade – jeder ungepatchte Tag erhöht das Angriffsrisiko.
🔥 Schnell raus – kurze Frist
Critical / Zero-Day Security Patch: < 72 h (CVSS ≥ 9.0)
High Security Patch: 1-2 Wochen
Hotfix für Major Incident: Stunden bis 1 Tag
→ Meistens via Emergency Change
🕓 Geplant – im Wartungsfenster
Medium/Low Security: 30-60 Tage
Bugfix (Patch-Version): 30-90 Tage
Feature-Update (Minor): 3-6 Monate Pilot
→ Meist Standard oder Normal Change
Diese Fristen sind aus typischen Security-Policies abgeleitet – z. B. fordert das BSI für KRITIS-Betreiber bei kritischen Schwachstellen die schnellstmögliche Reaktion. Die konkreten Werte legt jedes Unternehmen in seiner Patch-Policy fest, abhängig von Branche, Risikoappetit und regulatorischen Vorgaben.
4) Weitere Spezial-Begriffe
| Begriff | Bedeutung |
|---|---|
| Service Pack | Gesammelte Patches als kumulatives Paket. Microsoft-historisch, heute eher durch „Quality Updates" abgelöst. |
| Rollup / Cumulative Update | Mehrere einzelne Patches in einem Paket gebündelt. Vereinfacht das Ausrollen, da nicht 30 einzelne KB-Nummern verwaltet werden müssen. |
| LTS – Long Term Support | Version, die über Jahre Patches bekommt (z. B. Ubuntu 24.04 LTS = 5 Jahre Sicherheits-Updates). Wichtig für Server. |
| End-of-Life (EOL) | Version bekommt keine Patches mehr. Ab dem EOL-Datum keine neuen Updates – muss vor EOL migriert werden. |
| Backport | Sicherheits-Fix aus neuerer Version, der in eine ältere zurückportiert wird. Typisch bei Debian/RHEL: Paket „1.2.3-7" enthält Security-Fixes aus 1.4.x. |
| Zero-Day | Schwachstelle, die aktiv ausgenutzt wird, bevor ein Patch verfügbar ist. „Zero days warning" – die Verteidiger sind dem Angreifer hinterher. |
| N-Day | Schwachstelle, die n Tage nach Veröffentlichung des Patches noch immer aktiv ausgenutzt wird, weil Unternehmen nicht gepatcht haben. Statistisch das größere Risiko als Zero-Days. |
| Out-of-Band Patch | Patch außerhalb des regulären Zyklus (z. B. nicht am Patch Tuesday). Zeichen für hohe Dringlichkeit. |
5) Patch-Quellen
Woher kommen die Patches? Je nach System unterschiedlich:
- Microsoft: Windows Update / WSUS / Microsoft Update Catalog. Patch Tuesday (2. Dienstag im Monat) für Standard-Updates, Out-of-Band für kritische Lücken.
- Linux: Distributions-Repositorys über Paketmanager (apt, yum/dnf, zypper). Sicherheits-Repos meist getrennt vom Hauptrepo.
- macOS: Software Update via Apple-Server, oft auch über MDM-Tools (Jamf, Intune).
- Anwendungssoftware: Hersteller-Update-Service, autoupdate.exe, In-App-Updater, eigene Patch-Portale (Adobe, Oracle, SAP).
- Firmware (Drucker, Router, IoT): Hersteller-Portal, oft manuell – die größte Patch-Schwachstelle der Praxis.
- Cloud-Services (SaaS): Anbieter patcht selbst, Kunde merkt es meist nur am Release-Notes-Eintrag.
6) Wer entscheidet den Patch-Typ?
Die Klassifizierung kommt vom Hersteller – in den Release Notes oder im Security Advisory. Microsoft schreibt z. B. „Critical Security Update for Windows", Red Hat klassifiziert in „Critical / Important / Moderate / Low". Daraus leitet das Unternehmen seine eigene Behandlung ab. Bei reinen Sicherheits-Bewertungen wird oft zusätzlich der CVSS-Score herangezogen – der nimmt der subjektiven Hersteller-Bewertung etwas Spielraum.
7) Patch-Typen im Vergleichsüberblick
| Typ | Hauptziel | SLA-typisch | Change-Typ | Test-Tiefe |
|---|---|---|---|---|
| 🔒 Security | Sicherheitslücke schließen | 72 h - 30 T (je Schwere) | Standard/Emergency | kurz, fokussiert |
| 🐛 Bugfix | Fehlfunktion beheben | 30-90 Tage | Standard/Normal | regression test |
| ✨ Feature | Neue Funktionalität | 3-6 Monate Pilot | Normal | voll, UAT |
| 🚒 Hotfix | akuter Fehler beheben | Stunden | Emergency | minimal, gezielt |
8) Antipatterns
- Alle Patches gleich behandeln. Security-Patch wandert die gleiche 6-Wochen-Strecke wie ein Feature-Update durch CAB → Sicherheitslücke bleibt offen. Lösung: Patch-Klassifizierung als Pflichtfeld, Security-Schnellpfad.
- Feature-Updates als „nur Update" sehen. Major-Version-Sprung kann APIs ändern, Add-Ons brechen, Workflows kaputt machen. Tests in Test-Umgebung ist Pflicht.
- Hotfix ohne Nach-Patch. Hotfix wird aufgespielt, dann vergessen – wenn der reguläre Patch kommt, geht der Hotfix verloren oder konfligiert. Lösung: Hotfix-Tracking, in den nächsten Standardpatch integrieren.
- Backports übersehen. Admin sieht „nginx 1.18 ist alt, Version 1.25 hat den Fix" – ohne zu prüfen, dass die Distro den Fix längst in 1.18-13 zurückportiert hat. Lösung: erst Distro-Changelog lesen.
- EOL-Termine ignorieren. Windows Server 2012 läuft noch produktiv, obwohl seit 2023 EOL – jede neue CVE bleibt offen. Lösung: Lifecycle-Tracking in der CMDB.
Zusammenfassung
Vier Hauptpatch-Typen: Security (Sicherheitslücke schließen, höchste Dringlichkeit, 72 h - 30 T je nach CVSS), Bugfix (Fehlfunktion beheben, mittlere Dringlichkeit, 30-90 T), Feature (neue Funktionalität, niedrige Dringlichkeit, Monate), Hotfix (akute Reaktion, Stunden). Semantic Versioning (Major.Minor.Patch): Major-Sprung kann brechen, Minor fügt Funktionen hinzu (rückwärtskompatibel), Patch behebt Fehler. Spezial-Begriffe: Service Pack/Rollup (gesammelte Patches), LTS (Long Term Support), EOL (End-of-Life), Backport (Fix aus neuer Version in alte zurück), Zero-Day (ausgenutzt vor Patch), N-Day (ausgenutzt nach Patch, weil nicht gepatcht), Out-of-Band (außer dem regulären Zyklus). Patch-Klassifizierung kommt vom Hersteller, oft kombiniert mit eigenem CVSS-Score. Antipatterns: alle Patches gleich behandeln, Feature als Trivia unterschätzen, Hotfix vergessen, Backports übersehen, EOL ignorieren.
Verwandte Lektionen: Patch-Management-Prozess · CVE/CVSS · Change-Typen · und mehrWeitere relevante LektionenCIA-TriadeCVE/CVSS SicherheitKEDBIncident ManagementLinux PaketverwaltungCMDBWSUS