Der härteste Fork

Mythos ist real. Mir ist klar, dass ein Großteil der Branche denkt, das sei ein Marketing-Gag, und ich verstehe warum. Ich verstehe das. Aber ich habe die Ergebnisse gesehen, und sie sind übel. Das sind nicht einfach „Ups, diese Zeile hier ist falsch und das ist eine Remotecodeausführung (RCE).“ Es handelt sich um neuartige Kombinationen aus ein paar Dutzend Problemen unter Tausenden von Dingen, die jeder SAST-Scanner ohnehin findet, verkettet zu etwas sehr viel Schlimmerem. Das ist echte Kreativität, wie Zug 37. Das ist kein besserer Scanner. Das ist eine andere Kategorie von Bedrohung.

In gewisser Weise spielt das nicht einmal eine Rolle. Selbst wenn dieses spezifische Modell ein Schwindel wäre, kommt diese Fähigkeit so oder so. An manchen Tagen wünschte ich, es wäre ein Schwindel. Wir hätten mehr Zeit. Aber Sie können mir glauben oder nicht. Der Rest dieses Beitrags dreht sich darum, was wir in jedem Fall dagegen tun, und ich fange jetzt damit an.

Washington verfolgt dies schon seit einiger Zeit, aber man kann etwas nicht regulieren, von dem der Großteil der Branche denkt, es sei erfunden. Jetzt, da sich jede Führungsetage im Vorbereitungsmodus befindet (und das tut sie), kann Washington endlich darüber nachdenken, welche Schritte unternommen werden können. Es ist klar, dass sie eine Rolle spielen müssen, aber es ist nicht klar wie oder welche das sein soll. Und sie befinden sich in einer wirklich schwierigen Lage.

Reguliert man zu wenig, riskiert man, dass ein in den USA ansässiges Unternehmen versehentlich eine Waffe erschafft, die unsere kritische Infrastruktur gefährdet. Reguliert man zu viel, passiert genau dasselbe stattdessen in China. Das Ganze fühlt sich an wie Gain-of-Function-Forschung an Viren. Jeder weiß, dass man sich vor dem Verlassen des Labors die Hände waschen sollte, aber nur weil wir es zur Pflicht machen, heißt das noch lange nicht, dass der Rest der Welt das auch tut. Wir haben bereits gesehen, wie diese Geschichte in Wuhan ausgegangen ist.

Hier ist das strukturelle Problem, das die Möglichkeiten jeder Regierung einschränkt: Trotz Europas bester Versuche mit dem CRA ist Open Source nicht regierbar. Gesetze und Präsidialerlasse gelten nicht für Menschen auf der ganzen Welt, die kostenlos Dinge ins Internet stellen. Die USA haben das erkannt und konzentrieren sich daher dort, wo sie können und sollten: beim Konsum. Das ist der richtige Instinkt, und genau darum wird es im restlichen Teil dieses Beitrags gehen.

Das Open-Source-Ökosystem und das Konsummodell sind hierfür nicht bereit

Ich arbeite seit einem Jahrzehnt jeden Tag meines Lebens an diesem Problem. Ich habe während meiner Zeit bei Google die OpenSSF und Alpha-Omega mitgegründet. Ich habe Sigstore, Scorecards und die ersten Open-Source-Malware-Scanner entwickelt. Ich habe die Zuschüsse finanziert, die Rust in den Linux-Kernel und MFA zu PyPI gebracht haben. Dann habe ich Chainguard gegründet, um all dies kommerziell und im großen Stil zu tun. Ich erzähle Ihnen das alles nicht, um anzugeben, sondern weil Sie mir glauben müssen, wenn ich sage: Die Art und Weise, wie die Welt Open-Source-Software konsumiert, ist grundlegend defekt, und keine noch so vielen inkrementellen Verbesserungen werden das rechtzeitig beheben.

Nicht in ihrer aktuellen Form. Vielleicht überhaupt nicht. Das wird sich ändern müssen.

