Patch-Disziplin: Warum kleine Updates großen Schaden verhindern
Viele Sicherheitsvorfälle entstehen durch verpasste Patches. Wir zeigen unsere Patch-Strategie inklusive Auto-Deploy-Grenzen.
Die unbequeme Statistik
Wer nicht patcht, lädt ein
Etwa 7 von 10 erfolgreichen Angriffen nutzen eine Schwachstelle aus, für die seit Wochen oder Monaten ein Patch existiert. Das Problem ist selten ein Zero-Day. Es ist eine offene Tür, an der ein Schild „bitte nicht eintreten“ hängt.
Die durchschnittliche Verweildauer einer CVE
Branchen-Reports der letzten zwei Jahre liegen erstaunlich nah beieinander: zwischen Bekanntwerden einer kritischen CVE und ihrer breiten Ausnutzung im freien Netz liegen typischerweise 5 bis 15 Tage. Zwischen Bekanntwerden und durchschnittlichem Patch-Zeitpunkt in mittelständischen Setups: 60 bis 120 Tage. Diese Lücke ist das Geschäftsmodell von Angreifern - und sie wird größer, je tiefer in den Abhängigkeits-Bäumen die Lücke sitzt.
Warum „wir haben kein Budget für Wartung“ teurer ist
Wer Patches verschiebt, spart genau bis zum ersten Vorfall. Ein einzelner Ransomware-Angriff in einem mittelständischen Setup kostet im Schnitt deutlich mehr als drei Jahre disziplinierter Patch-Wartung. Hinzu kommen Meldepflichten, DSGVO-Folgen, Reputations-Schaden und der unbezahlbare Vertrauens-Verlust gegenüber Kunden. Patchen ist nicht teuer. Nicht-Patchen ist teuer.
Drei Sichten
Unsere Patch-Strategie in drei Schichten
Wir behandeln Patches nicht als monolithisches Thema. Es gibt drei klar getrennte Schichten - mit jeweils eigenem Rhythmus, eigener Toleranz, eigenem Automatisierungs-Grad.
Schicht 1: das Betriebssystem
Unattended-Upgrades für Debian und Ubuntu, beschränkt auf Security-Repos. Kernel-Updates landen in der Nacht, Live-Patching wo verfügbar (Ubuntu LTS Livepatch, kpatch). Wenn ein Reboot nötig wird, planen wir ein Wartungsfenster - niemals automatisch in der Hauptlast. Standard ist Sonntag 03:00 bis 05:00 Uhr Europe/Berlin, mit vorheriger Drain-Logik im Load-Balancer.
Schicht 2: Sprach-Runtime und System-Dienste
PHP 8.5, Postgres 17, Redis, Nginx - die Patch-Releases (8.5.x) gehen automatisiert in Staging, mit voller Test-Suite und einem 24-Stunden-Soak-Test, bevor sie nach Production rollen. Minor-Versionen (8.5 auf 8.6) sind Hand-Arbeit mit Changelog-Lesen und manueller Freigabe - sie tragen oft Verhaltens-Änderungen, die Tests nicht in 100 Prozent der Fälle abdecken.
Schicht 3: Anwendungs-Abhängigkeiten
Composer- und npm-Pakete laufen über Renovate oder Dependabot. Wir teilen den Strom in drei Pull-Request-Fenster pro Woche: Montag, Mittwoch, Freitag. Patches mit Security-Label kommen sofort als eigener PR, alles andere wird gruppiert. So bleibt der Code-Review-Aufwand begrenzt und die Patches kommen nicht in Wellen, sondern in Tropfen.
Patch-Stand prüfen lassen?
Wir scannen Ihr Setup gegen aktuelle CVE-Listen - und nennen Ihnen das Risiko in Zahlen.
Wo Automatisierung aufhört
Auto-Deploy-Grenzen, die wir nie überschreiten
Automatisierung ist gut. Blind-Automatisierung ist gefährlich. Wir haben drei harte Linien, hinter denen ein Mensch mitlesen muss - sonst gar nicht.
Linie 1: keine Major-Versionen ohne Mensch
Composer- und npm-Major-Updates (z. B. Laravel 12 auf 13, Vue 3 auf 4) gehen niemals automatisch. Sie tragen Breaking Changes in der Definition. Renovate erstellt einen PR mit Changelog-Auszug, ein Engineer liest ihn, plant Migration und Tests. Auto-Merge ist hier ausgeschaltet - und bleibt ausgeschaltet.
Linie 2: keine automatischen Deploys ohne grüne Test-Suite
Jeder Patch-PR läuft durch die volle CI-Pipeline: PHPUnit-Feature-Tests, statische Analyse mit PHPStan, Linting, Pint. Erst wenn alles grün ist, kann ein Patch-Level-Update (semver patch) automatisch gemergt und nach Staging deployt werden. Production-Deploy verlangt zusätzlich eine grüne Smoke-Test-Suite gegen Staging - sonst stoppt der Roll-Out.
Linie 3: keine Deploys außerhalb des Patch-Fensters
Auto-Merges und Auto-Deploys laufen ausschließlich werktags von 09:00 bis 16:00 Uhr Europe/Berlin. Niemand will Freitag um 18 Uhr ein Auto-Deploy, das einen Bereitschafts-Engineer ins Wochenende reißt. Critical-Security-Patches haben eine eigene Eilspur - aber auch die geht über einen Menschen, nicht über ein Bot-Konto.
Patch-Prinzip
Wir wollen Patches so klein, so häufig und so vorhersagbar wie möglich. Eine große Migration alle zwei Jahre ist schlechter als hundert kleine Schritte - für die Sicherheit, für die Nerven und für das Konto.
Werkzeuge, die helfen
Tooling: composer audit, npm audit und CVE-Feeds
Wer Patches im Griff haben will, braucht eine täglich laufende, automatische Bestandsaufnahme. Manuelle Listen veralten schneller als Milch.
composer audit und npm audit als CI-Gate
In jeder Pipeline laufen `composer audit` und `npm audit --audit-level=high`. Eine bekannte Schwachstelle in einer Abhängigkeit bricht den Build - keine Diskussion. Ausnahmen werden in einer expliziten Allow-List mit Ablaufdatum dokumentiert. Wir haben Setups gesehen, in denen Audit-Warnungen seit zwei Jahren ignoriert wurden - das ist kein Risiko-Management, das ist russisches Roulette mit Strom.
CVE-Feeds für die genutzten Komponenten
Wir abonnieren CVE-Feeds für alle eingesetzten Komponenten - BSI WID, GitHub Advisory Database, debian-security-announce. Ein eigener kleiner Service korreliert eingehende CVEs gegen die SBOM (Software Bill of Materials) unserer Kunden-Setups. Wenn ein Eintrag übereinstimmt, geht ein Ticket auf, klassifiziert nach CVSS-Score und Anwendungs-Exposition.
SBOM ist kein Bürokratie-Spielzeug
Eine maschinenlesbare Liste aller eingesetzten Pakete inklusive Versionen (CycloneDX oder SPDX) ist die einzige Grundlage, um eine neue CVE in Minuten gegen die eigene Welt abzugleichen. Ohne SBOM beantwortet niemand die Frage „sind wir betroffen?“ - und am Tag eines log4shell-artigen Ereignisses zählt jede Stunde.
Eilspur
Hotfix-Patches: wenn nichts mehr warten kann
Manche CVEs sind kritisch genug, dass das normale Patch-Fenster sie nicht mehr abfängt. Dafür haben wir einen klar abgegrenzten Eil-Pfad.
Auslöser: CVSS 9.0+ und ausnutzbar
Wir aktivieren den Eilpfad, wenn drei Bedingungen zusammenkommen: CVSS-Score ab 9.0 (Critical), das Setup ist nachweislich betroffen (SBOM-Match), und es existiert öffentlicher Proof-of-Concept-Code. Dann läuft die Reaktion innerhalb von 24 Stunden - auch wenn das ein außerplanmäßiges Deploy am Samstagabend bedeutet. Kommuniziert wird im Kunden-Slack vor dem Deploy, nicht danach.
Wenn kein Patch verfügbar ist: Mitigation
Nicht jede CVE hat sofort einen Patch. Dann definieren wir eine Mitigation: Web-Application-Firewall-Regel im Cloudflare-Setup, abgeschalteter Endpoint, temporäre Konfig-Änderung. Eine Mitigation ist eine Krücke, kein Heilmittel - sie wird dokumentiert, mit Ablaufdatum versehen und automatisch entfernt, sobald der echte Patch deployt ist.
Postmortem auch bei Beinahe-Vorfällen
Jeder Hotfix-Vorgang endet mit einem kurzen Postmortem: warum wurde diese CVE nicht früher entdeckt? Wo war die SBOM lückenhaft? Hätte ein zusätzlicher Audit-Schritt geholfen? Diese Reviews sind unspektakulär - sie sind aber der einzige Weg, das Patch-Setup über die Jahre langsam besser zu machen, statt nur Brände zu löschen.
Artikel teilen
Wir nehmen Ihren Patch-Stand auseinander
Ein Vulnerability-Scan und SBOM-Abgleich zeigt in wenigen Tagen, welche bekannten CVEs in Ihrem Setup noch offen sind - und welcher Aufwand für die Stabilisierung realistisch ist.
Wir liefern keine PDF-Bibel, sondern eine priorisierte Liste mit konkreten Schritten - sortiert nach CVSS-Score und tatsächlicher Exposition Ihrer Anwendung.