OSS Scanner: Anthropic verschiebt die Triage
Anthropic scannt Open-Source-Projekte kostenlos auf Lücken. Die Berichte prüft vorher kein Mensch, die Triage bleibt beim Maintainer. Was das heißt.
Anthropic hat am 08.10.2026 den OSS Scanner gestartet. Open-Source-Projekte können sich anmelden und bekommen ihren Code regelmäßig und kostenlos von Anthropics stärksten Modellen auf Sicherheitslücken durchsucht, laut Ankündigung einschließlich Claude Mythos. Vorbild ist Googles OSS-Fuzz, nur dass hier Sprachmodelle suchen statt Fuzzer.
Der Haken steht im selben Text: Die Berichte sind "fully model-generated, without human review or triage". Was das Modell für eine Lücke hält, geht direkt an die Maintainer. Anthropic löst damit ein eigenes Problem. Ob es auch das der Maintainer löst, hängt davon ab, wie viel Zeit sie haben.
Was angeboten wird
| Punkt | Regelung |
|---|---|
| Anmeldung | Pull Request im Repo anthropics/oss-scanner mit projects/<name>/project.yaml. Anthropic prüft von Hand, ob der Antragsteller Core-Maintainer ist |
| Wer aufgenommen wird | Etablierte Projekte mit "critical impact on infrastructure and user security", Entscheidung im Einzelfall. Anthropic kann die Aufnahme jederzeit zurücknehmen |
| Was ihr liefern müsst | Repo-URL, eine Kontaktadresse und ein Dockerfile, das alle Abhängigkeiten installiert und das Projekt baut. Der Scan selbst läuft ohne Internetzugang |
| Was ihr bekommt | Ein Bündel Berichte per E-Mail, jeweils mit Reproducer, Erklärung, wo möglich einer Bisection und einem Patch-Vorschlag |
| Prüfung vor dem Versand | Agenten prüfen die Funde gegen, ein Mensch nicht |
| Frist | Keine. Erst wenn Anthropic einen Fund später von Hand bestätigt, laufen 90 Tage bis zur Veröffentlichung |
| Kosten | Keine |
| Ausstieg | disabled: true pausiert, das Löschen des Projektordners beendet die Teilnahme, beides per Pull Request |
Am 10.10.2026 lagen neun Projekte im Repo: bitcoin-core, botan, homebrew, libheif, nestjs, nss, nuclei, nvm und zmap.
Die Zahlen und was sie nicht zeigen
Anthropic belegt die Qualität mit einer Stichprobe. Die Pentester, die sonst Anthropics eigene Meldungen prüfen, sahen sich 97 Funde der Stufen kritisch und hoch aus 48 Projekten an. 85 davon erfüllten die Anforderungen für eine reguläre Meldung, 11 waren echt, aber Duplikate, einer war falsch. Dazu kommen Stimmen von Maintainern. Todd Ouska von wolfSSL: "of the 74 reports we received, all but two were valid, and five became CVEs". Daniel Stenberg schreibt, der Scanner habe in curl "one of the worst curl vulnerabilities reported in the last few years" gefunden.
Das sind gute Werte. Drei Dinge decken sie nicht ab.
Nur die oberen Stufen. Gemessen wurden kritische und hohe Funde. Wie viele Berichte der Stufen mittel und niedrig ein Projekt bekommt und wie oft die stimmen, steht nirgends. Gerade dort entsteht bei einer Triage die Fleißarbeit.
Eine frühe Version, von Anthropic geprüft. Die Stichprobe stammt nach Anthropics Angabe aus einer frühen Fassung des Scanners, bewertet haben sie Leute, die in Anthropics Auftrag prüfen. Für den laufenden Betrieb nennt Anthropic nur eine Erwartung: eine Trefferquote über 90 Prozent (Cyber Mission).
Echt heißt nicht richtig eingestuft. Anthropic räumt ein, dass Maintainer überhöhte Schweregrade bemängelt haben und dass der Scanner das Bedrohungsmodell eines Projekts falsch verstanden hat. Das Agreement wird deutlicher: Ein Bericht könne Dinge als Lücke beschreiben, die keine sind, und Patches vorschlagen, "that are incomplete or that impair or break functionality".
Der Engpass zieht um
Warum es den Dienst gibt, sagt Anthropic offen. In sechs Monaten haben die Modelle über 29.000 mögliche Lücken in wichtiger Open-Source-Software gefunden. Von Hand geprüft hat Anthropic rund 6.000 davon: "we remain bottlenecked on our human capacity to validate these findings". Mehr als drei Viertel der Kandidaten hat dort also kein Mensch angesehen.
Der OSS Scanner beseitigt diesen Engpass nicht. Er gibt die Prüfung an die Leute weiter, die auch den Fix schreiben müssen. Fairerweise: Niemand wird dazu gezwungen. Der Dienst ist freiwillig, und Anthropic berichtet, dass Maintainer von sich aus nach den ungeprüften Rohdaten gefragt und knapp 5.000 Berichte so bekommen haben. Für ein Projekt mit eigenem Sicherheitsteam ist ein Fund mit lauffähigem Exploit schnell geprüft.
Unsere Kritik setzt an drei anderen Stellen an.
Erstens hilft der Dienst denen, die es am wenigsten brauchen. Die FAQ sagt es selbst: Das Angebot richtet sich an Projekte, die mit bestätigten Meldungen der Stufen hoch und kritisch schon Schritt halten. PostgreSQL, OpenSSL und curl gehören dazu. Die Bibliothek, die zwei Leute nach Feierabend pflegen und von der trotzdem viele andere Projekte abhängen, bleibt auf der langsamen Spur und wartet, bis bei Anthropic jemand Zeit für ihren Fund hat.
Zweitens liegt das Risiko vollständig beim Projekt. Laut Agreement sind die Maintainer dafür verantwortlich, jeden Bericht und jeden Patch zu prüfen, bevor sie etwas ändern. Die Berichte sind Anthropics vertrauliches Material und müssen geheim gehalten werden, bis die Lücke behoben ist. Anthropic haftet für nichts, was aus einem Bericht folgt, und insgesamt höchstens mit 1.000 Dollar. Freiwillige übernehmen damit die Qualitätssicherung für die Ausgabe eines Modells, mit deren Prüfung der Hersteller selbst nicht nachkommt.
Und ohne Frist weiß niemand, was liegen bleibt. Dass Anthropic auf ungeprüfte Funde keine 90 Tage setzt, ist nachvollziehbar, alles andere wäre unfair. Es heißt aber auch: Ein echter Fund, der in einem Stapel von Berichten untergeht, hat keinen Termin und keinen, der nachfragt. Er steht in einem Postfach und in Anthropics Datenbank, und die Nutzer der Software erfahren nichts davon.
Dahinter steht eine Rechnung, die wir schon im Artikel über Bugonomics aufgemacht haben. Das Finden kostet fast nichts mehr, das Prüfen und Beheben so viel wie vorher. Wer das Finden weiter beschleunigt und die Prüfung weglässt, hat das teure Ende der Kette nicht entlastet. Ein Filter vor dem Versand wäre die Stelle gewesen, an der Anthropic eigenes Geld und eigene Leute hätte einsetzen können. Angekündigt ist bisher nur, Triage und Patching künftig stärker zu automatisieren.
Was ihr als Maintainer prüfen solltet
Wenn euer Projekt infrage kommt und ihr die Kapazität habt, spricht wenig gegen einen Versuch. Ein paar Dinge lohnen sich vorher:
- Rechnet die Triage ein, bevor ihr den Pull Request stellt. Wer heute schon Sicherheitsmeldungen liegen lässt, bekommt durch den Scanner mehr davon, nicht weniger. Mit
disabled: truelässt sich der Zufluss wieder stoppen. - Schreibt die
threat_model.md. Sie ist optional, aber die einzige Stellschraube gegen die bekannten Schwächen: Hier legt ihr fest, was als Angreifer-Eingabe gilt, was außerhalb des Scopes liegt und wie ihr Schweregrade einstuft. Ohne die Datei rät der Scanner. - Nehmt eine Sammeladresse. Die E-Mail-Adressen in der
project.yamlsind öffentlich. Ein Security-Alias ist besser als ein persönliches Postfach, mit dem optionalen PGP-Schlüssel kommen die Berichte verschlüsselt. - Behandelt Patches als Vorschlag. Auch wenn ein PostgreSQL-Maintainer berichtet, einige seien fast unverändert nutzbar: Das Agreement schließt ausdrücklich nicht aus, dass ein Patch etwas kaputt macht.
- Führt selbst Buch. Weil es keine Frist gibt, erinnert euch niemand an offene Berichte. Jeder Fund braucht bei euch einen Eintrag mit Status, sonst verschwindet er.
Dass große Projekte dadurch schneller sicherer werden, glauben wir Anthropic. Der Scanner ist trotzdem kein Geschenk ohne Gegenleistung, bezahlt wird mit der Zeit der Maintainer.
Quellen5
- Anthropic: Launching an opt-in vulnerability-finding service for open-source software (08.10.2026)anthropic.com
- Anthropic Frontier Red Team: OSS Scanner, FAQ (abgerufen 10.10.2026)red.anthropic.com
- Anthropic: OSS Scanner Agreement (abgerufen 10.10.2026)red.anthropic.com
- GitHub: anthropics/oss-scanner (abgerufen 10.10.2026)github.com
- Anthropic: Cyber Mission (08.10.2026)anthropic.com