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, um kritische Open-Source-Repositories auf Sicherheitslücken zu scannen. Erfahren Sie mehr über den Dienst 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 Internetzugriff und sendet die gefundenen Ergebnisse per E-Mail an primary_contact (und etwaige CCs), jeweils mit einem Reproducer und, sofern verfügbar, einem vorgeschlagenen Patch. Die Berichte werden von einem Modell generiert und nicht von einem Menschen überprüft. Aus diesem Grund legen wir für diese Befunde keine 90-tägige Offenlegungsfrist fest und werden sie nicht veröffentlichen. Projektverantwortliche sollten project.yaml (zur Konfiguration des Scanners), ein Dockerfile (das angibt, wie das Projekt gebaut wird) und optional eine threat_model.md (mit projektbezogener Threat-Modeling-Dokumentation) 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 Ihre 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 Sie zustimmen, etwa ein Security-Alias.
Um Berichte per E-Mail verschlüsselt zu erhalten, fügen Sie Ihren OpenPGP-Public-Key im ASCII-Armor-Format hinzu. Diese gehen dann ausschließlich an primary_contact; pgp kann nicht mit auto_ccs kombiniert werden:
pgp: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF...
-----END PGP PUBLIC KEY BLOCK-----
Um festzulegen, wohin Berichte gehen, legen Sie den niedrigsten Schweregrad fest, den jeder Kanal erhält: low, medium, high, critical oder none, um den Kanal zu deaktivieren. Ein Kanal, den Sie auslassen, verwendet den hier gezeigten Standardwert, und ein Bericht, der beide Mindestwerte erreicht oder überschreitet, geht an beide Kanäle. pgp gilt nur für E-Mail, daher werden GitHub-Berichte nicht mit Ihrem Schlüssel verschlüsselt:
output_format:
email:
min_severity: low
github_security_advisory: # GitHub private vulnerability reporting
min_severity: none
Sie müssen ein Dockerfile bereitstellen, und zwar an genau einer von zwei Stellen:
dockerfile: auf dessen Pfad (wir empfehlen einen Ort wie .oss-scanner/Dockerfile). Dies ist die bevorzugte Option, da Sie damit den Build aktualisieren können, ohne hier einen Pull Request zu stellen; oderproject.yaml, als projects/<name>/Dockerfile, ohne dass ein Dockerfile:-Schlüssel 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 Threat-Modell funktioniert auf dieselbe Weise. Setzen Sie das Feld threat_model für seinen 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, jede Abhängigkeit zu installieren und das Projekt zu bauen. Die anfängliche Projekteinrichtung läuft mit aktiviertem Netzwerkzugriff, aber das anschließende Sicherheitsaudit läuft ohne Internetzugang. Alles, was der Build oder die Tests benötigen, muss während der anfänglichen Dockerfile-Einrichtung 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, Hinweise dazu zu geben, wie Sie die Schwere von Berichten bewerten (z. B.: Betrachten Sie Post-Auth-SQLi als hoch oder kritisch? Sind Pufferüberläufe 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 wahrscheinlich mit Ihrem Projekt funktionieren. tools/check --qemu <name> tut 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 benötigt Linux auf x86-64 mit QEMU statt Docker.
primary_contact mit einer Fehlermeldung.primary_contact und alle zusätzlichen CCs gesendet, mit Reproduktionsschritten und einem vorgeschlagenen Patch, sofern verfügbar.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 Netzwerkzugriff 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.