Beardsleys Kernargument dreht die übliche Rechtfertigung um: Stilles Patchen begrenze das Wissen über eine Schwachstelle nicht auf einen kleinen Kreis, sondern begrenze die offengelegte Wahrheit auf jene, die ausreichend motiviert sind, ein Produkt zu reverse-engineeren. In der Praxis verschiebe sich diese Gruppe zu den Angreifern mit Fähigkeit und Anreiz. Alle, die die Nutzer verteidigen sollen, priorisierten derweil auf unvollständiger Datenbasis. Als zusätzlichen Nebeneffekt nennt er die eigenen künftigen Produktentwickler des Herstellers, die denselben Fehler erneut einbauen könnten, weil er beim ersten Mal geheim gehalten wurde.
Eine begrenzte Ausnahme lässt Beardsley gelten. Bei gehosteten SaaS-Produkten, bei denen Kunden gar keine Patch-Entscheidung treffen – kein Wartungsfenster, kein Changelog –, sei ein kurzes Embargo, während der Anbieter die eigene Flotte aktualisiert, lediglich ein operatives Detail. Dasselbe gelte für Produkte mit kleiner, eng kontrollierter Nutzerbasis, bei denen Auto-Update ohnehin binnen Stunden nahezu alle erreicht. In beiden Fällen spiele der Administrator mit Patch-Warteschlange kaum eine Rolle, weshalb ein Zurückhalten von Details über einige Tage bis wenige Wochen die Kunden kaum gefährde.
Besondere Aufmerksamkeit widmet der Beitrag Broadcom, das über VMware und dessen Tanzu-Sparte auch das Spring Framework verantwortet. Mit einer Ankündigung vom Juni 2026 wurde ein Programm ausgeweitet, das zahlenden Kunden über ein privates „Spring Enterprise Repository“ validierte, CVE-bezogene Patch-Releases vor der übrigen Open-Source-Nutzerschaft zugänglich macht. Broadcom erklärt, weiterhin für jede unterstützte Version jedes Spring-Projekts CVEs zu vergeben – kommerziell wie quelloffen.
Die praktische Wirkung sei jedoch käuflicher Frühzugang zu Exploit-Wissen. Der größte Unterschied zwischen dem gelegentlichen Skriptkiddie und dem staatlich finanzierten Cyberspion sei das Budget, argumentiert Beardsley: Solange Broadcom kein ungewöhnlich striktes Know-Your-Customer-Verfahren rund um dieses Abonnement betreibe, dürfe man davon ausgehen, dass auch zwielichtige Akteure Vorabhinweise auf ansonsten undokumentierte Schwachstellen erhalten.
Das eigentliche Problem sieht er im Größenverhältnis: Die Open-Source-Nutzerschaft von Spring ist ungleich größer als die Minderheit zahlender Kunden. Zwar liefere Broadcom CVEs, Advisories und Patches letztlich nach, doch die Verzögerung erzeuge ein Zeitfenster, in dem die bestausgestatteten Angreifer in einem beträchtlichen Ökosystem potenzieller Ziele weitgehend ungestört agieren könnten.
Der ideale Weg bleibe daher, das Risiko gegenüber allen zugleich offen zu benennen. Die Mehrheit stehe schließlich auf Seiten des Herstellers, auch wenn einige wenige es nicht tun – und ein Geheimhalten sei schwer zu rechtfertigen, wenn der Patch selbst jedem mit ausreichendem Patch-Diffing-Geschick die ganze Geschichte erzählt. Ein Vorsprung nach dem Muster „erst patchen, dann Advisory“ sei in den genannten engen Fällen vertretbar; das Zurückhalten von Details über Wochen hinweg oder für immer sei kaum zu begründen.
Zum Abschluss variiert Beardsley einen Ausspruch von Eric S. Raymond, wonach bei genügend Augenpaaren alle Fehler offensichtlich werden. Seine heutige Fassung: Bei genügend Prompt Engineering sei jeder Patch ein Advisory.