Unser erster Release-Zyklus mit verstärkter Sicherheit: Was wir gelernt haben und was wir künftig ändern

Kunal AnandChief Product Officer | F5

Anmerkung der Redaktion (14. Oktober 2026): F5 bezeichnet „gehärtete Releases“ nun als „kritische Releases“. Diese terminologische Änderung unterstreicht die Bedeutung dieser Releases und wie wichtig es ist, die neueste Version so schnell wie möglich bereitzustellen.

Im Juli schrieb ich über unsere Umstellung auf monatliche gehärtete Releases und monatliche Sicherheitsbenachrichtigungen. Damals sagte ich, dass dieser Rhythmus für unsere damalige Situation angemessen sei und dass dieselbe Disziplin, die uns von vierteljährlichen Veröffentlichungen weggeführt hatte, uns erneut zu einer Umstellung bewegen würde, sobald die Lage es erforderte.

Nach einem Release-Zyklus haben wir viel gelernt. Wir haben von Kunden und Partnern gelernt und beobachtet, wie sich ein monatlicher Rhythmus in Produktionsumgebungen bewährt. Einige dieser Erkenntnisse veranlassen uns dazu, unseren Ansatz zu ändern.

Ab HR2 am 2. September werden gehärtete Releases nicht mehr monatlich, sondern im Sechs-Wochen-Rhythmus veröffentlicht. Außerdem setzen wir die regelmäßigen Sicherheitsmitteilungen aus, deren Veröffentlichung parallel dazu geplant war.

Ich möchte erklären, wie es dazu gekommen ist, denn die Beweggründe sind wichtiger als die Termine.

Was uns unsere Kunden mitgeteilt haben

Wir haben HR1 am 15. Juli veröffentlicht und anschließend getan, was wir versprochen hatten: Wir haben zugehört.

Die Rückmeldungen waren einheitlich, und eigentlich ging es dabei nicht um F5. Unternehmen, die unsere Produkte in ihren geschäftskritischsten Bereichen einsetzen, sagten uns, dass ihnen ein monatlicher Rhythmus nicht genügend Spielraum zum Testen, Stagen und Bereitstellen lasse – nicht unbedingt, weil unsere Releases für sich genommen schwer zu bewältigen seien, sondern weil sie zeitgleich mit denen aller anderen Anbieter einträfen. Jeder ernst zu nehmende Anbieter reagiert auf denselben Wandel, und die kumulierte Belastung trifft in jedem Unternehmen dasselbe Team mit begrenzten Kapazitäten.

Sechs Wochen sind ein Eingeständnis, dass eine Fehlerbehebung, die niemand implementieren kann, keine echte Fehlerbehebung ist. Die Geschwindigkeit, mit der Kunden eine Änderung umsetzen können, ist inzwischen selbst Teil der Sicherheitsgleichung. Ein Rhythmus, der die Aufnahmefähigkeit übersteigt, schafft zusätzliche Risiken, statt sie zu verringern.

Eine weitere Erkenntnis weist in die entgegengesetzte Richtung. Kunden, die in Flottenmanagement und Automatisierung investiert haben, können Updates deutlich schneller durchführen. Ein weltweit tätiger Kunde mit einer großen F5 BIG-IP-Flotte verkürzte die Aktualisierungsdauer von mehr als sechs Monaten auf etwa zwei Wochen.

Warum wir Sicherheitsbenachrichtigungen vorübergehend aussetzen

Die zweite Änderung ist schwieriger, und ich möchte die Gründe dafür offen darlegen.

Als wir monatliche Sicherheitsbenachrichtigungen ankündigten, gingen wir davon aus, dass eine Verzögerung von etwa 30 Tagen zwischen der abgesicherten Version und der Offenlegung den Kunden ein praktikables Zeitfenster für die Aktualisierung bieten würde, bevor die Details öffentlich bekannt würden. Diese Annahme entsprach unserer damaligen bestmöglichen Einschätzung.

Diese Annahme gilt nicht mehr. Gespräche mit Kunden und anderen Akteuren der Branche in den vergangenen Wochen haben unsere Einschätzung dazu verändert, wie viele Informationen tatsächlich erforderlich sind, um einen funktionsfähigen Exploit zu entwickeln. Führende Modelle werden immer besser darin, aus begrenzten Anhaltspunkten – einem Diff, einer unvollständigen Beschreibung oder einem Versionsbereich – eine funktionierende Angriffskette abzuleiten. Das Zeitfenster, das wir damit für Verteidiger schaffen wollten, steht in der Praxis auch Angreifern offen – und es wird immer kleiner.

