Wie sind die tatsächlichen Leistungen von Glasswing in sieben Monaten?

Nach den Daten von VulnCheck als Drittanbieter: 442 CVEs, durchschnittlich etwa 63 pro Monat, was etwa 0,5% aller CVEs des Jahres entspricht. Nur 2 wurden in der Praxis genutzt; Anthropic hat selbst 37.966 Berichte, 217 Behebungen und 7.349 öffentliche Angaben gemeldet. Sowohl die Zahlen als auch die Darstellung „tausende hochriskante und schwerwiegende Lücken“ beim Start stehen in Widerspruch zueinander.

Warum sind die Überprüfungsergebnisse von curl wichtig?

Dies ist ein seltenes Beispiel dafür, wie die Betreuer die AI-Falldiagnosen einzeln überprüfen und ihre Ergebnisse öffentlich machen: Von 45 Berichten wurden 34 überprüft, 19 als „nicht gefährlich“ eingestuft, 6 als geringgradig gefährlich bestätigt und 9 noch bewertet. Die falsch-positive Rate beträgt 55,9%; während die Selbstbewertung von Anthropic eine echte positive Rate von 94,2% aufweist. Die unterschiedlichen Angaben können nicht übereinstimmen, und der Unterschied zeigt, dass die Überprülungslast auf die Betreuer übertragen wird.

Kann dieser Bericht vollständig akzeptiert werden?

Nein. VulnCheck ist ein Hacker-Insider, der mit Anthropic konkurriert. In den Kommentaren von HN wurde darauf hingewiesen, dass seine Schlussfolgerungen mit seinem eigenen Geschäftsmodell übereinstimmen; außerdem sind 80,6 % der Erkenntnisse im Buchhaltungsmaterial nicht öffentlich, weshalb die Qualität nicht bekannt ist und es sich um Survivable-Analysen handelt. Die richtige Lesart ist, dass die beiden Zahlen jeweils eigene Angaben haben und erst an den Überschneidungspunkten eine Entscheidung getroffen wird, ohne eine Seitensteuerung.

Hot Tracking 041 | 37.966 Berichte, nur 217 wurden behoben

Was passiert

Hintergrund: Am 7. April 2026 startete Anthropic das Project Glasswing. Die offizielle Aussage zur Veröffentlichung lautete: „Tausende zusätzliche hochriskante und schwerwiegende Sicherheitslücken wurden identifiziert und verantwortungsvoll an die Open-Source-Entwickler weitergeleitet.“ Der Start war sehr bemerkenswert: Am 22. Mai gab es eine Veröffentlichung unter HN 1541▲/836💬, am 2. Juni eine Erweiterung von 561▲ und am 2. Juni eine weitere Erweiterung von 180▲. Im Mai startete Anthropic sein eigenes Verzeichnis der enthüllten Sicherheitslücken (ledger), das nur gelegentlich in großen Mengen aktualisiert wurde. Am 8. Oktober veröffentlichte Anthropic den Selbstscannungsdienst OSS Scanner, mit dem mehr als 29.000 potenzielle Sicherheitslücken entdeckt wurden, aber nur etwa 6.000 davon manuell überprüft wurden. „Der Engpass liegt in der menschlichen Überprüfung“, so die offizielle Aussage von Anthropic. Zudem wurden fast 5.000 ungeprüfte Berichte an die Entwickler gesendet, die eine vollständige Übertragung verlangten. „Vollständige Modellgenerierung, keine manuelle Überprüfung oder Drei-Schritte-Methode“ sind die offiziellen Aussagen von Anthropic.

Audit: VulnCheck begann am 17. April mit der Erfassung, früher als das eigenständige Verzeichnis von Anthropic. Die Methode bestand darin, den Open-Source-Repository von Anthropic zu überwachen, CVEs zu erfassen und diese mit CVE-Protokollen, GHSA-Daten, Linux-Kernel-Commitments sowie dem eigenen Verzeichnis von Anthropic zu vergleichen. Dabei wurden die Berichte manuell überprüft. Dies war nicht das erste Mal, dass VulnCheck seine Ergebnisse veröffentlichte: Seit dem ersten Bericht vom 15. April wurden bereits Berichte über das Verzeichnis (9. Juni), einen Bericht über die Nutzung der Lücken (28. Juli) und eine letzte Phase der Überprüfung (8. September) veröffentlicht. Dieser Bericht ist die fünfte Aktualisierung in sieben Monaten. Die Ergebnisse der letzten sieben Monate (alle von VulnCheck veröffentlicht): Insgesamt gab es 442 CVEs, die auf Anthropic zurückgeführt werden konnten, mit einem Durchschnitt von etwa 63 pro Monat, was etwa 0,5% aller 93.450 CVEs des Jahres entspricht. Von den 442 CVEs wurden nur 2 in der Praxis genutzt (0,45%, CVE-2026-61500 und CVE-2026-26980, verglichen mit dem KEV von VulnCheck). Ein weiterer Vergleich: Die 442 CVEs, die von VulnCheck erfasst wurden, überstiegen das Niveau der behobenen CVEs in dem eigenen Verzeichnis von Anthropic (217, laut Anthropic selbst).