Die meisten Unternehmen konsumieren Open Source seit Jahren frei, ohne wirklich darüber nachzudenken. Moderne Anwendungen sind Schichten von Abhängigkeiten, und wenn in einer davon etwas schiefgeht, kann die Behebung Kaskadeneffekte durch einen gesamten Stack auslösen. Für große Organisationen mit gewachsenem Code ist das keine Sache, die man an einem Nachmittag behebt. Und schnelles Handeln birgt mittlerweile eigene Risiken. KI hat auch Angriffe auf die Lieferkette massiv beschleunigt. Wenn Sie eine Sicherheitslücke überstürzt und ohne sorgfältige Prüfung patchen, installieren Sie möglicherweise Malware, die noch schlimmer ist als das ursprüngliche Problem.

Die Betreiberseite ist noch schwieriger. Vor allem für den riesigen Teil der Maintainer, denen es am Herzen liegt und die helfen wollen. Viele tun das nicht, und das ist völlig in Ordnung. Sie sind ihren Downstream-Nutzern nichts schuldig. Einige der kritischsten Softwarekomponenten im Internet werden von ein oder zwei Personen in ihrer Freizeit gewartet. Automatisierte Scanner und KI-generierte Berichte überhäufen sie seit Jahren mit minderwertigem Rauschen. Und im Gegensatz zu kommerzieller Software haben Open-Source-Maintainer keine Verträge oder SLAs. Es gibt keine Garantie dafür, dass ein Patch geschrieben oder zusammengeführt wird oder dass die Person überhaupt erreichbar ist.

Koordinierte Schwachstellenoffenlegung wurde für eine Welt entwickelt, in der das Finden einer schwerwiegenden Schwachstelle wochenlange Expertenarbeit erforderte und die Ziele eine kleine Gruppe bekannter Projekte waren. Ein Modell kann nun über Nacht Hunderte im Long Tail finden. Das bestehende System wird da nicht mithalten können, und wir alle brauchen einen Notfallplan für die Schwachstellen, die nicht gepatcht werden.

Was jetzt tatsächlich geschehen muss

Wir brauchen einen Plan A und einen Plan B.

Plan A: koordinierte Offenlegung, die im großen Maßstab auch wirklich funktioniert. Eine einzige, vertrauenswürdige Gruppe, die vollständig überprüfte Berichte und Patches nach oben weiterleitet und die Betreuer unterstützt, die Hilfe wünschen. Kein Dutzend konkurrierender Gruppen, die unzählige Tickets einreichen. Eine koordinierte Anstrengung, die Betreuer kennen und der sie vertrauen, damit ihre Berichte ganz oben in jedem Posteingang landen. Im Moment hat es Glasswing geschafft, etwa 6 % der gefundenen Schwachstellen nach oben weiterzuleiten. Dieses Programm wird niemals 100 % erreichen. So funktioniert der Long Tail von Open Source nun mal nicht. Mein bester Tipp ist, dass wir eine normale koordinierte Offenlegung unter starkem Zeitdruck für bestenfalls vielleicht 50 % der Projekte zum Laufen bringen können. Und es wird eine Menge Arbeit erfordern, dorthin zu gelangen.

Plan B: Wie wir mit dem Rest umgehen. Und das ist keine saubere Trennung. Es gibt ein riesiges, unübersichtliches Mittelfeld von Projekten, bei denen der Betreuer zwar reagiert, aber nicht rechtzeitig einen Fix liefern kann, oder bei denen ein Patch existiert, den aber niemand downstream übernimmt. Für all diese Fälle und für die Projekte, bei denen Betreuer überhaupt nicht patchen können oder wollen, brauchen wir einen Betreuer der letzten Instanz. Open Source gibt Ihnen das Recht zu forken. Ein Projekt zu übernehmen, die Verantwortung zu tragen und es unabhängig am Leben zu erhalten. Das Forken von toten oder nicht reagierenden Projekten kommt ohnehin jeden Tag vor. Aber in einer Welt, in der Hunderte von Schwachstellen von Dutzenden von Gruppen gemeldet werden, müssen wir diese Forks an einem Ort zentralisieren, damit die Endbenutzer ihnen vertrauen können. Das wird harte Entscheidungen und verletzte Gefühle mit sich bringen, aber es ist der einzige Weg, wie wir eine Fragmentierung vermeiden.