Daher setzen wir regelmäßige Benachrichtigungen vorerst aus, während wir gemeinsam erarbeiten, wie eine verantwortungsvolle Offenlegung in diesem Umfeld aussehen kann. Es wird Ausnahmen geben. Wenn eine Schwachstelle aktiv ausgenutzt wird, wenn wir uns mit Forschenden oder Behörden abstimmen oder wenn regulatorische beziehungsweise vertragliche Verpflichtungen dies erfordern, werden wir bei der Offenlegung anders vorgehen. Dies ist keine dauerhafte Abkehr von Transparenz. Es ist eine Entscheidung unter der Maßgabe, dass der Schutz unserer Kunden an erster Stelle steht, und wir werden sie fortlaufend überprüfen.

Mir ist bewusst, dass dies unangenehm ist. Auch für mich als ehemaligen CISO ist es unangenehm. Die Regeln für die Offenlegung bestehen aus gutem Grund, und die Sicherheitscommunity hat sie über Jahrzehnte hinweg auf der Grundlage schwieriger Erfahrungen entwickelt. Allerdings waren diese Regeln auf eine Welt zugeschnitten, in der zwischen „Details veröffentlicht“ und „Exploit verfügbar“ Wochen lagen. Dieser zeitliche Abstand ist verschwunden, und jede Organisation, die Informationen über Schwachstellen veröffentlicht, wird sich damit auseinandersetzen müssen, was das bedeutet.

Die schwierigere Frage: Triage ohne Schweregrad

Das ist der Aspekt, mit dem sich die Branche meiner Meinung nach noch nicht umfassend auseinandergesetzt hat.

Die meisten Programme für das Schwachstellenmanagement richten sich nach dem Schweregrad. Kritische Schwachstellen werden innerhalb von 24 Stunden behoben, solche mit hohem Schweregrad innerhalb von drei Tagen, solche mit mittlerem Schweregrad in einem Sprint und solche mit niedrigem Schweregrad, wenn Zeit dafür ist. Dieses Modell setzt zweierlei voraus: dass Schweregradbewertungen das Risiko aussagekräftig vorhersagen und dass überhaupt Schweregradbewertungen vorliegen, mit denen man arbeiten kann.

Beide Annahmen verlieren zunehmend ihre Gültigkeit.

Die erste Annahme verliert an Gültigkeit, weil Angreifer, die hochmoderne Modelle einsetzen, keine kritische Schwachstelle benötigen. Sie verketten mehrere Schwachstellen miteinander. Drei Schwachstellen mit niedrigem Schweregrad, die einzeln betrachtet möglicherweise weit unten in der Priorisierungsliste stehen, ergeben einen praktikablen Angriffsweg, wenn ein Modell alle drei gleichzeitig in seine Überlegungen einbeziehen kann. Bei der Überprüfung unseres eigenen Codes stoßen wir auf genau diese Art von Problemen: Schwachstellen mit niedrigerem Schweregrad, die miteinander verkettet werden könnten. Sie systematisch zu beseitigen, macht Software widerstandsfähiger. Sie einzeln nach Schweregrad zu priorisieren, führt hingegen dazu, dass sie bestehen bleiben.

Die zweite Annahme verliert an Gültigkeit, weil Anbieter – uns eingeschlossen – künftig weniger Details und diese erst später veröffentlichen werden. Für Sicherheitsteams wird sich das wie ein Kontrollverlust anfühlen, und ich verstehe, warum.

Was tun Sie also stattdessen?

Priorisieren Sie nach Exposition, nicht nach Bewertung. Erreichbarkeit, Exposition gegenüber dem Internet, potenzielles Schadensausmaß und Geschäftskritikalität sind verlässlichere Kriterien als ein CVSS-Score, den Sie möglicherweise gar nicht erhalten. Ein exponiertes und ungepatchtes System stellt unabhängig von den Angaben in der Sicherheitsempfehlung ein Risiko dar.

Konsequent auf dem neuesten Stand zu bleiben, ist das Gebot. Die Organisationen, die in diesem Umfeld erfolgreich sein werden, sind diejenigen, die den „Betrieb der neuesten gehärteten Version“ als dauerhafte betriebliche Verpflichtung betrachten und nicht als Maßnahme, die erst durch eine Schweregradeinstufung ausgelöst wird. Das erfordert ebenso einen kulturellen wie einen technischen Wandel – und für dessen nachhaltige Umsetzung braucht es die Rückendeckung der Führungsebene.

