Offener Brief von Akrites zum gemeinsamen Schutz von Open-Source-Sicherheit

• Da KI-gestützte Schwachstellenerkennung die Reaktionsgeschwindigkeit von Maintainer:innen überholt, wurde Akrites als branchenweite Zusammenarbeit gestartet, um zentrale Open-Source-Software gemeinsam zu stärken
• Die Entdeckung schwerwiegender Schwachstellen dauerte früher für Expert:innen Wochen, doch heute können KI-Modelle innerhalb von Minuten mehrere Schwachstellen finden, wodurch die Belastung für die Reaktion stark steigt
• AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft und GitHub, NVIDIA, OpenAI, Red Hat, die Rust Foundation und weitere wollen Upstream-Fixes und verantwortungsvolle Offenlegung koordinieren
• Akrites stellt einen vertraulichen Koordinationspunkt und ein dediziertes Security Incident Response Team bereit, um doppelte Meldungen und kollidierende Patches zu reduzieren; bei zentralen Paketen ohne Maintainer:innen übernimmt es außerdem als letztes Mittel die Rolle des Maintainers
• Da Angreifer nach der Veröffentlichung eines Patches die Schwachstelle mithilfe von KI zurückentwickeln können, liegt das Erfolgskriterium nicht in der Veröffentlichung selbst, sondern darin, dass Patches in realen Systemen ausgerollt werden

---

Die durch KI veränderte Geschwindigkeit der Open-Source-Sicherheit

• Open Source bildet die Grundlage für kritische Infrastrukturen und Dienste, auf die Menschen täglich angewiesen sind, etwa Banken, Telekommunikation und Versorgungsunternehmen
• Weil dieselben Open-Source-Komponenten über den gesamten Technology Stack hinweg weit verbreitet sind, teilen viele Systeme dieselben potenziellen Fehler
• KI verschiebt das Gleichgewicht zwischen Angreifern und Verteidigern und senkt die Kostenstruktur für das Finden und Wiederverwenden von Schwachstellen
  • Die Entdeckung schwerwiegender Schwachstellen dauerte früher für Expert:innen Wochen, kann heute aber von Maschinen in Minuten erledigt werden
  • KI-Modelle geben mitunter in einem einzigen Lauf mehrere Schwachstellen zurück
  • Dieselben Fähigkeiten können auch zur Verteidigung genutzt werden, doch bei Missbrauch kann die Schwachstellensuche pipelineartig automatisiert werden

Wie doppelte Meldungen Maintainer:innen unter Druck setzen

• Bisherige Prozesse für Sicherheitsreaktion und Offenlegung funktionieren so, dass mehrere Organisationen und Teams relativ lose voneinander getrennt agieren; dadurch kann dasselbe Problem gleichzeitig bearbeitet werden, und es können kollidierende Patches sowie mehrere Berichte entstehen
• Wenn Dutzende Unternehmen dieselbe Bibliothek unabhängig scannen und jeweils eigene Berichte einreichen, gehen Maintainer:innen im Rauschen unter
• Je mehr Parteien von einer noch ungepatchten Schwachstelle wissen, desto größer wird die Wahrscheinlichkeit eines Leaks vor der Behebung, und dieses Risiko breitet sich auf das gesamte Ökosystem aus
• Auch gut gemeinte Reaktionen ohne Koordination können das Problem verschärfen und Zeit verschwenden

Der gemeinsame Reaktionsansatz von Akrites

• Akrites wurde als Initiative gestartet, die gemeinsame Systeme und Tools bereitstellt, um Schwachstellen in zentraler Open-Source-Software zu finden, zu beheben und verantwortungsvoll offenzulegen
• Zu den Beteiligten gehören Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft und GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, die Rust Foundation, Sonatype, Vodafone, Zscaler und weitere
• Im Zentrum der Reaktion steht der Upstream, in dem es Maintainer:innen gibt
  • Bereitgestellt wird ein einzelner vertraulicher, vertrauensbasierter Ort, an dem Schwachstellenerkennung, Behebung und Offenlegung koordiniert werden können
  • Ein dediziertes Security Incident Response Team wird für Maintainer:innen zu einem planbaren einzigen Partner statt zu einer Vielzahl unkoordinierter Meldungen
  • Fixes sollen in die ursprünglichen Repositories und Maintainer-Flows der jeweiligen Projekte zurückgeführt werden