Überprüfung durch Entwickler: Vor etwa dem 6. November, drei Tage vor der Veröffentlichung des Blogs, gab der Entwickler von curl, Daniel Stenberg, bekannt, dass Anthropic ihm 45 Sicherheitslückenberichte geschickt habe. Anthropic selbst gab an, nur 1 mittelschweres Problem zu haben, die restlichen seien alle geringfügig. Daniel verlangsamte absichtlich den Transfer der Berichte auf GitHub, um „den Team einen Schaden zu ersparen“ und plante, alle Berichte innerhalb dieser Woche öffentlich zu machen. Von den 34 öffentlich gemachten Berichten wurden 19 als „nicht Sicherheitslücken“ klassifiziert, 6 als geringfügig, und 9 wurden zur Bewertung gelassen. Die Fehlbestimmungsrate lag bei 55,9%, die Bestätigungsrate bei 17,6% und alle Berichte waren geringfügig. Das war nicht das erste Mal: Im Mai dieses Jahres schrieb Daniel über fünf Mythos-Findungen, von denen nur eine Sicherheitslücke tatsächlich identifiziert wurde. Bis zum Zeitpunkt der Veröffentlichung hatte Anthropic keine positive Reaktion auf diesen Bericht erhalten (weder HN noch Blog gaben eine Antwort).

Verzeichnisaudit: Steigende Anzahl von Entdeckungen, stagnierende Behebung

Wenn man die von Anthropic angegebenen Zahlen nach Zeitreihen auflistet, sprechen die Probleme von selbst. Bei der Einführung im Mai gab es 23.019 Erkenntnisse, mit einer angeblichen echten Positivrate von 90,8%. Die neueste Aktualisierung vom 2. November: 37.966 Erkenntnisse, davon nur 217 als behoben markiert, und 7.349 (19,4%) wurden öffentlich gemacht.

Wenn man sich die Veränderungen in den letzten zwei Monaten vom 09-08 bis 11-02 ansieht (alle von Anthropic selbst angegeben): Die Gesamtzahl der Erkenntnisse stieg von 26.153 auf 37.966 (+11.813); die Anzahl der öffentlich gemachten Erkenntnisse von 2.736 auf 7.349; die Anzahl der behobenen Erkenntnisse stieg von 202 auf 217 (+15); die Anzahl der zurückgezogenen Erkenntnisse von 245 auf 419 (+174); die Anzahl der wiederholten Erkenntnisse stieg von 2 auf 1.670 (+1.668). Insgesamt gab es 1.654 wiederholte Erkenntnisse (4,4%), was etwa 7,5 Mal so viel ist wie die Anzahl der behobenen Erkenntnisse. Der Anstieg der wiederholten Erkenntnisse ist kein Zufall: VulnCheck hatte bereits in seiner letzten Aktualisierung im September gewarnt, dass je länger die Berichte im System liegen, desto höher ist die Wahrscheinlichkeit, dass andere dieselbe Schwachstelle zuerst entdecken und beheben. Zwei Monate später bestätigte sich diese Prognose: Die Anzahl der entdeckten Erkenntnisse konnte nicht vollständig abgedeckt werden, die Anzahl der behobenen Erkenntnisse war begrenzt, und das, was dazwischen lag, waren wiederholte und zurückgezogene Berichte.

Die Anzahl der entdeckten Erkenntnisse stieg in zwei Monaten um fast die Hälfte, die Anzahl der behobenen Erkenntnisse stieg nur um 15; der Anstieg bei zurückgezogenen und wiederholten Berichten war größer als der Anstieg bei behobenen Berichten. Das Problem, das VulnCheck festgestellt hat, liegt hier: Es wurden mehr zurückgezogene und wiederholte Berichte gemeldet als behobene, während die angegebene echte Positivrate von 90,8% auf 94,2% stieg (im Zeitraum vom 09-08 lag sie bei 91,4%, +2,8 Punkte). Das System könnte einen „dreifachen Nicht-Ausweis“ als Feedback-Rücklauf fehlen; Berichte, die von den Betreuern als „nicht als Schwachstelle erkannt“ eingestuft wurden, wurden nicht mitgezählt. Darüber hinaus hat VulnCheck einen Fehler im System entdeckt, bei dem bereits offiziell gemeldete Schwachstellen übertrieben angegeben werden (der Filter „disclosed“ lässt diesen Fehler wiederholen).