Investieren Sie jetzt in die nötigen Kapazitäten zur Bewältigung. Automatisierung, Transparenz über die gesamte Systemlandschaft, wiederholbare Wartungsfenster und erprobte Rollback-Verfahren sind entscheidend, um einen schnelleren Takt bewältigen zu können. Diese Investitionen mögen derzeit noch optional erscheinen. In einem Jahr werden sie das nicht mehr sein.

Gehen Sie davon aus, dass diese Lücke bestehen bleibt, und sichern Sie sie ab. Kein Unternehmen spielt Patches sofort ein. Laufzeitschutz – verhaltensbasierte Erkennung, virtuelles Patching und Kontrollen, die nicht von der Kenntnis der konkreten Schwachstelle abhängen – kann dazu beitragen, den Zeitraum zwischen der Verfügbarkeit und der Bereitstellung eines Fixes abzusichern. Dieser Zeitraum wird nicht verschwinden. Berücksichtigen Sie ihn bei Ihrer Planung, statt ihn zu ignorieren.

Über das Ändern unserer Meinung

Wir haben im Juli auf Grundlage der besten uns damals vorliegenden Informationen eine Entscheidung getroffen. Wir haben sie umgesetzt, aus den Rückmeldungen von Kunden und Partnern gelernt und unseren Kurs angepasst. An unserer Position festzuhalten, nur weil wir sie angekündigt hatten, wäre für Kunden und Partner die schlechtere Alternative gewesen.

Ich habe im Juli gesagt, dass wir uns auch weiterhin anpassen werden, wenn sich die Rahmenbedingungen und Ihre Anforderungen verändern. So sieht das in der Praxis aus. Jeder Anbieter muss derzeit ehrlicherweise einräumen, dass etablierte Vorgehensweisen in der gesamten Branche laufend neu bewertet werden. Wer behauptet, dafür bereits eine vollständige Lösung gefunden zu haben, verschließt die Augen vor der Realität.

Was sich nicht ändert, ist der Anspruch, den wir an uns selbst stellen. Unternehmen setzen F5 zwischen ihre Benutzer und ihre Anwendungen, ihre Agenten und ihre APIs. Diese Position ist der Grund dafür, dass wir Schwachstellen in diesem Tempo finden und beheben, dass wir auf diese Weise testen und dass wir uns bei der Offenlegung so entschieden haben. Vielen Dank für das Feedback, das diese Entscheidung mitgeprägt hat. Bitte geben Sie uns auch weiterhin Rückmeldung und halten Sie sich auf dem Laufenden.

Über den Autor

Kunal AnandChief Product Officer | F5

Kunal Anand leitet als Chief Product Officer die Produktorganisation von F5. Er ist für Produktvision, Strategie und Umsetzung verantwortlich und stellt die Entwicklung wegweisender Lösungen sicher, die kritische Herausforderungen bewältigen und außergewöhnliche Kundenerlebnisse schaffen. In seiner vorherigen Funktion als Chief Technology and AI Officer bestimmte Kunal die Technologie- und KI-Strategie sowie die entsprechende Vision des Unternehmens. Vor seiner Zeit bei F5 hatte Kunal bei Imperva die Doppelfunktion des Chief Technology Officer und Chief Information Security Officer inne. Sein Weg zu Imperva begann 2018 mit der Übernahme von Prevoty, einem 2013 von ihm mitgegründeten Start-up für Anwendungssicherheit. Vor seinem Wechsel zu Prevoty war er Director of Technology bei BBC Worldwide. Kunal verfügt über langjährige Innovations- und umfassende technische Erfahrung und leitete bei Gravity, MySpace und dem NASA Jet Propulsion Lab Teams in den Bereichen Sicherheit, Daten, Technologie und Engineering. Kunal verfügt über mehr als 15 Jahre Erfahrung in den Bereichen KI und maschinelles Lernen – von Modelltraining und dem Einsatz KI-gestützter Algorithmen zur Produktoptimierung bis hin zur Konzeption und Implementierung von KI-Architekturen. Kunal hat einen Bachelor-of-Science-Abschluss in Informatik vom Babson College.

Weitere Blogbeiträge von Kunal Anand