• Falls ein zentrales Paket keine Maintainer:innen hat, will Akrites als Maintainer letzter Instanz einspringen, damit Fixes rechtzeitig ankommen

Warum Ausrollen wichtiger ist als die Veröffentlichung eines Patches

• Sobald ein Patch veröffentlicht ist, können Angreifer KI nutzen, um die eigentliche Schwachstelle schnell zurückzuentwickeln, Exploits zu entwickeln und Angriffe zu starten
• Daher sollte der Erfolg von Akrites nicht daran gemessen werden, ob ein Patch veröffentlicht wurde, sondern ob er in realen Systemen ausgerollt wurde
• Akrites will mit Eigentümern und Betreibern kritischer Infrastruktur, zivilgesellschaftlichen Initiativen und Regierungen zusammenarbeiten, um den Koordinationsgrad zu erhöhen
• Vertraulichkeit ist nicht verhandelbar; nicht veröffentlichte Fehler in weit verbreiteten Paketen sind faktisch wie Waffen, daher hat die Verhinderung von Leaks Priorität

Belastungen und Zusagen der teilnehmenden Organisationen

• Endor Labs erklärte, dass von den Tausenden in den vergangenen Monaten identifizierten Open-Source-Schwachstellen weniger als 5 % gepatcht worden seien
• OpenInfra erklärte, die OpenStack-Community habe allein in diesem Quartal 20 Security Advisories veröffentlicht; im gesamten Jahr 2025 seien es 2 gewesen
• JPMorganChase ist der Ansicht, dass KI die Zeit zwischen Schwachstellenerkennung und Ausnutzung nahezu auf Echtzeit verkürzt hat, weshalb auch die Zeit von der Behebung bis zum Rollout verkürzt werden muss
• Chainguard, Sonatype, RapidFort, Red Hat und weitere vertreten die Position, dass Schwachstellenbehebungen nicht verteilt in Forks oder hinter proprietären Mauern stattfinden sollten, sondern über Upstream-Koordination innerhalb der ursprünglichen Software- und Maintainer-Flows
• Die teilnehmenden Organisationen verpflichten sich, Engineering-Personal, Sicherheitsexpertise, Mittel und KI-Technologie einzusetzen, um gemeinsam genutzte Software zu stärken

[GN⁺]

Hacker-News-Meinungen

• Viele aus dem Open-Source-Umfeld werden diese Liste beteiligter Unternehmen zwangsläufig skeptisch sehen, und das aus gutem Grund
  Der entscheidende Punkt ist, wie man „Schwachstellen in kritischer Open-Source-Software findet, behebt und verantwortungsvoll offenlegt“ konkret umsetzt. Wenn man über bestehende Kanäle und Pull Requests beiträgt, kann man mit der Community zusammenarbeiten. Wenn man aber unter dem Vorwand der „Sicherheit“ forkt, grenzt man die Community aus, spaltet Ressourcen und kann langfristig viele Projekte zerstören. Bug-Bounties haben Potenzial, aber bei kritischen Bugs passen Geschwindigkeit und Zeitpunkt der Offenlegung womöglich nicht zusammen, und auch finanzielle Unterstützung ist nur begrenzt wirksam, wenn sie nicht mit Unterstützung für Maintainer verbunden wird

  • Ich bin bei der Linux Foundation angestellt, kenne aber die internen Details dieses Projekts nicht. Stattdessen kann ich sagen, was die Projekte tun, die ich unterstütze: Das HackerOne-Programm wird zurückgefahren, weil es mehr Rauschen als Signal erzeugt
    PQCA ermöglicht über AWS-Credits den Zugang zu Hardware, um Proofs und CI auszuführen, und betreibt zudem bezahlte Mentoring-Programme. OWF stellt ebenfalls AWS-Credits und gehostete Services für Tests bereit. LFDT hat bezahlte Mentoring-Programme, Kosten für Reviews durch Trail of Bits, Veranstaltungsbetrieb, den Maintainer Summit in New York und Support für große GitHub-CI-Runner finanziert. Unser Team besteht nach Entwicklerbeziehungs-Maßstäben von OWF/PQCA/LFDT nur aus 3 Vollzeitkräften, 1 Auftragnehmer und 1 Manager, aber wir arbeiten ziemlich hart daran, Entwicklern zu helfen
    LFDT: https://www.lfdecentralizedtrust.org/
    OWF: https://openwallet.foundation/
    PQCA: https://pqca.org/
    Beispiel für PQCA-Benchmarks: https://pq-code-package.github.io/mldsa-native/dev/bench/
  • Das war auch mein erster Gedanke, sobald ich sah, wer beteiligt ist und was sie vorhaben. Allmendegüter dürfen nicht in die Hände profitorientierter Unternehmen geraten
    Wie auch immer die Form aussieht: Es muss dezentralisiert sein, damit weder ein einzelner zentraler Ort noch eine einzelne Instanz Kontrolle ausüben kann
  • Es ist seltsam, so zu tun, „als wären diese Unternehmen keine Open-Source-Akteure“. Open Source ist kein exklusiver Club
  • So wie ich es gelesen habe, scheint gemeint zu sein, dass man dort, wo es möglich ist, auf bestehende Weise beiträgt und dort, wo es nötig ist, gesonderte Maßnahmen ergreift. Bei der Linux Foundation sollte selbstverständlich Open Source und die Community Vorrang haben
    Es ist von finanziellen Beiträgen die Rede, aber wichtig ist auch, wie und wofür sie geleistet werden. Die meisten Projekte sind nicht darauf vorbereitet, Spenden anzunehmen oder sinnvoll einzusetzen. Allerdings wäre es gut, wenn alle Open-Source-Projekte erheblichen Zugang zu KI erhalten könnten, damit sie ihre Codebasis und Pull Requests prüfen und so die Wartungslast senken können; einige solche Versuche gibt es bereits

