Schwachstellenmeldungen sind nichts Besonderes mehr

• In der Pflege von Open Source können normale Issues und PRs optional behandelt werden, aber frühere Schwachstellenmeldungen waren eine Ausnahme, die wegen des Schutzes der Nutzer gesondert bearbeitet werden musste
• Diese Ausnahmestellung beruhte auf seltener Erkenntnis und Vertraulichkeit, die Forschenden die Möglichkeit gaben, Projekte vor Angreifern zu patchen, und Projekte erwiderten dies mit schnellen Antworten, Untersuchungen, Status-Updates und Anerkennung
• 2026 können sowohl Maintainer als auch Angreifer LLMs einsetzen, sodass sich der Engpass von der Entdeckung potenzieller Probleme zur Auswahl echter Schwachstellen verlagert
• Externe Forschende ohne Vertrauensverhältnis können zu dieser Auswahl kaum wesentlich beitragen, und das Signal-Rausch-Verhältnis beim Prüfen von LLM-Ausgaben ähnelt dem beim Durchsehen des security@-Posteingangs
• Die Zeit von Maintainern sollte weniger in die Reaktion auf Meldungen selbst fließen als in Klassifizierung, schnelle Behebung und Prävention; außerdem werden Wege benötigt, LLM-Analysen in CI auszuführen

---

Warum Schwachstellenmeldungen eine Ausnahme waren

• Maintainer von Open Source, die öffentlich arbeiten, betrachten Issues, PRs und Feedback als Geschenke und können sie je nach Bedarf annehmen, ignorieren oder nur teilweise nutzen
• Frühere Schwachstellenmeldungen waren ein Sonderfall, der von diesem Prinzip abwich
  • Sicherheitsforschende entschieden sich für eine nicht öffentliche Meldung, statt sofort zu veröffentlichen, damit das Projekt zuerst Zeit für eine Behebung hatte
  • Üblicherweise wurde erwartet, dass das Projekt die Meldung schnell bestätigt und untersucht, den Fortschritt mit den Meldenden teilt und am Ende die Entdeckung würdigt
• Diese Erwartung beruhte auf der Annahme, dass Meldende keine Personen waren, die Bugfixes oder Features einforderten, sondern dem Projekt einen Dienst erwiesen
  • Der zentrale Wert lag in Erkenntnis und Vertraulichkeit, damit ein Fix ausgeliefert werden konnte, bevor Angreifer einen Exploit veröffentlichten
  • Eine Schwachstellenmeldung zu ignorieren wurde als Signal verstanden, dass die Sicherheit der Nutzer nicht ernst genommen wird

Die 2026 zerbrochenen Annahmen

• 2026 lassen sich die Annahmen, die Schwachstellenmeldungen besonders gemacht haben, kaum noch aufrechterhalten
  • LLMs sind fast so gut wie nahezu alle Sicherheitsforschenden, und jeder kann sie ausführen
  • Dieselben Werkzeuge können auch Maintainer und Angreifer einsetzen
• Knapp ist nicht die Fähigkeit, potenzielle Probleme zu finden, sondern die Klassifizierungsarbeit, herauszufinden, was davon tatsächlich eine Schwachstelle ist
• Externe Forschende ohne bestehendes Vertrauensverhältnis können zu diesem Klassifizierungsprozess kaum sinnvoll beitragen
  • Das Signal-Rausch-Verhältnis beim Prüfen von LLM-Ausgaben ist fast dasselbe wie beim Durchsehen des security@-Posteingangs
• Auch die Bedeutung von Vertraulichkeit, Embargos und Koordination nimmt gegenüber früher ab
  • Angreifer müssen nicht auf vollständige öffentliche Offenlegungen warten, sondern können ihr eigenes LLM nach Schwachstellen fragen
  • Allerdings dürften auch Angreifer denselben Klassifizierungsengpass wie Verteidiger haben

Veränderte Prioritäten für Maintainer

• Die Zeit, in der Schwachstellenmeldungen etwas Besonderes waren, könnte vorbei sein
• Wichtiger sind heute Klassifizierung, schnelle Behebung und Prävention
• Es müssen Wege gefunden werden, LLM-Analysen in CI auszuführen
• Diese Position ist nicht die offizielle Haltung des Go Security Teams, sondern die persönliche Ansicht eines ehemaligen Leads des Go Security Teams
• Wenn die Bearbeitung von Schwachstellenmeldungen mit der Durchsetzung des Code of Conduct kollidiert, gibt es keine eindeutige richtige Antwort
  • Beurteilt werden muss je nach Schwere des Verhaltens, ob es sich um eine private Angelegenheit handelt oder die Community betrifft, und nach den Ressourcen des Teams, das security@ bearbeitet
• Öffentliche Praktiken haben eine komplexe Geschichte
  • In der Vergangenheit wurden gutwillige Forschende mit rechtlichen Drohungen oder Strafverfolgung konfrontiert
  • In der Open-Source-Realität von 2026 gibt es keine Forschenden mehr, die wegen Schwachstellenmeldungen eine Strafverfolgung fürchten, und Projekte sollten auch nicht mit Strafverfolgung drohen, als Alternative zu einer dokumentierten Meldungsrichtlinie
