Tech Teardown 024｜oss-scanner: Anthropics offizielles Schwachstellen-Scan-Repository, 5 Tage 960 Stars, darin jedoch keine einzige Zeile Scanner-Code

Am 8. Oktober hat die offizielle Accountseite von Anthropic, anthropics, auf GitHub einen neuen Repository namens oss-scanner erstellt. Innerhalb von fünf Tagen wurden mehr als 960 Sterne vergeben (10-14 Snapshots, 5 Tage seit der Erstellung des Repositories). Die Pull Request-Nummer ist bereits auf #598 gestellt. Seine Popularität kommt nicht aus den Diskussionen in der Community, sondern aus drei Faktoren: offizielle Veröffentlichungen, die aktive Registrierung von 76 wichtigen Open-Source-Projekten sowie die Aussagen der Entwickler von PostgreSQL, OpenSSL, wolfSSL, curl und HotCRP in ihren Veröffentlichungen. Noch interessanter ist das Repository selbst: Nach Durchsicht von 184 Dateien konnte keine einzige Zeile Code gefunden werden, der eine Ausführungslücke scannt. Dies ist ein Registry für Scanservice, wobei der Scanner auf den Servern von Anthropic gespeichert wird. Gestern wurde im Anatomy der Produktionsschicht der Agent-Ökologie untersucht; heute betrachtet dieses Repository die Sicherheitsschicht. Die beiden Abteilungen zeigen, wie AI-Unternehmen in die Open-Source-Infrastruktur eingreifen. Dieser Artikel wird wie gewohnt in sechs Abschnitte unterteilt.

1. Was ist es?

Zuerst muss man die Kernaussage klarstellen: Das Repository oss-scanner enthält nicht den Code des Scanners, sondern ein „Registry + Konfigurationsprotokoll + Selbstprüfungstool“. Der Scanner selbst läuft auf der Serviceseite und ist nicht open-source. Der open-source Teil löst eine andere Aufgabe: Wie kann ein Open-Source-Projekt sich diesem Scanner unterordnen und wie kann es vor der Bereitstellung selbst prüfen?

Der Service ist eine kostenlose Lückebeseitigung für wichtige Open-Source-Projekte von Anthropic, die auf Opt-in-Basis erfolgt. Nur projektbezogene Registrierungen werden gescannt. Die Nutzung ist durch die Nutzungsbedingungen auf red.anthropic.com/oss-scanner eingeschränkt. In den offiziellen Veröffentlichungen wird dies sehr direkt beschrieben: Die Inspiration stammt von Google’s OSS-Fuzz, wobei der Fuzzer durch das stärkste Sprachmodell (einschließlich Claude Mythos) ersetzt wurde. Seine Vorläufer waren das intern von Anthropic verwendete Project Glasswing zur Lückefindung mit Claude sowie ein CVD-Prozess, der bereits mehr als 6000 Berichte manuell überprüft hat. Die Aufgaben zwischen dem kostenpflichtigen Produkt Claude Security und OSS Scanner sind auch klar definiert: OSS Scanner bietet Open-Source-Projekten kostenlos einen Service an, während kommerzielle Kunden eine andere Route wählen.

Daher ist die Form dieses Repositories etwas Besonderes: AI-Unternehmen bauen Open-Source-Sicherheitsinfrastruktur auf – nicht Modelle oder Scanners, sondern ein Anschlusprotokoll. Dies unterscheidet sich deutlich von der traditionellen Sicherheitstool-Open-Source-Methode, bei der „Code ist das Produkt“. Die Offenlegung des Registers bedeutet, dass jeder, der gescannt wird, nachverfolgbar ist, während der geschlossene Scanner bedeutet, dass die Art der Scans in einem „Schattenbox“-Modus erfolgt – Transparenz wird also in zwei Teile geteilt.

2. Repository-Struktur

Das Repository enthält insgesamt 184 Dateien (ohne .git), davon 80 yaml-, 51 md- und 4 py-Dateien, unter Apache-2.0-Lizenz.

