Lorenc zeichnet ein Szenario, in dem klassische Prozesse für den Umgang mit Schwachstellen nicht mehr ausreichen. Koordinierte Offenlegung sei für eine Welt entworfen worden, in der das Auffinden schwerwiegender Lücken Wochen an Expertenarbeit koste und nur eine überschaubare Zahl bekannter Projekte betroffen sei. Ein Modell könne heute jedoch über Nacht Hunderte Schwachstellen im „langen Ende“ der Open-Source-Landschaft finden. Für ungepatchte Fälle brauche es daher einen Ausweichplan.
Als Problem beschreibt er nicht nur die schiere Zahl potenzieller Befunde, sondern auch die Struktur des Open-Source-Ökosystems. Viele kritische Projekte würden von nur einer oder zwei Personen in ihrer Freizeit gepflegt. Diese Maintainer seien seit Jahren mit verrauschten, qualitativ schwachen Meldungen aus automatisierten Scannern und KI-generierten Berichten überlastet. Anders als bei kommerzieller Software gebe es keine Verträge und keine zugesicherten Reaktionszeiten; es sei nicht garantiert, dass ein Patch geschrieben, übernommen oder der zuständige Maintainer überhaupt erreichbar sei.
Für Unternehmen sieht Lorenc die Schwächen auf der Nutzerseite. Moderne Anwendungen bestünden aus Schichten von Abhängigkeiten. Wenn in einer Komponente ein Problem auftrete, könne die Behebung durch den gesamten Stack kaskadieren. In großen Organisationen mit gewachsenen Codebasen sei das kein schneller Eingriff. Zugleich habe KI auch Supply-Chain-Angriffe verstärkt: Wer unter Zeitdruck eine Schwachstelle beheben wolle, riskiere ohne sorgfältige Prüfung, statt eines Patches Schadsoftware zu installieren.
Als „Plan A“ schlägt Lorenc eine koordinierte Offenlegung vor, die tatsächlich skaliert: eine einzige vertrauenswürdige Gruppe, die vollständig geprüfte Berichte und Patches an Upstream-Projekte weiterleitet und Maintainer unterstützt, die Hilfe annehmen wollen. Nicht viele konkurrierende Gruppen mit rauschhaften Tickets, sondern ein zentraler Prozess, dessen Meldungen in den Posteingängen priorisiert würden. Als Beispiel nennt er Glasswing: Dort seien bislang rund 6 Prozent der Funde an Upstream-Projekte weitergereicht worden. Sein eigener Schätzwert liegt deutlich unter Vollabdeckung: Unter starkem Zeitdruck könne klassische koordinierte Offenlegung bestenfalls für etwa 50 Prozent der Projekte funktionieren.
Darüber hinaus fordert Lorenc einen „Maintainer letzter Instanz“ als „Plan B“. Dabei geht es um Projekte, bei denen Maintainer zwar reagieren, aber nicht rechtzeitig liefern können, ebenso wie um Fälle, in denen ein Patch existiert, aber nachgelagerte Nutzer ihn nicht übernehmen. Hinzu kommen Projekte, deren Maintainer gar nicht oder nicht mehr patchen wollen. Open Source erlaube das Forken ausdrücklich; diese Praxis existiere bereits. Neu sei aber die Größenordnung: Statt einzelner Projekte gehe es darum, Infrastruktur aufzubauen, um Tausende Forks unter Zeitdruck zu pflegen und zu verteilen.
Lorenc betont, eine solche Funktion müsse nachhaltig finanziert, personell besetzt, neutral und vertrauenswürdig sein. Ohne Zentralisierung drohe aus seiner Sicht ein chaotisches Szenario, in dem große Cloud-Anbieter und Sicherheitsfirmen jeweils eigene Forks kritischer Bibliotheken pflegen und Teams den Überblick verlieren, welche Variante welche CVEs behebt. Der von ihm bevorzugte Weg sei deshalb ein bewusst koordinierter „harter Fork“ der Vertrauensinfrastruktur für den Konsum von Open Source.
Auch die Politik streift Lorenc. Washington beobachte das Thema schon länger, könne aber schwer etwas regulieren, das weite Teile der Branche für erfunden hielten. Die USA konzentrierten sich deshalb auf die Nutzungsseite. Zugleich argumentiert er, Open Source lasse sich trotz europäischer Bemühungen wie dem CRA nicht direkt steuern, weil Gesetze und Verordnungen nicht auf weltweit frei veröffentlichte Software durchgriffen.