So funktioniert es
Vom Repository-Link zu verifizierten Befunden
Die Pipeline folgt dem von Anthropic für den Anthropic OSS Scanner beschriebenen Ablauf – Bedrohungsmodell, Audit, Gegenprüfung, Ursachenanalyse, Patch – und basiert auf den leistungsfähigsten Claude-Modellen, die über eine öffentliche API verfügbar sind.
- 1
Sicherer Klon
Wir rufen den angeforderten Branch mit einem flachen, nach Blobs gefilterten git clone über HTTPS ab. Git-Hooks sind deaktiviert, Symlinks werden als gewöhnliche Dateien ausgecheckt und jeder Transport außer HTTPS wird verweigert. Private Netzwerkadressen sind gesperrt, sodass der Scanner nicht auf interne Hosts gerichtet werden kann.
Nichts aus dem Repository wird jemals ausgeführt: keine Builds, keine Paketinstallationen, keine Tests. Der ausgecheckte Quellcode wird nach Abschluss des Scans gelöscht.
- 2
Bestandsaufnahme und Risikobewertung
Jede Textquelldatei wird mit ihrer Sprache und Größe erfasst. Eingebundener Fremdcode, generierte Dateien, minimierte Bundles und Lockfiles werden übersprungen. Jede Datei erhält eine Risikobewertung anhand gefährlicher Senken – Speicherkopien, Shell-Ausführung, Deserialisierung, SQL-Erstellung, Template-Rendering, Pfadverknüpfungen, Kryptografie- und Authentifizierungscode – sowie anhand kritischer Codepfade wie Parsern, Protokollhandlern und Request-Routing.
- 3
Bedrohungsmodell
Wenn das Repository .oss-scanner/threat_model.md (dieselbe Datei, die der Scanner von Anthropic liest), eine SECURITY.md oder ein bei der Anmeldung von dir bereitgestelltes Bedrohungsmodell enthält, richtet sich der Scanner danach. Andernfalls liest ein Modell die README, die Verzeichnisstruktur und die riskantesten Dateien und erstellt einen Entwurf: worum es bei dem Projekt geht, wo nicht vertrauenswürdige Eingaben eintreffen und was nicht zum Umfang gehört.
Das Bedrohungsmodell wählt außerdem Dateien für den Fokus aus, damit das Audit sein Budget auf Code konzentriert, den ein Angreifer tatsächlich erreichen kann.
- 4
Auditieren
Die riskantesten Dateien werden mit Zeilennummern zu großen Paketen zusammengefasst und zusammen mit dem Bedrohungsmodell an ein Reasoning-Modell gesendet. Es sucht nach Problemen, die ein sorgfältiger menschlicher Auditor melden würde:
- Speichersicherheit: Pufferüberläufe, Use-after-free, Integer-Trunkierung
- Injection: SQL-, Befehls-, Template- und Path-Traversal-Angriffe, SSRF
- Authentifizierungs-, Autorisierungs- und Sitzungslogik
- unsichere Deserialisierung und Parser-Verwirrung
- Missbrauch von Kryptografie und Umgang mit Geheimnissen
Schnellscans verwenden Claude Haiku mit einem moderaten Budget. Tiefenscans für registrierte Projekte verwenden Claude Sonnet und lesen bis zu viermal mehr Code.
- 5
Unabhängige Verifizierung
Jeder potenzielle Befund wird mit frischem Kontext an einen separaten Verifizierungsagenten weitergegeben. Seine Aufgabe ist es, den Befund zu widerlegen: den Datenfluss nachzuverfolgen, nach Validierungen an anderer Stelle zu suchen und zu prüfen, ob die Eingabe gemäß dem Bedrohungsmodell tatsächlich vom Angreifer kontrolliert werden kann. Nur Befunde, die er bestätigt oder als wahrscheinlich einstuft, bleiben bestehen; die übrigen werden als verworfen gezählt.
Für bestätigte Befunde erstellt der Verifizierungsagent eine Ursachenanalyse, einen Reproducer und einen minimalen Patch-Kandidaten als Unified Diff.
- 6
Einführender Commit und Bericht
Duplikate mit gemeinsamer Ursache werden zusammengeführt. Mit git blame für die betroffenen Zeilen wird der jüngste Commit ermittelt, der sie geändert hat – normalerweise der Commit, der den Fehler eingeführt hat. So kannst du ein Fixes:-Tag hinzufügen und herausfinden, welche Releases betroffen sind.
Der Bericht wird unter einer zufälligen, nicht erratbaren ID gespeichert. Du kannst ihn als Markdown für ein Advisory, als JSON für Tools oder als SARIF 2.1.0 für GitHub-Code-Scanning exportieren.
Was der Scanner nicht tut
- Er führt deinen Code nicht aus, erstellt keinen Build davon und ruft keine Abhängigkeiten ab.
- Er veröffentlicht keine Befunde, erstellt keine Issues und kontaktiert niemanden außer angemeldeten Maintainern.
- Er behält nach dem Scan keine Kopie deines Quellcodes. Berichte enthalten kurze Ausschnitte der betroffenen Zeilen.
- Er gibt keinerlei Garantien: Modelle übersehen Fehler und melden manchmal fälschlicherweise welche. Ein unauffälliger Bericht ist keine Sicherheitszertifizierung.
Warum Reproducer gesperrt sind
Jeder kann einen Link zu einem öffentlichen Repository einfügen, auch Personen, die keine Maintainer sind. Ursachenanalyse und Patch helfen Verteidigern; ein funktionierender Proof of Concept hilft vor allem Angreifern. Deshalb bleiben Reproducer verborgen, bis jemand eine Token-Datei in das Repository eincheckt – als Nachweis, dass die Person einen Fix veröffentlichen kann. Das folgt der Leitlinie des Linux-Kernels, dass Reproducer für von KI gefundene Fehler auf Anfrage von Maintainern geteilt werden sollten.
Wie sich der Anthropic OSS Scanner von diesem Scanner unterscheidet
Anthropic betreibt seinen Scanner in Offline-Sandboxes, in denen das Projekt anhand einer Dockerfile erstellt wird. Dadurch können Agenten Code kompilieren und ausführen, um Fehler dynamisch zu bestätigen. Dabei kommen die leistungsstärksten Modelle zum Einsatz, darunter Claude Mythos, das nicht öffentlich verfügbar ist. Wir analysieren Code statisch mit öffentlich verfügbaren Claude-Modellen. Dafür kann jeder ossscanner.org innerhalb weniger Minuten und ohne Antrag oder Dockerfile nutzen.