Das Hauptteil enthält 76 Projektordner unter projects/. Jeder Ordner ist ein Registrierungsdokument. Die Liste ist sehr gut: openssl, cpython, spidermonkey (der JS-Brenner von Firefox), nss (Mozilla-Kryptographiebibliothek), homebrew, drupal, grafana, rabbitmq, jupyterlab, nestjs, valkey (Redis-Sparte), uutils-coreutils, lvm2, cryptsetup; Sicherheitswerkzeuge umfassen nuclei, grype, syft, zmap, radare2, ossec-hids, go-tuf, tinyssh, botan; Auch einige AI-Projekte sind dabei, wie unsloth, autogpt, goose, sogar Anthropics’ eigenes claude-code-templates ist registriert. Beachten Sie, dass curl nicht auf der Liste steht, aber in den Veröffentlichungsartikeln gibt es einen Aussage von Curl-Entwickler Daniel Stenberg.

Das Herzstück jedes Dokuments ist project.yaml, mit zwei Pflichtfeldern: repo (Git-Repository-Adresse, kann mit #branch als Sicherheitsknoten verwendet werden) und primary_contact (E-Mail-Adresse für die Berichterstattung). Optionale Felder sind dockerfile, threat_model, auto_ccs, pgp, disabled, homepage. Das Beispiel für openssl ist repräsentativ: repo zeigt auf openssl/openssl und schließt master ab, primary_contact verwendet die Gruppendatenzeile openssl-security@ anstatt einer persönlichen Adresse – dies ist ein Beispiel für die Regel im README, dass „die E-Mail-Adresse öffentlich sein wird, bitte verwenden Sie den Alias security“.

Der Werkzeugcode ist in tools/ konzentriert, etwa 1287 Python-Codezeilen plus 142 shell-Zeilen: validate.py mit 261 Zeilen für die Konfigurationsprüfung, check_build.py und check_qemu.py für die lokale Build-Überprüfung. templates/ enthält Konfigurationsvorlagen. Die Haltung des Repositories gegenüber Beiträgen ist auch am Ende des README beschrieben: Nur registrierte PRs unter projects/ werden akzeptiert, Änderungen in tools und templates werden nicht berücksichtigt. 598 PRs innerhalb von fünf Tagen, fast alle sind in der Warteschlange.

III. Mechanismusanalyse

Der gesamte Prozess des Dienstes besteht aus vier Schritten: Builden, Netzwerkunterbrechen, Scannen und E-Mail senden. Die Projekte stellen eine Dockerfile bereit (entweder im eigenen Repository oder neben dem Registrierungsordner, wobei die erstere Variante bevorzugt wird, da Änderungen am Build ohne PRs möglich sind), der Scanner baut das Projekt in einer isolierten VM, während der Anfangsphase des Builds das Netzwerk aktiv ist. Nach dem Eintritt in die Sicherheitsüberprüfungsphase wird das Netzwerk vollständig unterbrochen, und die Ergebnisse werden an die primary_contact gesendet. Jeder Bericht enthält drei Elemente: ein selbstständiges reproducer, eine Fehlerbeschreibung (inklusive der Zeitpunkte, zu denen die Fehler mit bisection identifiziert wurden), sowie einen Kandidaten-Patch.

Der Bericht wird in zwei Kategorien unterteilt. Eine ist der CVD-Kanal, der manuell überprüft wird; die andere ist der „fast track“, bei dem der gesamte Modellinhalt ohne manuelle Überprüfung sofort veröffentlicht wird. Laut der Veröffentlichung wurden bereits fast 5000 ungeprüfte „fast track“-Berichte direkt an diejenigen weitergeleitet, die vollständige Berichte anforderten (angemessene Angabe von Anthropic). Das doppelte System verteilt die „Verifizierungskapazität“ als knappe Ressource: Wer eine manuelle Überprüfung wünscht, muss warten; wer Zeit hat, kann selbst seine Daten bereitstellen.

Auch bei der Netzwerkunterbrechung gibt es spezielle Aspekte. Die Freigabe des Netzwerks während der Erstellungsphase dient dazu, Abhängigkeiten zu aktivieren; die Unterbrechung des Netzwerks während der Überprüfungsphase verhindert, dass Modelle während der Analyse mit anderen Systemen verbunden werden: Damit wird vermieden, dass die gescannten Umgebungen Projektcode oder Details zu Sicherheitslücken preisgeben, und gleichzeitig verhindert, dass Modelle selbst Daten herunterladen, die die Analyse stören könnten. tools/check reproduziert diese Umgebung genau, was auch den Wert als Selbstüberprüfungstool ausmacht – das Verhalten, das man lokally beobachtet, entspricht dem der Service-Seite.

Die lokale Selbstüberprüfung vor der Registrierung ist der praktischste Teil des Repos. tools/validate.py wandelt die Registrierungsregeln in README in Code um: Feld-Whitelist, HTTPS-Überprüfung, E-Mail-Format, PGP-Publikationskey-Format, maximale Dateigröße – außerdem werden Felder wie workflow, budget und cadence blockiert, die nur vom Servicebetreiber eingestellt werden können. tools/check <name> konstruiert das Projekt nach dem gleichen Muster wie der Scanner und startet einen Shell in der fertigen Netzwerkunterbrechungs-Image. Wenn der Scanner in diesem Container funktioniert, ist es sehr wahrscheinlich auch für tools/check geeignet; die —qemu-Variante verwendet QEMU, um die VM-Lage des Scanners auf x86-64 Linux zu rekonstruieren. In der Dokumentation von validate.py steht auch eine ehrliche Aussage: Es teilt keine Code mit dem Service-Scanner, und Änderungen an den Regeln müssen beidseitig synchronisiert werden.

Vier, Zahlen und Verifizierung

Zuerst betrachten wir die wichtigsten Zahlen, die von Anthropic angegeben wurden. Alle folgenden Angaben basieren auf deren eigenen Angaben. In den letzten 6 Monaten wurden mit dem neuesten Modell die wichtigsten Softwareprojekte weltweit gescannt. Dabei wurden mehr als 29.000 potenzielle Sicherheitslücken gefunden, von denen nur etwa 6.000 manuell überprüft wurden. Anthropic gibt an, dass das Problem bei der Menge an Daten liegt, nicht beim Modell selbst. Auf dem akademischen Benchmark CyberGym ist die Erkennungsrate von LLM-Sicherheitslücken von Anfang letzten Jahres weniger als 20% auf dieses Jahr über 85%.

Die Verifizierungsexperimente sind die schwierigste Gruppe der Zahlen: Anthropic hat Penetrationstester beauftragt, die CVD-Prozesse zu kennen, um die 97 critical/high-Level-Sicherheitslücken in 48 Projekten zu überprüfen. Dabei waren 85 (88%) den CVD-Standards entsprechend; von den restlichen 12 waren 11 tatsächlich vorhanden, aber es handelte sich um wiederholte Berichte. Nur 1 (angemessene Angabe von Anthropic) war ein echter falscher positiver Bericht.

Auch die offiziellen Stärken werden nicht verheimlicht: Einige Benutzer berichten, dass die Schwerebewertungen möglicherweise übertrieben sein könnten, und der Scanner könnte die Bedrohungsmodelle des Projekts falsch interpretieren.

Berichte von Wartungsmitarbeitern aus dem von Anthropic veröffentlichten Artikel, wiedergegeben wie folgt. Noah Misch von PostgreSQL sagt, dass ein sehr hoher Anteil der entdeckten Schwachstellen echte Fehler sind, und dass die Verbesserungen in vielen Berichten direkt angewendet werden können. Anton Arapov von OpenSSL Corporation vergleicht, dass die AI-Schwachstellenberichte vor 18 Monaten katastrophal waren, und dass diese hier nicht schlechter, sondern sogar besser sind als menschliche Berichte. Berichte mit echten Exploits erleichtern den Ingenieren ihre Arbeit. Todd Ouska von wolfSSL berichtet, dass von 74 Berichten nur 2 ungültig waren und 5 zu CVEs wurden. Daniel Stenberg von curl erwähnt, dass einer der schwersten curl-Schwachstellen in den letzten Jahren durch solche Scans entdeckt wurde. Eddie Kohler von HotCRP ist ebenfalls auf der Liste der Unterstützer. Diese Berichte stammen alle aus dem von Anthropic veröffentlichten Artikel und sind einseitige Zitate; bei ihrer Verwendung muss eine Abzugskraft angewandt werden.

Fünftes Kapitel: Bewertung

Es gibt drei Punkte, auf die man achten sollte.

Erstens: Doppelte Abweichungen von der Offenlegungspolitik. Im README heißt es: Die Berichte werden vom Modell generiert und wurden nicht manuell überprüft, daher gibt es kein 90-tägiges Offenlegungsfristen und keine öffentliche Veröffentlichung. Beide Grundlagen der traditionellen Schwachstellenoffenlegung sind hier aufgehoben. Es gibt technische Gründe dafür: Da die Berichte nicht überprüft wurden, eine 90-tägige Frist anzuwenden bedeutet, dass die Wartungsmitarbeiter auch bei falschen Positiven eine Countdown-Zeit eingehalten müssen; keine öffentliche Veröffentlichung verhindert, dass unverifzierte Informationen in die Hände von Angreifern gelangen. Der Preis dafür ist jedoch, dass die Außenwelt niemals überprüfen kann, was das System meldet und was es übersieht. Nur Anthropic selbst kann die 88% der Erfüllungsquoten berechnen.

Zweitens: Die Kosten für die Triage werden auf die Wartungsmitarbeiter übertragen. Die kostenlose Nutzung ist real, aber im README wird deutlich gemacht, dass die Berichte nicht manuell überprüft wurden und der Service an Projekte gerichtet ist, die in der Lage sind, verifizierte Hochrisikoberichte zu bearbeiten. Für Konzerne wie OpenSSL und PostgreSQL mit eigenen Sicherheitsteams ist dies ein Nettoergebnis; für Projekte mit knapper Personalstärke könnte die direkte Veröffentlichung von fast 5000 unverifizierten Berichten eine Belastung sein. Alle 76 registrierten Projekte sind schwere Projekte, und diese Liste ist ein Beweis für den Servicezweck. Dies ist keine Anklage, sondern eine Grenze des Services: Es werden nur Projekte mit Sicherheitsreaktionsfähigkeit ausgewählt, was genau diejenigen ausschließt, die am dringendsten externe Sicherheitsunterstützung benötigen.

Drittens: Doppelte Implementierung von Konfigurationsprüfungen. validate.py teilt sich den Code nicht mit dem Service-Scanner und die Regeln müssen manuell abgeglichen werden. Dies ist ein klares technisches Problem in der Ingenieurarbeit; je größer das Projekt, desto eher kann es zu Problemen kommen, bei denen die „lokale Prüfung erfolgreich war, aber die Importierung auf der Service-Seite fehlgeschlagen ist“. Bei 76 Projekten und 598 PRs bedeutet jede Änderung dieser Regel, dass zwei Stellen des Codes manuell abgeglichen werden müssen.

Im Großen Ganzen repräsentiert dieser Repository eine neue Form: AI-Unternehmen machen Sicherheitsfähigkeiten zu einem Service, während Open-Source nur das Anschlussprotokoll und die Registrierung sind. Das Protokoll ist offen, die Fähigkeiten jedoch geschlossen. Im Vergleich zum vorherigen Modell von OSS-Fuzz, bei dem „die Infrastruktur vollständig open-source war“, geht die Transparenz vor der Iterationsgeschwindigkeit. Für die Wartungsmitarbeiter ist es wettwertig, ob dieser Austausch lohnenswert ist, abhängig davon, ob man dem selbstgemachten Wert von 88% der Erfüllungsquoten glaubt und wie viel Kapazität noch in der Sicherheitsreihe vorhanden ist.

Sechstes Kapitel: Wer kann wie verwendet

Die Qualifikationsanforderungen sind nicht niedrig: Es ist notwendig, die Identität des Kernbetreuers zu überprüfen, sowie eine Qualifikationsprüfung nach dem Prinzip von OSS-Fuzz durchzuführen, um zu überprüfen, ob das Projekt unglaubwürdige Eingaben verarbeitet und ob die Anzahl der Nutzer im Unterfallbereich ausreichend ist. Der Prozess selbst ist einfach: Erstellen Sie einen PR, fügen Sie eine projects/<name>/-Direktorenbeneigung hinzu, legen Sie project.yaml und Dockerfile (oder den Pfad zu Ihrem eigenen Repository) hinein, und nach der Kombination übernimmt der Scanner die Automatische Importierung.

Zwei praktische Tipps. Erstens: Obwohl threat_model.md optional ist, wird dringend empfohlen, ihn zu erstellen. Die richtige Anwendung in dem README sollte klare Angaben zur Schwere hinsichtlich SQL-Injection machen: Ist die nach der Authentifizierung erfolgte SQL-Injection als high oder critical einzustufen? Sollte ein Buffer Overflow ohne Demonstration eines Exploits nicht als high eingestuft werden? Unter welchen Bedingungen sollte eine storage-basierte XSS-Exploitation aktualisiert werden? Diese Fragen decken genau die offiziell als „Übermäßige Schwere“ bezeichneten Schwächen ab. Zweitens: Führen Sie vor der Registrierung tools/validate.py und tools/check aus. Beachten Sie, dass der check das Dockerfile des Projekts über das Internet ausführt. Warnen Sie im README, dass die Überprüfung nur auf Projekte beschränkt ist, denen Sie vertrauen, oder verwenden Sie ein Gerät, bei dem es keinen Verlust gibt. Um Berichte vor der Weitergabe vorzubereiten, können Sie PGP-verschlüsselung verwenden, aber nach dem Verschlüsseln sollten nur die primary_contact-Informationen weitergegeben werden, nicht zusammen mit auto_ccs. Wenn Sie das Projekt nicht löschen, sondern nur pausieren möchten, setzen Sie disabled auf true.

Für normale Entwickler ist dieses Repository eher ein Lehrbuch: 76 Beispiele für project.yaml sind die besten Praktiken zur Konfiguration der Sicherheitskontakte, und die 261 Zeilen von validate.py sind ein sauberes Beispiel dafür, „die Dokumentationsregeln in Validatoren umzusetzen“.

Quellen

• Repository und Dokumentation: README auf github.com/anthropics/oss-scanner, tools/validate.py, Auflistung der projects-Direktorenbeneigungen sowie Beispielkonfigurationen für openssl (10-14 lokale Snapshots, Anzahl der Dateien und Codezeilen berechnet mit find+wc)
• Anzahl der Sterne, PR-Nummern, Anzahl der Projekte: GitHub-Seite und API, 10-14 Snapshots (Repository erstellt am 2026-10-08)
• Kernelemente (29.000/6.000/etwa 5.000/88%/97 von 1 falsch positive/CyberGym-Entdeckungsrate): Veröffentlichung von anthropic.com „Launching an opt-in vulnerability-finding service for open-source software“ (2026-10-08), alle Angaben stammen von Anthropic selbst, der Text ist dort jeweils markiert
• Aussagen der Betreuer (PostgreSQL/OpenSSL/wolfSSL/curl/HotCRP): Aussagen der Betreuer aus den Veröffentlichungen von Anthropic, der Text wird nachgebildet
• Offenlegungsrichtlinien, Registrierungsregeln, Verwendung von Selbstüberprüfungstools: Originaltext des README