Anthropic: Gratis-Scans ohne menschliche Vorprüfung

Anthropic stellte am 8. Oktober 2026 in seiner Ankündigung zum OSS Scanner einen kostenlosen Dienst für aufgenommene Open-Source-Projekte vor: Er soll deren Code regelmäßig auf Schwachstellen prüfen und die modellgenerierten Funde ohne vorherige menschliche Sichtung an Maintainer senden. Die schnellere Zustellung hat eine unmittelbare Folge: Ein Bericht kann auch einen unzutreffenden Fund enthalten.

Teilnehmen können Kern-Maintainer geeigneter Projekte nach einer Bewerbung; ein Scan beliebiger Repositories auf Abruf ist damit nicht angekündigt. Die Berichte enthalten einen eigenständig ausführbaren Nachweis und eine Erklärung des möglichen Fehlers, nach Möglichkeit auch einen Patch-Vorschlag. Ob der Fund für das Projekt tatsächlich ausnutzbar ist und ob eine Korrektur sicher funktioniert, müssen die Maintainer selbst beurteilen.

Warum die Berichte ohne Vorprüfung ankommen

Anthropic hat die menschliche Sichtung als Engpass seiner bisherigen Schwachstellenmeldungen beschrieben. Einige Maintainer baten bereits darum, auch ungeprüfte Modellfunde zu erhalten, um mögliche Fehler früher bearbeiten zu können. Aus dieser freiwilligen Abkürzung wird nun ein regelmäßiges Angebot für Projekte, die solche Meldungen selbst einordnen können. Für andere Projekte soll das bestehende Verfahren mit menschlich geprüften Hinweisen weiterlaufen.

Der Dienst nutzt Anthropics leistungsstärkste Modelle, darunter Claude Mythos. Ein Bericht kann außerdem eingrenzen, wann ein Fehler in den Code gelangte; ein Patch-Kandidat gehört nur dazu, wenn das Modell einen liefern kann. Gerade diese Kombination macht eine Meldung nützlich: Der Nachweis gibt dem Projekt einen konkreten Ausgangspunkt für die Reproduktion, während der Änderungsvorschlag die mögliche Reparatur sichtbar macht. Weder der Nachweis noch der Vorschlag ersetzt jedoch die Prüfung im vorgesehenen Einsatz des Projekts.

Was die Prüfung einer frühen Version zeigt

Die Analyse von SiliconANGLE nennt 97 als hoch oder kritisch eingestufte Funde einer frühen Scanner-Version aus 48 Projekten: Externe Prüfer akzeptierten 85 für das koordinierte Meldeverfahren, elf weitere betrafen reale, aber bekannte oder doppelt erfasste Probleme, und einer war ungültig; sie zitiert OpenSSL-Vertreter Anton Arapov zu einem Bericht mit echtem Exploit mit „basically job done for an engineer“. Das ist ein ermutigender Befund für diese ausgewählte Gruppe schwerwiegender Meldungen, aber keine Fehlerquote für sämtliche künftigen Scans.

Auch ein realer Softwarefehler kann für ein Projekt anders zu bewerten sein, als der Scanner vorschlägt. Anthropic nennt überhöhte Schweregrade und ein falsch verstandenes Bedrohungsmodell als mögliche Probleme. Ein reproduzierbarer Absturz etwa zeigt ein Verhalten des Programms; ob ein Angreifer es unter unterstützten Konfigurationen auslösen und für einen Angriff nutzen kann, hängt von Eingaben, Berechtigungen und erreichbaren Schnittstellen ab. Dieselbe technische Beobachtung kann deshalb je nach Projekt eine andere Priorität erhalten.

Wer aufgenommen wird und wie die Meldungen zugestellt werden

