Anthropic OSS Scanner erklärt
Kostenlose Sicherheitsprüfungen für Open-Source-Teams, die Befunde bearbeiten können.
Anthropic OSS Scanner ist ein kostenloser Dienst zur Schwachstellensuche für geeignete Open-Source-Projekte, die sich ausdrücklich anmelden. Er wurde am 8. Oktober 2026 angekündigt, untersucht aufgenommene Repositories regelmäßig mit Anthropics leistungsfähigsten Modellen und verschickt Befunde per E-Mail. Entscheidend ist: Anthropic lässt die Berichte vor dem Versand nicht von Menschen prüfen. Das Projekt muss sie selbst validieren und priorisieren.
Wenn Sie eine wichtige Bibliothek oder Anwendung betreuen und Kapazität für die Untersuchung haben, beginnen Sie mit den offiziellen FAQ. Die Anmeldung erfolgt per Pull Request im Anthropic-Repository. Ein Tool-Download oder ein gekaufter API-Schlüssel meldet kein Projekt an.
Quellen geprüft am 9. Oktober 2026. Dieser Leitfaden beruht auf Anthropics Ankündigung, FAQ und Anmeldecode. Wir haben weder ein Projekt angemeldet noch den Scanner ausgeführt. Leistungszahlen stammen vom Anbieter. Die verlinkten Primärquellen sind englischsprachig.
Welche Projekte kommen infrage?
Anthropic prüft etablierte Projekte mit wesentlichem Einfluss auf Infrastruktur und Nutzersicherheit nach ähnlichen Kriterien wie OSS-Fuzz. Dazu zählen mögliche Fernangriffe, etwa durch die Verarbeitung nicht vertrauenswürdiger Eingaben, sowie die Zahl der Nutzer und abhängigen Projekte. Die Aufnahme erfolgt im Einzelfall; eine automatische Zulassung ab einer bestimmten Sternezahl nennen die FAQ nicht.
Den Antrag muss ein verantwortlicher Maintainer aus dem Kernteam stellen. Anthropic überprüft diese Rolle. Erklären Sie kurz die Bedeutung des Projekts und benennen Sie eine Person für das Sicherheitspostfach. Der Dienst richtet sich ausdrücklich an Teams, die bestätigte Befunde mit hoher oder kritischer Schwere bereits bewältigen können. Kostenlose Scans ersetzen nicht die Arbeitszeit für Bewertung, Korrekturen und Releases.
Abgrenzung zu Claude Security und Claude Code
Die OSS-Scanner-FAQ und das Repository von Claude Code Security Reviewer beschreiben unterschiedliche Zugangswege:
| Werkzeug oder Verfahren | Zweck | Zugang und Ergebnis |
|---|---|---|
| OSS Scanner | Regelmäßige Audits aufgenommener Open-Source-Projekte | Kostenlos nach Anmeldung; modellgenerierte E-Mail-Berichte |
| Claude Security | Kommerzielle Quellcodeprüfung und Behebung von Schwachstellen | Eigenständiges Unternehmensprodukt mit separatem Zugang |
| Claude Code Security Reviewer | Prüfung von Codeänderungen im Entwicklungsprozess | Separate GitHub Action und /security-review-Ablauf |
| Anthropics reguläres CVD-Verfahren | Koordinierte Offenlegung bestätigter Befunde | Menschlich geprüfte Berichte nach der Offenlegungsrichtlinie |
Laut technischem Einführungsbeitrag kommen Anthropics stärkste Modelle einschließlich Claude Mythos zum Einsatz. Das beschreibt die interne Verarbeitung, gewährt aber weder einen Modell-Download noch allgemeinen Mythos-API-Zugang. Das öffentliche Repository enthält Anmeldekonfiguration und Vorbereitungshilfen; eine dokumentierte lokale Nachbildung des vollständigen gehosteten Scanners bietet es nicht.
So melden Sie ein Projekt an
1. Build und Sicherheitskontakt vorbereiten
Lesen Sie die Repository-Anleitung und die Hinweise zur Teilnahme. Erstellen Sie ein Dockerfile, das Abhängigkeiten installiert und das Projekt baut. Der Build hat Netzwerkzugang, das anschließende Sicherheitsaudit nicht. Laden Sie Testvoraussetzungen während der Vorbereitung herunter und prüfen Sie, ob die Tests danach offline funktionieren.
Die E-Mail-Adressen in der Anmeldung sind öffentlich. Verwenden Sie einen veröffentlichbaren Sicherheitskontakt. Mit einem öffentlichen Schlüssel unter pgp können Berichte verschlüsselt werden; dann gehen sie nur an primary_contact, und auto_ccs darf nicht gleichzeitig gesetzt sein.
2. Anmeldekonfiguration hinzufügen
Legen Sie in Ihrem Fork des Anthropic-Repositories anhand der offiziellen Vorlage die Datei projects/my-project/project.yaml an. Dieses Minimalbeispiel setzt voraus, dass Build-Datei und Bedrohungsmodell in Ihrem eigenen Projekt liegen. Ersetzen Sie Beispiel-Repository und Kontakt und erstellen Sie die referenzierten Dateien:
repo: https://github.com/example/project#main
primary_contact: security@example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
Verwenden Sie den kleingeschriebenen Schlüssel dockerfile aus Vorlage und Validator. Alternativ legen Sie eine Datei namens Dockerfile neben die Anmeldekonfiguration und lassen das Feld dockerfile weg. Wählen Sie genau einen Ablageort. Das untersuchte Git-Repository muss nicht auf GitHub liegen.
Die optionale Datei threat_model beschreibt nicht vertrauenswürdige Eingaben, Sicherheitsgrenzen, ausgeschlossene Verhaltensweisen, Schweregrade und Anforderungen an Reproduktionsbeispiele oder Patches. Sie erleichtert die Einordnung des beabsichtigten Verhaltens. Dass jeder Befund das Bedrohungsmodell richtig berücksichtigt, ist dadurch nicht garantiert.
3. Konfiguration und Offline-Umgebung prüfen
Im Wurzelverzeichnis Ihres lokalen Checkouts des Anmelde-Repositories sind folgende Vorbereitungsschritte dokumentiert:
python3 tools/validate.py
tools/check my-project
Der erste Befehl prüft die Anmeldekonfigurationen. Der zweite baut das Projekt und öffnet eine Shell ohne Netzwerk, in der Sie Tests starten können. Vorausgesetzt werden Git, Docker und Python 3 mit PyYAML. Führen Sie nur vertrauenswürdige Projektdefinitionen aus, da der Build Netzwerkzugang hat. Wir haben die Befehle mit der Dokumentation abgeglichen, aber keinen Scanner-Test damit durchgeführt.
4. Pull Request einreichen
Reichen Sie pro PR ein Projekt ein, füllen Sie die Checkliste aus und befolgen Sie das Verfahren zu Nutzungsbedingungen und Mitwirkungsvereinbarung. Anthropic bestätigt die Maintainer-Rolle vor der Aufnahme. Schlägt der Build des aufgenommenen Projekts auf der eigenen Infrastruktur fehl, wird der Hauptkontakt benachrichtigt.
Nach dem ersten Scan suchen weitere Durchläufe nach neu eingeführten und zuvor übersehenen Schwachstellen. Ein fester täglicher oder wöchentlicher Rhythmus ist nicht zugesagt. Laut FAQ hängen die Abstände unter anderem von Auslastung und Verbreitung des Projekts ab.
Berichte und Leistungszahlen richtig einordnen
Die E-Mail-Berichte enthalten ein Reproduktionsbeispiel, eine Erklärung und, sofern verfügbar, einen Patch-Vorschlag. Eine Bisektion kann die Einführung des Fehlers eingrenzen. Agenten prüfen Befunde erneut; das ist keine menschliche Validierung. Schweregrade können überhöht sein, Befunde bekannte Probleme wiederholen oder das Bedrohungsmodell falsch verstehen.
Für die frühe Auswertung wurden 97 Befunde mit hoher oder kritischer Schwere aus 48 Projekten ausgewählt: 85 erfüllten die CVD-Kriterien, 11 waren echte, aber doppelte Befunde und einer war ungültig. Diese ausgewählte frühe Stichprobe ist kein unabhängiger Genauigkeitstest über alle Schweregrade. Sie misst auch nicht, wie viele Schwachstellen unentdeckt bleiben.
Die im Cyber-Mission-Beitrag genannte Quote echter positiver Befunde von „über 90 %“ ist eine Erwartung, keine Zusicherung. Erfassen Sie bestätigte Probleme, Duplikate, falsche Schweregrade und ungültige Berichte getrennt.
Ein praktikabler Ablauf für Maintainer
Die folgenden Schritte sind unsere Empfehlung, kein Leistungsversprechen von Anthropic:
- Zuweisen und dokumentieren. Bestimmen Sie im zugriffsbeschränkten Sicherheitspostfach einen Verantwortlichen und erfassen Sie Berichts-ID, betroffene Revision und Ausgangsstatus.
- Reproduzieren und abgleichen. Prüfen Sie das Beispiel in einer isolierten Testumgebung und vergleichen Sie es mit vorhandenen Hinweisen oder privaten Meldungen. Ein Duplikat kann eine echte Schwachstelle beschreiben, ohne einen zweiten Fix zu erfordern.
- Auswirkung bewerten. Prüfen Sie die Kontrolle des Angreifers über Eingaben, die Erreichbarkeit in unterstützten Konfigurationen und notwendige Rechte. Wenden Sie Ihre eigenen Schweregradkriterien an.
- Patch prüfen und veröffentlichen. Kontrollieren Sie die Änderung, ergänzen Sie einen Regressionstest und prüfen Sie die Kompatibilität. Stimmen Sie Korrektur und Sicherheitshinweis ab, bevor sensible Details öffentlich werden.
Benötigt ein als „kritisch“ eingestufter Angriff beispielsweise Administratorrechte, dokumentieren Sie diese Voraussetzung und bewerten Sie die Auswirkung neu. Ein falscher Schweregrad allein macht den gesamten Bericht nicht wertlos. Wiederkehrende Missverständnisse gehören ins Bedrohungsmodell und in Ihre Rückmeldung an Anthropic.
Offenlegung, Pause und häufige Fragen
Beginnt mit jedem Bericht eine Frist von 90 Tagen?
Nein. Die FAQ sieht für unbestätigte Befunde keine automatische 90-Tage-Frist vor. Validiert Anthropic einen Befund später manuell, kann er nach der CVD-Richtlinie offengelegt werden; die Frist beginnt mit der Mitteilung über die menschliche Bestätigung. Dauerhafte Geheimhaltung wird damit nicht zugesagt.
Kann ein Projekt pausieren oder aussteigen?
Ja. Ein PR mit disabled: true pausiert Berichte; das Entfernen des Anmeldeverzeichnisses beendet die Teilnahme. Reguläre, menschlich geprüfte CVD-Berichte können weiterhin eintreffen. Bei zukünftigen Änderungen der Offenlegungsregeln sehen die FAQ eine Vorankündigung und Ausstiegsmöglichkeit vor.
Ist der Dienst kostenlos und ersetzt er andere Prüfungen?
Anthropic übernimmt die Scan-Kosten für aufgenommene Projekte. Wir empfehlen weiterhin Abhängigkeitsprüfungen, Tests und menschliche Sicherheitsreviews. Die veröffentlichten Ergebnisse belegen keine vollständige Abdeckung aller Schwachstellen. Entscheidend ist, ob Ihr Team zusätzliche Befunde ohne Überlastung in überprüfte Korrekturen umsetzen kann.
Welche Rolle OmniaKey spielt
Für separate Entwicklungs- und Reparaturarbeiten erklären unser Leitfaden zur Claude-Code-Einrichtung und der Modellkatalog die aktuellen Gateway-Optionen. OSS Scanner wird direkt bei Anthropic beantragt; ein OmniaKey-Konto schaltet weder diesen Dienst noch dessen interne Modelle frei.