Dienst, der registrierte Open-Source-Repositories in isolierten Offline-VMs baut und sie auf Sicherheitslücken scannt, wobei Ergebnisse per E-Mail mit Reproduzierern und vorgeschlagenen Patches versendet werden.
OSS Scanner ist ein Dienst von Anthropic, der kritische Open-Source-Repositories auf Sicherheitslücken untersucht. Weitere Informationen zum Dienst finden Sie unter red.anthropic.com/oss-scanner.
Beachten Sie, dass die Nutzung dieses Tools den Bedingungen unterliegt, die in den OSS Scanner terms beschrieben sind.
Registrieren Sie ein Open-Source-Projekt, indem Sie einen Pull Request öffnen, der ein Verzeichnis hinzufügt:
projects/<name>
Unser Sicherheitsscanner baut Ihr Projekt in einer isolierten VM, analysiert es anschließend ohne Internetzugang und sendet die Ergebnisse per E-Mail an primary_contact (und etwaige CCs), jeweils mit einem Reproducer und, sofern verfügbar, einem vorgeschlagenen Patch. Berichte werden von einem Modell generiert und nicht von einem Menschen überprüft. Aus diesem Grund legen wir keine 90-tägige Offenlegungsfrist auf diese Ergebnisse und werden sie nicht veröffentlichen. Projektinhaber sollten project.yaml (zur Konfiguration des Scanners), ein Dockerfile (das angibt, wie das Projekt gebaut wird) und optional eine threat_model.md (mit projektspezifischer Bedrohungsmodellierung) bereitstellen.
Beginnen Sie mit templates/project.yaml:
repo: https://github.com/example/project # required: the git repository to scan; add #branch to pin one
primary_contact: [email protected] # required: reports and build problems go here (one address)
auto_ccs: # optional: more addresses on every mail
- [email protected]
homepage: https://example.org # optional
disabled: false # optional: true pauses reports without removing the enrolment
dockerfile: .oss-scanner/Dockerfile # required unless a Dockerfile sits in this repo next to your project.yaml
threat_model: .oss-scanner/threat_model.md # optional; also supports placing the file in this repository
repo und primary_contact sind immer erforderlich. dockerfile ist erforderlich, es sei denn, Sie legen Ihr Dockerfile neben project.yaml ab (siehe unten). Die übrigen sind optional.
Die E-Mail-Adressen in project.yaml sind öffentlich. Verwenden Sie Adressen, deren Veröffentlichung für Sie in Ordnung ist, etwa einen Security-Alias.
Um Berichte verschlüsselt zu erhalten, fügen Sie Ihren armorierten öffentlichen OpenPGP-Schlüssel hinzu. Berichte gehen dann nur an primary_contact; pgp kann nicht mit auto_ccs kombiniert werden:
pgp: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF...
-----END PGP PUBLIC KEY BLOCK-----
Sie müssen ein Dockerfile bereitstellen, und zwar an genau einer von zwei Stellen:
dockerfile: auf dessen Pfad (wir empfehlen eine Stelle wie .oss-scanner/Dockerfile). Dies ist die bevorzugte Option, da Sie damit den Build ohne einen Pull Request hier aktualisieren können; oderproject.yaml, als projects/<name>/Dockerfile, ohne dass der Schlüssel Dockerfile: in der project.yaml gesetzt ist. Wenn Sie lieber keine Dateien zu Ihrem Repository hinzufügen möchten, legen Sie es hier ab, und der Scanner baut es genau so, wie er es mit einer Kopie im Repository tun würde.(Das Bedrohungsmodell funktioniert auf dieselbe Weise. Setzen Sie das Feld threat_model auf dessen Speicherort in Ihrem Repository, oder legen Sie es hier unter projects/<name>/threat_model.md ab.)
Der Zweck des Dockerfile besteht darin, Ihre Umgebung einzurichten, alle Abhängigkeiten zu installieren und das Projekt zu bauen. Das anfängliche Projekt-Setup läuft mit aktiviertem Netzwerkzugang, aber das Sicherheitsaudit danach läuft ohne Internetzugang. Alles, was der Build oder die Tests benötigen, muss während des anfänglichen Dockerfile-Setups abgerufen werden. Wir empfehlen zu prüfen, dass Ihre Tests innerhalb des gebauten Images bestehen.
Die Datei threat_model.md (optional, aber dringend empfohlen) ermöglicht es Ihnen, dem Scanner Dokumentation zu Ihren beabsichtigten Sicherheitszielen bereitzustellen. Wir haben festgestellt, dass es am nützlichsten ist, eine Anleitung dazu zu geben, wie Sie die Schwere von Berichten einstufen (z. B.: Betrachten Sie Post-Auth-SQLi als hoch oder kritisch? Sind Buffer Overflows ohne nachgewiesene Exploits auf hoch begrenzt? Wann ist gespeichertes XSS mittel, hoch und kritisch?). Diese Datei kann auch angeben, was das Projekt tut, wo nicht vertrauenswürdige Eingaben eintreten, welche Komponenten wichtig sind und welche außerhalb des Geltungsbereichs liegen, wie Sie Berichte und Patches gestaltet haben möchten oder alles andere, was Sie für wichtig oder nützlich halten.
Wir empfehlen, vor dem Öffnen eines Pull Requests zwei Befehle auszuführen:
tools/validate.py prüft projects/<name>/ gegen die oben genannten Regeln.tools/check <name> baut Ihr Projekt so, wie unser Scanner es tun wird, und öffnet eine Shell im fertigen Image ohne Netzwerk. Wenn Ihre Tests in diesem Container bestehen, wird unser Scanner mit Ihrem Projekt wahrscheinlich funktionieren. tools/check --qemu <name> macht dasselbe innerhalb von virtuellen Maschinen, die wie die des Scanners eingerichtet sind.Diese Tools erfordern, dass auf Ihrem Host git, Docker und Python 3 mit PyYAML installiert sind (pip install pyyaml); --qemu erfordert Linux auf x86-64 mit QEMU statt Docker.
primary_contact.primary_contact und etwaige zusätzliche CCs gesendet, mit Reproduktionsschritten und, sofern verfügbar, einem vorgeschlagenen Patch.Sie können Ihr Projekt jederzeit mit einem PR bearbeiten. Um Ihr Projekt abzumelden, setzen Sie das Feld disabled auf true, um Berichte zu pausieren, oder entfernen Sie projects/\<name\>/, um das Projekt vollständig zurückzuziehen.
tools/check führt das Dockerfile Ihres Projekts mit Netzwerkzugang aus, so wie es docker build tun würde. Mit --qemu läuft der Build innerhalb einer virtuellen Maschine, was ihn von Ihren Dateien fernhält, aber er kann dennoch Dienste auf Ihrem Computer und in Ihrem lokalen Netzwerk erreichen. Prüfen Sie nur Projekte, denen Sie vertrauen, oder verwenden Sie einen Rechner, auf dem es nichts zu verlieren gibt.tools/check installiert Claude Code in das Image, das es baut (so wie es der Scanner tut). Claude Code unterliegt seinen eigenen Bedingungen.Bitte besuchen Sie red.anthropic.com/oss-scanner.
Wartungsstatus: Dieses Repository wird aktiv von Anthropic gepflegt. Wir prüfen und mergen nur Enrollment-Pull-Requests (Änderungen unter projects/<name>/); wir akzeptieren keine anderen Beiträge, einschließlich Änderungen an tools/ oder templates/. Siehe CONTRIBUTING.md für Informationen zur Anmeldung, SECURITY.md zum Melden einer Schwachstelle in diesem Repository und CODE_OF_CONDUCT.md.