• Es ist nur Corporate Showmanship
  Microsoft sagt, man wolle „Fachwissen, Ressourcen und KI-Technologie einbringen, um Schwachstellen verantwortungsvoll zu identifizieren und zu beheben“, aber Microsoft betreibt NPM und GitHub und hat Zugang zu den besten KI-Modellen und riesigen Rechenzentren. Trotzdem verschlechtert sich die Sicherheit der eigenen Produkte rapide, und die Dienste werden zu zentralen Hubs, über die sich verschiedene Exploits verbreiten
  Wer sehen will, wie Microsoft mit Sicherheitsproblemen in eigenen Open-Source-Projekten umgeht, dem empfehle ich diesen GitHub-Thread: https://github.com/dotnet/efcore/issues/38257
  EF Core verteilt derzeit eine SQLite-Version mit einer schwerwiegenden Schwachstelle. Das Problem wurde schon vor über einem Jahr entdeckt, SQLite hat es innerhalb einer Woche behoben, aber EF Core markierte den Treiber nicht als verwundbar, bis ein Nutzer das Thema kürzlich erneut meldete und mit den Entwicklern darüber stritt. Der Fix für die aktuelle stabile Version von .NET Core soll erst in ungefähr zwei Monaten kommen

  • CVE-2025-70873 als schwerwiegende Schwachstelle zu bezeichnen, wirkt etwas übertrieben. Die Schwachstelle greift nur, wenn man einem Angreifer erlaubt, eine beliebige ZIP-Datei importieren zu lassen; solange Nutzer keine beliebigen ZIP-Dateien importieren, ist das nicht ganz so gravierend
  • Vor der Übernahme durch Microsoft wollte GitHub sogar mit JavaScript eine IDE bauen und entwickelte dafür Electron; das war interessant und wurde am Ende zu etwas ganz anderem Nützlichem. So entsteht technische Innovation
    Nach der Übernahme hat Microsoft diesen Weg mit VSCode nicht fortgeführt, sondern eher eine Stimmung geschaffen, in der auf Electron herabgesehen wird, und inzwischen hassen viele Leute Electron, ohne den Grund überhaupt erklären zu können. VSCode hat Atom nicht einmal geforkt, sondern etwas Ähnliches von Grund auf gebaut, das größer und langsamer wurde und jetzt auch noch Copilot dranhängen hat. Ich bin am Ende zu Pulsar zurückgekehrt, einem guten Fork von Atom
    Microsoft schaut bei Übernahmen immer auf Chancen und Wettbewerbskonstellationen, nutzt das Gekaufte dann aber nur selten richtig. Gute Mitarbeiter und guter Code werden beseitigt und das Produkt wird ruiniert. Trotzdem benutzen alle weiterhin Microsoft-Produkte, und ich verstehe nicht, warum. Man sollte LinkedIn verlassen und gemeinsam auf ein anderes Versionsverwaltungssystem umziehen. Solange Open-Source-Entwickler nicht Taten statt Worte sprechen lassen, wird Microsoft immer schlimmer werden