• Die einmonatige Aussetzung des Kanals für Schwachstellenmeldungen bei curl wirkte zunächst überzogen, aber zum Schutz der Nutzer ist es nicht mehr offensichtlich, dass die Reaktion auf Schwachstellenmeldungen die beste Nutzung der Zeit ist

[GN⁺]

Lobste.rs-Kommentare

• Ich denke weiterhin, dass eine vorschnelle Offenlegung von Schwachstellen Angreifern deutlich mehr hilft als Verteidigern. Nach dem, was ich selbst erlebt und beobachtet habe, kann selbst mit Frontline-Modellen die False-Positive-Rate bei fast 90 % liegen
  Nebenbei: Dort steht der Satz, dass „die nachhaltige Wartung und Entwicklung von Open-Source-Kryptoprotokollen für die breite Akzeptanz der Blockchain-Technologie wichtig ist“, und es überrascht mich, dass es immer noch Menschen gibt, die an Blockchain-Technologie glauben

  • Ich war verwirrt, warum dieser Satz dort stand, aber wie sich herausstellte, war das eine Botschaft von einem der Sponsoren von Fillippo
    Zum jetzigen Zeitpunkt könnte der wertvollste Beitrag der Blockchain-Technologie zur Welt tatsächlich darin bestehen, starke finanzielle Anreize dafür geschaffen zu haben, wirklich sichere Implementierungen von Kryptoprotokollen zu bauen. Ein Teil davon könnte auch für alle anderen nützlich werden
  • Ich frage mich, was hier mit False Positive gemeint ist. Dass das Modell behauptet hat, eine Schwachstelle gefunden zu haben, sich bei der Überprüfung aber herausstellte, dass es gar kein Problem war?
    Ich dachte, inzwischen sei ziemlich etabliert, dass LLMs beim Auffinden von Schwachstellen und ganz allgemein beim Verstehen von Code recht gut sind, daher würde mich interessieren, ob das tatsächlich so ist. Es wäre gut, wenn du etwas mehr aus deiner eigenen Erfahrung erzählen oder auf Material verweisen könntest, das man sich ansehen kann. Ich nutze keine LLMs und kann daher schwer einschätzen, wie weit das inzwischen ist, und frage mich ehrlich, ob ich meine Annahmen ändern sollte

• Besondere Schwachstellenmeldungen sollten besonders behandelt werden, und auf der Seite der Verteidiger braucht es bessere Verifizierungsverfahren und ein offengelegtes Threat Model. So können Menschen einen höheren Standard erfüllen und nachweisen, um als hervorragende Meldung anerkannt zu werden

  • Am Ende könnte es tatsächlich darauf hinauslaufen. Schwachstellenmeldungen sind im Allgemeinen nicht besonders, aber einige Meldungen mit hoher Schwere oder hoher Glaubwürdigkeit sollten als besondere Schwachstellenmeldungen betrachtet werden

• Ich stimme zu, dass es heute leichter geworden ist, Sicherheitsprobleme zu finden, und die Einstiegshürde niedriger ist, sodass Sicherheits-Mailinglisten wahrscheinlich stärker von Rauschen geprägt sind als früher. Trotzdem würde ich Bug-Reports von renommierten Sicherheitsberatungen wie Trail of Bits oder Zellic weiterhin klar priorisieren
  Nicht nur, weil ich glaube, dass sie keine schlampigen Reports einreichen, sondern auch, weil ich die Kombination aus Top-Sicherheitsforschern und LLMs für besser halte, als einfach ein LLM in CI laufen zu lassen

  • Ich habe kürzlich mit solchen Anbietern gearbeitet, und schlampige Reports kommen weiterhin vor. Die Qualität der Berichte ist nur insgesamt höher
    LLMs können unabhängig davon, wer sie steuert, das Threat Model missverstehen und beim Nachweis eines „Exploits“ nachlässig sein. Wenn Sicherheitsforscher solche Fehler übersehen, landen sie am Ende bei Maintainers wie uns. containerd hat schlampige Reports von solchen Anbietern, von LLM-Forschungsfirmen, von bekannten Foundation-Model-Unternehmen und auch von J Random User aus dem Internet erhalten
    Eine weitere Schwierigkeit, die Filippo hier nicht ausreichend anspricht, sind Doppelmeldungen. Wenn man sich die aktuellen Advisories von containerd ansieht, erkennt man, dass Duplikate ein weiteres großes Problem bei Triage und Aufmerksamkeitsverteilung sind. So wurden zum Beispiel 9 separate researchers/groups genannt, darunter auch renommierte Gruppen wie die zuvor erwähnten. Das zeigt, dass (a) LLMs, egal von wem sie eingesetzt werden, oft dieselben Probleme finden, und (b) ein Bericht von einem bekannten Melder nicht automatisch etwas Besonderes ist. Umgekehrt gab es bei diesem hier tatsächlich keine Doppelmeldungen, daher wurde nur einer Person gedankt, und dieser Melder war niemand, den wir vorher kannten oder zu dem wir eine Beziehung hatten