Auch die Schwere der Schwachstellen stimmt nicht überein. VulnCheck hatte im September festgestellt, dass Claude 91,5% der Erkenntnisse im System als schwerwiegend/hochrisikovorbelastet einstufte, während die Betreuer nur 51,3% als solche einstuften. Bei denselben Berichten lag der Unterschied zwischen der automatischen Bewertung durch das System und der Bewertung durch die Betreuer bei 40 Prozentpunkten.

Die Übertragung der Überprülungslast: Vom OSS Scanner zum curl

Der zweite Kritikpunkt ist nicht die Zahlen, sondern der Prozess. Da jeder einzelne entdeckte Fehler offensichtlich nicht skalierbar ist, sagte Anthropic selbst dies auch, und so kam es am 8. Oktober zur Änderung: Der OSS Scanner wurde in einen Selbstbedienungsmodus umgestellt, wodurch die Betreuer selbst Scans anfordern und die Ergebnisse bewerten konnten. Nach der Einführung des OSS Scanners wurden nur etwa 6.000 von 29.000 potenziellen Schwachstellen manuell überprüft, während fast 5.000 ungeprüfte Berichte direkt an die Betreuer gesendet wurden, die eine vollständige Zugangsdaten erhielten. Laut Anthropic wurden diese Berichte vollständig automatisch generiert, ohne manuelle Überprüfung oder Bewertung. Wenn die Anzahl der entdeckten Fehler nicht vollständig abgedeckt werden kann, wer soll dann die Überprülungslast tragen? Das Beispiel mit curl gibt die Antwort: Die Betreuer übernehmen diese Last selbst. Hier liegt eine eigene Logik von Anthropic: Der Grund für die Einführung des Selbstbedienungsscanners ist, dass „wenn die angegebene echte Positivrate tatsächlich so hoch ist wie behauptet, sollte es kein Problem sein, wenn die Betreuer selbst die Ergebnisse bewerten“. Die 55,9% falscher Positivraten bei curl zeigen, dass diese Annahme nicht zutrifft; der Kostenfaktor des Selbstbedienungsmodus wird tatsächlich durch die Arbeitszeit der Betreuer getragen.

Daniels Handlungen nach dem Erhalt von 45 Berichten sollten genauer betrachtet werden: Er verlangsamte die Übertragung auf GitHub, um „den Druck auf das Team zu verringern“. Er überprüfte jeden Bericht einzeln und öffentlichte alle niedrig- und mittelschweren Sicherheitslücken als Issues. VulnCheck kommentierte dies damit, dass die Betreiber sich durch „Rhythmuskontrolle“ schützen müssen – was bereits eine Belastung darstellt. Die Entscheidung von curl, alle Informationen öffentlich zu machen, ist ein Beispiel für Transparenz.

Es ist wichtig, die Grenzen der Kritik zu kennzeichnen: Sowohl dieser Artikel als auch VulnCheck lehnen es nicht ab, dass AI zur Erkennung von Sicherheitslücken effektiv ist. VulnCheck hat selbst betont, dass AI ein effektives Werkzeug ist, und die 442 CVEs sind tatsächlich durch die Nutzer eingetragen worden. Die Kritik gilt zwei Dingen: der Darstellung des Erkennungsvolumens und der Übertragung der Verifizierungskosten auf die Open-Source-Betreiber.

Überprüfung der Handlungen: Der ursprüngliche Versprechung entspricht nicht dem tatsächlichen Verlauf

Der erste Schritt, das Versprechen bezüglich des Volumens. Zu Beginn wurde gesagt, dass „tausende zusätzlicher hochriskanter und schwerwiegender Sicherheitslücken“ gefunden wurden. Sieben Monate später lag VulnCheck bei 442 CVEs, was etwa 0,5% des Jahresvolumens entspricht, wobei nur 2 Lücken tatsächlich genutzt wurden. Zwischen Tausenden und 442 CVEs liegt eine Differenz, selbst wenn alle 7.349 bereits öffentlich gemachten Erkenntnisse als CVEs gezählt werden – doch curl gibt einen Umrechnungsfaktor von 17,6% an, wobei alle Lücken niedrige Risiken aufweisen.