• Wir werden das nicht tun. Wir werden keine großspurigen Erklärungen abgeben, dann kommerzielle Unternehmen alles ruinieren lassen und uns anschließend lautstark über den Zustand beklagen, obwohl wir selbst nichts getan haben
  Ich denke, künftig wird es eine Bewegung geben, die ich undo fork nenne. Das ist ein Fork, der zum Zeitpunkt vor Beginn des Wahnsinns zurückkehrt und noch einmal neu nachdenkt — etwas, das nur Menschen tun können, die nicht an kommerzielle Anforderungen gebunden sind

  • In gewisser Weise hat dieser Wandel bereits in dem Moment begonnen, als es den Übergang von Free Software zu Open Source gab, und er verlangsamt sich nicht
  • Noch schlimmer: Open Source kann von Marketing-getriebenen Unternehmen vereinnahmt werden und zu einem Mittel werden, kostenlose Arbeit herauszuziehen, um das zu bauen, was sie wollen, nicht das, was wir wollen
  • 95 % nützlicher Open-Source-Software werden von kommerziellen Unternehmen entwickelt oder gepflegt. Linux und Postgres sind solche Fälle; von kleineren Utilities einmal abgesehen
  • Die heutige Linux Foundation ist faktisch kaum anders als andere globale Unternehmen mit politischer Agenda. Wenn man dem Geldfluss folgt, sieht man, dass Unternehmen die Kontrolle haben; Torvalds wurde entmachtet, und die Zusammenarbeit ist meist kaum weniger als ein Albtraum
    Menschen, die sich für Open Source interessieren, rate ich immer, Abstand zur Linux Foundation zu halten. Inzwischen ist sie eher ein Hindernis für Softwarefreiheit als etwas, das sie ermöglicht

• Wenn wir Open Source schützen wollen, muss das nicht mit Worten beginnen, sondern mit konkreter Unterstützung für Projekte und Entwickler
  Aus Sicht eines OpenBSD-Entwicklers ist es wirklich wichtig, Entwicklern neue Hardware bereitzustellen. Viele Entwickler arbeiten auf 5 bis 10 Jahre alten ThinkPads, die ersetzt werden müssten
  https://www.openbsd.org/want.html
  Der OpenBSD Foundation fehlen bis zum Spendenziel für 2026 noch etwa 50 %
  https://www.openbsdfoundation.org/campaign2026.html

  • Es wäre gut, nicht nur die Open-Source-Projekte zu finanzieren, die man nutzt, sondern wenn möglich auch die einzelnen Beitragenden und Entwickler, die an diesen Projekten arbeiten, direkt zu unterstützen. Viele sind Ehrenamtliche, und selbst kleine monatliche Unterstützungen können einen großen Unterschied machen
    https://brynet.ca/wallofpizza.html
  • Ich wollte ein paar YubiKeys kaufen, um GPG-Schlüssel zu schützen, mit denen man nach Debian hochladen kann, aber wenn ich sie brauche, scheint es am Ende darauf hinauszulaufen, dass ich sie aus eigener Tasche bezahle

• An der Stelle „mit Amazon Web Services“ ist die Glaubwürdigkeit dieses Textes komplett dahin

• Das liest sich wie ein Versuch von Zentralisierung und Kontrolle. Wer auch immer Akrites ist: Es würde nur großen Tech-Konzernen einschließlich Google die Macht geben, Open Source zu kontrollieren
  Danke, aber nein danke. Ich erinnere mich daran, dass Google diesen September in Android Installationen von Drittanbietern über .apk blockieren will

  • Ich habe dieselbe Sorge. Wenn kritische Open-Source-Pakete von den „Sicherheits“-Releases dieser Unternehmen abhängig werden, könnten sie dann nicht zum Beispiel Identitätsprüfung für Pakete erzwingen?
    Dazu passend: Die meisten klugen Leute, die ich kenne, glauben, dass Open-Source-KI Anthropic und OpenAI finanziell unmöglich macht. Viele der Unternehmen, die hier unterzeichnet haben, hängen stark mit diesen beiden zusammen und haben einen Anreiz, Open-Source-KI zu destabilisieren, bevor ihre Kunden den Preisschock zu spüren bekommen. Ich habe mich gefragt, was ihr nächster Zug sein würde, und das könnte ein Teil davon sein

