Victoria Shinder: Ein Hersteller-Patch ist eine ungeprüfte Änderung — und sie kommt trotzdem

Victoria Shinder19 September 2026, 15:102 Min. Lesezeit

Teams stecken enorme Mühe in die Änderungen, die sie selbst schreiben: geschützte Branches, Review, Tests, stufenweises Ausrollen, ein Rückfallplan. Dann liefert ein Hersteller an einem Dienstag ein Update aus, es landet auf jedem Rechner — und nichts von dieser Maschinerie greift.

Der Excel-Fehler dieses Monats ist ein kleines, sauberes Beispiel: Ein Sicherheitsupdate schloss eine echte Lücke und ließ als Nebenwirkung eine alltägliche Operation lautlos scheitern. Im Release-Prozess der betroffenen Organisationen hatte niemand eine Meinung dazu, denn die Änderung kam gar nicht durch diesen Prozess.

Wie eine Absicherung aussähe

Den Patch eines Herstellers kann man nicht reviewen. Man kann entscheiden, was passiert, wenn er ankommt.

Wissen, was sich selbst aktualisiert. Die meisten Teams können ihre Abhängigkeiten aufzählen und die wenigsten das, was sich ungefragt aktualisiert: Betriebssystem, Office-Paket, Browser, der Agent auf der Build-Maschine, das Base-Image mit :latest. Diese Liste ist das erste Ergebnis — und sie zu schreiben ist meist unangenehm.

Eine Maschine, die es zuerst bekommt. Keine Testumgebung für die eigene Software, sondern ein Rechner, der Hersteller-Updates einen Tag oder eine Woche vor allen anderen nimmt, auf dem jemand normal arbeitet. So findet ein Kollege den lautlosen Fehler und nicht ein Kunde.

Aufschreiben, wofür jedes Werkzeug tragend ist. „In Excel schließt die Buchhaltung den Monat ab" ist der Satz, der aus einem kaputten Einfügen einen Vorfall mit Frist macht. Aufgeschrieben wird er üblicherweise erst hinterher.

Der unangenehme Teil

Das alles wird selten gemacht, weil es kein sichtbares Ergebnis hat, wenn es funktioniert. Ein Patch kommt, nichts geht kaputt — und die Woche, in der nichts kaputtging, sieht genauso aus wie die Woche, in der niemand hingesehen hat.

Es ist dasselbe Argument, das gegen Tests vorgebracht wird, und es verliert aus demselben Grund: Die Kosten fallen einmal an, der Schaden jedes Mal. Ein Release-Prozess, der nur die eigenen Commits regelt, regelt die kleinere Hälfte dessen, was sich in der Produktion ändert.

Eine Fassung auf einer Seite, die man wirklich einführt

Niemand führt eine Richtlinie mit neun Schritten ein. Diese hat drei Zeilen, und jedes Team, bei dem ich es funktionieren gesehen habe, hat sie sichtbar aufgeschrieben:

1. Eine Liste dessen, was sich selbst aktualisiert. Keine Abhängigkeiten — die Dinge, die niemand deklariert hat: Betriebssystem, Browser, Office-Paket, der Agent auf der Build-Maschine, das Base-Image an einem wandernden Tag.
2. Eine Maschine, die Updates zuerst bekommt, benutzt für normale Arbeit von jemandem, der etwas merkt und es sagt.
3. Ein Satz pro Werkzeug, wofür es tragend ist — geschrieben vor dem Vorfall und nicht während dessen.

Die Messung, die das Argument trägt

Damit das Argument eine Planungsrunde übersteht, braucht es eine Zahl: die Produktionsvorfälle des letzten Jahres zählen und in Änderungen, die wir gemacht haben und Änderungen, die eingetroffen sind sortieren. Die meisten Teams haben diese Trennung nie vorgenommen und sind überrascht. Die zweite Spalte gehört niemandem — und klein ist sie selten.