Der zweite Schritt, das Versprechen bezüglich der Qualität. Die andere Seite der „verantwortungsvollen Offenlegung“ ist die Qualität der Offenlegung: Die Selbstbewertung von VulnCheck mit einer wahren Erkennungsrate von 94,2% (gemessen an Anthropic) steht im Gegensatz zur falsch erkannten Rate von 55,9% (gemessen von den Betreibern) bei curl. Claude hat eine Selbstbewertung von 91,5% für schwerwiegende/hochriskante Lücken, während die Betreiber nur 51,3% anerkennen. Diese beiden Zahlen können nicht gleich sein.

Der dritte Schritt, die Art der Reaktion. Das Buchhaltungsprotokoll wurde nur im Massenformat aktualisiert, ohne eine Feedback-Kommunikation zu haben. Nach der Veröffentlichung des Berichts gab es keine positive Reaktion. Der Aufruf zu Beginn mit 1541▲ und die Kälte des Berichts mit 35▲ zeigen, dass die Behörden keine Lösung gefunden haben. Der Rhythmus selbst ist bemerkenswert: Drei offizielle Veröffentlichungen wurden mit großer Aufmerksamkeit begleitet, während es nach sieben Monaten Kontrolle durch Dritte still blieb.

Die ursprüngliche Bewertung von VulnCheck lautete: Die Beweise stimmen nicht mit der ursprünglichen Erklärung überein – die Beweise entsprechen nicht dem Versprechen zu Beginn. Dieser Artikel hält an dieser Distanz fest: Es wird nicht beschuldigt, „versagt“ oder „fälscht“ zu sein, sondern nur, dass die Zahlen nicht übereinstimmen. Gleichzeitig müssen beide Seiten eingeschränkt werden: VulnCheck hat wettbewerbsintensive Interessen, und seine Schlussfolgerungen könnten Werbung sein (der Nutzer jrflo hat dies bereits angedeutet). Was die Qualität der 80,6% nicht öffentlich gemachter Erkenntnisse angeht, weiß niemand genau, daher kann man die offiziell veröffentlichten 19,4% nicht als repräsentativ für alles betrachten. Das ist eine Analyse der Überlebenden – der Hinweis des Nutzers dfee gilt, und dieser Artikel fällt keine Seite ein.

Was sagt die Kommentarbereich?

35▲ HN-Beiträge mit nur 6 Kommentaren – wenig, aber die Richtung ist wichtig. Es wird in vier Bereiche unterteilt.

Erstens, der „Wolfsalarm“-Ansatz. Der Nutzer fny sagte, dass das offensichtlichste Signal darin besteht, dass in den letzten einem Jahr keine Katastrophenlücken gefunden wurden. Wenn tausende hochriskante Lücken tatsächlich gefunden worden wären, sollten die Zahlen für die Nutzung im Feld nicht so niedrig sein.

II. Der Weg des Überlebenden Bias. Benutzer dfee erinnert daran: Nur 19,4% der Ergebnisse sind öffentlich zugänglich. Dieser Artikel analysiert die überlebenden Ergebnisse, während der restliche 80% unbekannt oder nicht geprüft sind. Es ist wichtig, vorsichtig zu sein mit den Schlussfolgerungen. Benutzer hologramofham stellt die gleiche Frage: Der Artikel zieht große Schlussfolgerungen aus dem öffentlich verfügbaren 19,4%, doch dieser Prozentsatz könnte auch etwas anderes bedeuten. In den nicht öffentlich zugänglichen Teilen könnten sensibele Ergebnisse stehen, die nicht veröffentlicht werden sollten. Es ist unmöglich, diese beiden Möglichkeiten auseinanderzuhalten, allein aufgrund der bereits veröffentlichten Daten.

III. Der Weg des Interessenkonflikts. Benutzer jrflo weist darauf hin, dass die Schlussfolgerungen von VulnCheck stark mit seinem Geschäftsmodell übereinstimmen: Hersteller, die Sicherheitslücken informieren, kritisieren andere für schlechte Qualität ihrer Berichte über Lücken, was auf Werbung hindeuten könnte.

IV. Bis zur Überprüfung hat Anthropic keine Antwort auf HN oder Blogs gegeben.

Drei Dinge, die normale Benutzer tun können