Vor einem Jahr wäre das in großem Maßstab noch nicht möglich gewesen. Jetzt ist es das. Dieselbe KI-Fähigkeit, die diese Krise verursacht, macht einen Betreuer der letzten Instanz überhaupt erst machbar. Diese Funktion muss an einem Ort angesiedelt sein, der nachhaltig finanziert, personell besetzt, neutral und vertrauenswürdig ist.

Der beste Zeitpunkt, um einen Abhängigkeitsbaum zu reparieren, war vor 20 Jahren. Der zweitbeste Zeitpunkt ist jetzt. Und wie das Sprichwort sagt: Wenn du schnell gehen willst, geh allein. Wenn du weit gehen willst, geh gemeinsam. Das Problem ist, dass wir beides tun müssen.

Drei Wege, die sich kreuzen

Was also tun wir eigentlich? Es gibt drei Möglichkeiten, wie das ausgehen kann, je nachdem, wie stark Sie der Meinung sind, dass dieses Problem von jemand anderem gelöst werden muss, und wie lange wir brauchen, um zu begreifen, dass niemand kommt, um uns zu retten, und endlich unseren Kram auf die Reihe zu kriegen.

Die naive Variante: Sie tun nichts und hoffen. Glasswing patcht alles upstream, Ihr Anbieter sandboxet auf magische Weise jede Workload, damit nichts entkommen kann, Ihr Team schreibt Ihre Legacy-Bereitstellungspipeline so um, dass alle sechzig Sekunden ausgeliefert wird, und Ihr CISO schläft zum ersten Mal seit 2014 die ganze Nacht durch. Jeder Betreuer reagiert auf jede Offenlegung innerhalb von 24 Stunden. Jedes Unternehmen aktualisiert jede Abhängigkeit an dem Tag, an dem ein Patch eintrifft. Niemand baut eine Regression ein. Niemand installiert Malware, die als Patch getarnt ist. Ich möchte in dieser Welt leben. Wir leben nicht in dieser Welt.

Die chaotische Variante: Niemand zentralisiert. Jeder große Cloud-Anbieter forkt seine eigenen Versionen kritischer Bibliotheken, jede mit ihren eigenen Patch-Sets. Drei verschiedene Sicherheitsanbieter liefern konkurrierende Forks desselben Logging-Frameworks aus. Ihr Team versucht herauszufinden, welche Version welches Forks welche CVEs behoben hat und ob eine davon neue eingeführt hat. Das ist der Standard, wenn wir gar nichts tun.

Der harte Fork: eine bewusste, koordinierte, schmerzhafte Entscheidung, eine neue Vertrauensinfrastruktur für den Open-Source-Konsum aufzubauen. Eine Offenlegungspipeline, die im großen Maßstab funktioniert. Ein vertrauenswürdiger Ort für gewartete Forks. Schwere Entscheidungen darüber, welche Projekte geforkt werden und welche Forks überleben. Dies ist die schwierigste Option und die einzige, die wirklich Sinn ergibt.

Open Source hatte schon immer einen Mechanismus dafür. Wenn sich ein Projekt nicht anpassen kann oder will, forkt man es. Man übernimmt die Verantwortung, tut die Arbeit und macht weiter. Das ist die Abmachung. Das war schon immer die Abmachung.

Was jetzt anders ist, ist der Maßstab. Wir sprechen nicht davon, ein einziges Projekt zu forken. Wir sprechen davon, die Infrastruktur aufzubauen, um Tausende davon zu forken, zu warten und zu verteilen. Unter Zeitdruck, mit echten Gegnern auf der anderen Seite. Das ist der härteste Fork, den je einer von uns machen musste.

Dieselbe KI-Fähigkeit, die diese Krise verursacht hat, ist diejenige, die sie möglich macht. Software wird sich auf eine Weise verändern, die vor einem Jahr noch unvorstellbar gewesen wäre, und ich denke, auf der anderen Seite wartet eine hellere Zukunft.

Wird das alles überhaupt funktionieren? Ich habe ehrlich gesagt keine Ahnung. Aber wir müssen anfangen, und wie das Credo des Programmierers besagt: „Wir tun dies nicht, weil es einfach ist, sondern weil wir dachten, es wäre einfach, als wir damit anfingen.“ Das fühlt sich schon am Anfang nicht einfach an.