Ein neuer kostenloser Dienst soll Sicherheitslücken in verbreiteter Open-Source-Software finden. Anthropic lässt dafür Sprachmodelle Quellcode untersuchen und schickt Berichte direkt an teilnehmende Projekte. Der entscheidende Haken steht in der eigenen Dokumentation: Die Hinweise werden vor dem Versand nicht von Menschen geprüft.

Anthropic nennt dennoch eine hohe Quote. Von 97 ausgewählten Funden mit angeblich hoher oder kritischer Schwere hätten 85 den Standard des eigenen Verfahrens zur koordinierten Offenlegung erfüllt. Das sind rechnerisch rund 88 Prozent. Die Zahl darf aber nicht auf alle Ergebnisse übertragen werden: Geprüft wurde eine ausgewählte Teilmenge aus 48 Projekten, nicht jeder der mehr als 29.000 zuvor erzeugten Kandidaten.

Der technische Ablauf bietet gute Voraussetzungen für eine Prüfung. Projekte melden sich freiwillig an, beschreiben Bauumgebung und möglichst ihr Bedrohungsmodell. Der Quellcode wird zunächst in einer isolierten virtuellen Maschine gebaut; die eigentliche Analyse läuft laut Repository ohne Internetzugang. Berichte sollen Reproduktionsschritte und, wenn verfügbar, einen Patchvorschlag enthalten.

Für Maintainer beginnt damit erst die eigentliche Sicherheitsarbeit. Ein belastbarer Ablauf hat fünf Stufen: den Fund in einer isolierten Umgebung reproduzieren, betroffene Version und Angriffsweg bestätigen, den Schweregrad am eigenen Bedrohungsmodell prüfen, den Patch samt Regressionstest ausführen und erst danach die Veröffentlichung koordinieren. Ein nicht reproduzierbarer Hinweis ist noch keine bestätigte Lücke.

Ein Vergleich mit OSS-Fuzz zeigt, warum diese Trennung wichtig ist. Das etablierte Fuzzing-System meldet in der kontinuierlichen Integration einen Absturz nur, wenn er reproduzierbar ist und nicht schon in älteren Builds auftritt. Ein Sprachmodell kann andere Fehlerklassen entdecken, sollte aber denselben Grundsatz nicht umgehen: Ein plausibler Bericht braucht einen überprüfbaren technischen Nachweis.

Das größte Risiko ist deshalb nicht nur ein falscher Alarm. Tausende richtige, doppelte und falsch priorisierte Hinweise können kleine Projekte überfordern. Ein vorgeschlagener Patch kann außerdem Nebenwirkungen haben. Projekte sollten vor einer Teilnahme festlegen, wer Berichte annimmt, wie dringende Fälle priorisiert werden und welche vertraulichen Meldewege gelten.

Der Scanner kann nützlich sein, wenn ein Projekt genug Kapazität für die Nachprüfung besitzt. Die Anbieterquote belegt aber keine allgemeine Zuverlässigkeit. Aussagekräftiger wären künftig unabhängig ausgewertete Daten: Anteil reproduzierbarer Funde, Duplikate, falsch bewertete Schweregrade, Zeit bis zum Patch und neu verursachte Fehler.