Wenn Sie einen von AI generierten Sicherheitslückenbericht erhalten, folgen Sie zuerst Ihrem eigenen Prozess. Wenn Sie ein Administrator oder Sicherheitsverantwortlicher sind: Akzeptieren Sie nicht direkt die Schweregrade in den Berichten: 91,5% als ernsthaft/hochgefährlich, während Administratoren nur 51,3% als ernsthaft akzeptieren. Es gibt Beispiele für Inflation der Schweregrade. Die Vorgehensweise von curl kann übernommen werden: Massenempfang, Kontrolle des Tempos, individuelle Überprüfung und öffentliche Schlussfolgerungen.
Überprüfen Sie vor dem Patchen die praktische Nutzung der Lücken. Lassen Sie sich nicht von „hochgefährlich“ leiten. Von den 442 CVEs wurden nur 2 in der Praxis genutzt (0,45%). Bei der Priorisierung sollten Sie sich auf das KEV-Verzeichnis und die Aufzeichnungen von GHSA stützen und Ihre begrenzte Reparaturzeit auf echte Lücken verwenden.
Beobachten Sie die nächsten beiden Punkte. Erstens die vollständige Fehlpositivitätsrate nach der öffentlichen Veröffentlichung aller 45 Berichte von curl in dieser Woche. Zweitens, ob Anthropic antwortet und ob die Berichte den drei-stufigen Feedback-Kreislauf wiederherstellen. Sobald etwas passiert, wird der Artikel aktualisiert.

Schlussfolgerung

Grenzen setzen: Dieser Artikel schreibt nicht über „Fehlschlag von Glasswing“ oder „Datenfälschung“. Alle Zahlen werden in zwei verschiedenen Formaten angegeben. 442, 2, 0,5%, 55,9%, 17,6%, 91,5% vs. 51,3% sind die Angaben von VulnCheck oder der Überprüfung durch Administratoren; 23.019, 37.966, 217, 7.349, 94,2% sind die Angaben von Anthropic selbst. Der Kritikpunkt ist nicht das „AI finden von Lücken“, sondern die Trennung zwischen der Erkenntnis und der Reparatur der Realität sowie die Verschiebung der Überprüfungslast auf die offiziellen Administratoren. Die Wettbewerbsinteressen von VulnCheck und die Ungewissheit bezüglich 80,6% der nicht öffentlich zugänglichen Ergebnisse werden beide in den Text eingefügt, ohne eine Seite zu verurteilen.

Die Überprüfung selbst ist wertvoller als die Qualifikation: Um glaubwürdig zu sein, fehlt es nicht an einer höheren tatsächlichen Fehlpositivitätsrate, sondern an einem Mechanismus, der den Administratoren ermöglicht, die Ergebnisse zurückzuverfolgen. Innerhalb von 48 Stunden (11-09 Blogveröffentlichung, 11-10 HN-Veröffentlichung) wird der Artikel aktualisiert, sobald Anthropic eine Antwort gibt oder die vollständigen Überprüfungsergebnisse von curl verfügbar sind.

Referenzquellen

VulnCheck-Blog: „Nach 7 Monaten überwältigt Glasswing die Maintainer mit enttäuschenden Ergebnissen“ (veröffentlicht von Patrick Garrity am 09.11.2026, vollständiger Text zur Überprüfung von 200 Stellen; Quelle direkt, aber beachten Sie die Position der Konkurrenzprodukte).
Offizielle Stellungnahme von Anthropic: Ankündigung des Projekts Glasswing (07.04.2026), Offener Buchhaltungsbuch (erschien am Mai, letzte Aktualisierung am 02.11.), Selbstbeschreibung von OSS Scanner (08.10.2026; „Vollständige Modellgenerierung, keine manuellen Überprüfungen oder Drei-Schritte-Verfahren“ sind die offiziellen Aussagen).
Öffentliche Aussage des Curl-Maintainers Daniel Stenberg (ab ca. 06.11.2026; 45 Berichte, 34 Überprüfungsergebnisse stellen die Maintainer-Daten dar).
Hacker News-Story 50447074 (veröffentlicht am 10.11.2026, zum Zeitpunkt der Schreibung 35▲/6💬, Algolia-Snapshots; alle Kommentare wurden wiedergegeben, der Benutzername bleibt erhalten).
Historische Popularitätsdaten von HN (Startbeitrag am 07.04.: 1541▲/836💬, Aktualisierung am 22.05.: 561▲, Erweiterung am 02.06.: 180▲, alle historische Snapshot-Daten).

Unterzeichner: Yongliang