• Die wichtigste Information ist die Stelle, an der steht, dass die Beteiligten Engineering-Ressourcen beitragen
  Ob das wie geplant funktioniert, muss man abwarten. Davon abgesehen beeindrucken mich die Behauptungen dieses Projekts nicht besonders. Die Struktur begünstigt Zentralisierung und unternehmenszentrierte Netzwerke und steht damit genau im Gegensatz zu der Richtung, die die Hacker-Ethik aus guten Gründen gefördert hat

  • Es wirkt nicht inklusiv. Es sieht aus wie noch eine weitere Schicht, die eingehende Schwachstellen zentral sammelt, Informationen aggregiert und alles im Geheimen bearbeitet
    Es könnte zu einer weiteren Quelle von Druck werden. Tatsächliche Schwachstellen könnte es zwar gut herausfiltern, aber das Ergebnis würde dann mit hoher Priorität an Maintainer weitergereicht. Viele Maintainer sind schon ohne KI-Rauschen erschöpft, und selbst wenn ein Fix mitgeliefert wird, muss er immer noch geprüft werden
    Im besten Fall kann man das Rauschen reduzieren, aber die eigentliche Arbeit bleibt. Die Branche sollte Open-Source-Projekte insgesamt so finanzieren, dass sie die Befugnis haben, solche Dinge selbst zu bearbeiten. Das ist vermutlich auch am besten für die Qualität. Wenn man KI-Rauschen herausfiltern muss, kann man diese Funktion hinzufügen — aber nicht in Form einer geheimen, intransparenten Struktur, die alles kontrolliert
  • Kürzer gesagt: Es wirkt wie eine Scheinkooperation, bei der Unternehmen Zeit absaugen und nichts zurückgeben. Ich stimme zu, dass das das genaue Gegenteil von dem ist, was die Hacker-Ethik fördert

• Ich warte auf den Tag, an dem ich Schlagzeilen sehe wie: „Wir alle sind von Open Source abhängig. Wir werden gemeinsam dafür zahlen“

  • Ein erheblicher Teil der großen Unternehmen „finanziert Open Source“ bereits, indem sie Mitarbeiter einstellen und sie dazu beitragen lassen. Das sieht man zum Beispiel an den Firmen-E-Mail-Adressen auf der LKML

• Der Name „Akrites“ gefällt mir
  Auf Nicht-Griechen wirkt er vielleicht weniger eindrucksvoll, aber auf Griechen hat er ziemlich starke Wirkung

  • Für alle, die es nachschlagen wollen, kurz zusammengefasst: akritai bezeichnete im 9. bis 11. Jahrhundert im Byzantinischen Reich Grenzsoldaten, die die östliche Grenze bewachten
    akron bedeutet Rand oder Grenze, also etwa „Grenzbewohner“ oder „Menschen der Grenze“. Der wichtige Punkt dabei ist, dass man moderne Konflikte oder Vorurteile nicht einfach eins zu eins auf tausend Jahre alte Geschichte übertragen kann. Im historischen Kontext war es ähnlich wie viele andere Grenzen zwischen verschiedenen Zivilisationen, und wichtig ist, dass es sich um eine organisierte Gruppe handelte, die zusammenkam, um ihr eigenes Gebiet zu verteidigen
  • Ein jüngeres Beispiel ist Mark Carneys Davos-Rede. Ich muss dabei besonders an die Stelle denken: „Mittelmächte müssen gemeinsam handeln. Wenn wir nicht am Tisch sitzen, landen wir auf der Speisekarte“
    [1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech

• Ich halte es nicht für besonders sinnvoll, so etwas auf Hacker News zu posten. Die Mehrheit hier hat den AI-Trend stark verinnerlicht und kümmert sich nicht besonders darum
  Außerdem gehören viele der Unternehmen auf der Liste zu den Hauptverdächtigen dafür, dass Open Source in seinem jetzigen Zustand ist

  • Ich akzeptiere den AI-Müll nicht, und ich verstehe auch nicht so recht, wie man zu so einem Schluss kommt. Die meisten Kommentare stehen AI-Müll eher ziemlich kritisch gegenüber
    Ich stimme allerdings zu, dass viele der Unternehmen auf der Liste zu den Hauptverdächtigen für den Zustand von Open Source gehören. Das wirkt wie eine PR-Anzeige, die diese Unternehmen reinwaschen soll, und es fällt schwer zu glauben, dass ihnen Open-Source-Ethik wirklich am Herzen liegt.