Für die Bewerbung beschreibt Anthropics Anmelde-Repository einen Pull Request mit Projektkonfiguration und Dockerfile; eine Datei zum projektspezifischen Bedrohungsmodell ist optional. Die Aufnahme wird im Einzelfall entschieden und richtet sich an Projekte mit erheblicher Bedeutung für Infrastruktur und Nutzersicherheit. Die Konfiguration enthält eine Kontaktadresse für Berichte, die im öffentlichen Pull Request sichtbar ist. Eine dafür vorgesehene Sicherheitsadresse vermeidet, dass eine persönliche Mailadresse veröffentlicht werden muss.

Nach der Aufnahme baut Anthropic das Projekt in einer isolierten virtuellen Maschine mit Netzzugang und führt die anschließende Analyse ohne Internetverbindung aus. Meldungen gehen per E-Mail an den angegebenen Kontakt; verschlüsselter Versand ist möglich. Das Projekt kann weitere Berichte pausieren oder seine Anmeldung zurückziehen. Für ungeprüfte Scanner-Funde ist keine automatische öffentliche Bekanntgabe nach Ablauf einer Frist vorgesehen; wird ein Fund später im herkömmlichen Verfahren menschlich bestätigt, gelten dessen gesonderte Regeln.

Kostenlos zugesagt ist die Scanleistung für aufgenommene Projekte. Die Zeit für Sichtung, Reproduktion, Prüfung eines Patches und Veröffentlichung einer Korrektur trägt weiterhin das Projekt. Eine verbindliche Scanfrequenz, eine Bearbeitungsfrist für Bewerbungen und eine belastbare Fehlerquote des laufenden Angebots sind bislang nicht angegeben. Damit hängt der praktische Nutzen auch davon ab, wie viele Meldungen ein Maintainer-Team bearbeiten kann.

Vom Scanner-Fund zur sicheren Korrektur

Die fehlende Vorprüfung verlagert die entscheidende Sicherheitsarbeit auf das Projekt. Für Maintainer ergibt sich daraus ein nachvollziehbarer Ablauf; die folgenden Schritte sind eine redaktionelle Einordnung und keine Zusage, dass Anthropic sie vor dem Versand ausführt.

Fund reproduzieren: Das mitgelieferte Beispiel gegen die betroffene Version in einer isolierten Testumgebung ausführen und Eingaben, Abhängigkeiten sowie Einstellungen festhalten. Lässt sich das Verhalten nicht nachvollziehen, bleibt die Meldung zunächst ungeklärt. Eine plausibel klingende Erklärung allein macht aus einem Modellfund noch keine bestätigte Schwachstelle.
Ausnutzbarkeit bewerten: Prüfen, ob ein Angreifer die nötigen Bedingungen im vorgesehenen Einsatz herstellen kann. Entscheidend sind unter anderem erreichbare Schnittstellen, erforderliche Rechte und das Bedrohungsmodell des Projekts. Erst diese Einordnung zeigt, welche Nutzer oder unterstützten Konfigurationen betroffen sein könnten und wie dringlich eine Korrektur ist.
Patch isoliert testen: Den Vorschlag wie jede andere Codeänderung prüfen. Er sollte den reproduzierten Fehler verhindern, bestehende Tests bestehen und zulässiges Verhalten erhalten. Tests für benachbarte Eingaben und betroffene Varianten können zeigen, ob die Änderung das Problem umfassend behebt oder lediglich den vorgelegten Nachweis unwirksam macht.
Änderung freigeben: Einen bestätigten Fund und die geprüfte Korrektur durch den üblichen Review- und Veröffentlichungsprozess führen. Dort entscheidet das Projekt auch, welche unterstützten Versionen einen Fix benötigen und wann Nutzer informiert werden. Ein automatisch vorgeschlagener Patch nimmt diese Entscheidungen nicht vorweg.

Mit den ersten regelmäßigen Lieferungen wird für teilnehmende Projekte vor allem eine Größe sichtbar werden: wie viel Prüfaufwand zwischen einem schnellen Modellbericht und einem sicher veröffentlichten Fix liegt.

Lesen Sie auch: