AI-translated from English; not yet reviewed by a fluent editor.

# Wie Open-Source-Maintainer Anthropic OSS Scanner nutzen und dessen Berichte prüfen können

> Ein dokumentationsbasierter Leitfaden zu den Voraussetzungen für Anthropic OSS Scanner, zur Anmeldung, zum Offline-Build und zur sicheren Validierung von modellgenerierten Berichten, die noch nicht von Menschen geprüft wurden.

By BIG CHANGE Editorial

Published: 2026-10-09T17:01:09.330Z
Updated: 2026-10-09T17:01:09.330Z
Canonical: https://bigchange.ai/blog/anthropic-oss-scanner-maintainer-enrollment-triage-guide

![A seated maintainer studies a blank report sheet beside a dark, unbranded monitor.](https://bigchange.ai/api/media/file/anthropic-oss-scanner-maintainer-triage-hero-v1.png)
Conceptual illustration of a maintainer reviewing an unverified scanner report; it does not depict a real report, finding or test. AI-generated illustration by BIG CHANGE.

Anthropic OSS Scanner ist ein kostenloser Opt-in-Dienst, der angenommene Open-Source-Projekte regelmäßig mit den leistungsstärksten Modellen des Unternehmens scannt. Anthropic beschreibt ihn als Schnellweg zu Berichten unmittelbar nach einem Scan und als Ergänzung zum von Menschen geprüften koordinierten Offenlegungsverfahren. Modelle erstellen die Berichte; sie werden ohne menschliche Prüfung versendet. Die Anmeldung ist daher eine Kapazitätsentscheidung: Das Projekt braucht Maintainer, die Sicherheitsbefunde unabhängig validieren und entscheiden können, was behoben werden soll.

Dieser Leitfaden richtet sich an Kern-Maintainer sicherheitskritischer Open-Source-Projekte. Er erläutert den dokumentierten Anmeldeweg und den sorgfältigen Umgang mit einem Bericht. Grundlage ist die am 9. Oktober 2026 geprüfte Dokumentation von Anthropic. BIG CHANGE hat kein Projekt angemeldet, den Scanner nicht ausgeführt und keine Schwachstelle reproduziert.

## Prüfen Sie zuerst, ob Ihr Projekt die Berichte bearbeiten kann

Anthropic zufolge berücksichtigt das Unternehmen etablierte Projekte mit kritischer Bedeutung für Infrastruktur oder Nutzersicherheit. Als Indikatoren nennt es unter anderem die Exposition gegenüber Remote-Angriffen und die Zahl der Nutzer oder anderen Projekte, die von der Software abhängen. Anträge werden einzeln geprüft; Anthropic kontrolliert manuell, ob die antragstellende Person Kern-Maintainer ist. Der Dienst ist laut Anthropic für Projekte gedacht, die bereits verifizierte Berichte hoher und kritischer Schweregrade bearbeiten können.

Beantworten Sie vor dem Öffnen eines Pull Requests die folgenden Fragen anhand eigener Belege aus Ihrem Projekt:

1. Sind Sie Kern-Maintainer und können Sie den Antrag stellen sowie vertrauliche Sicherheitsberichte empfangen?
2. Erfüllt das Projekt das Kriterium der kritischen Auswirkungen? Können Sie seine Rolle für Infrastruktur oder Nutzersicherheit, die Exposition gegenüber Remote-Eingaben oder die nachgelagerte Nutzung belegen?
3. Haben Sie Personal und Abläufe, um zusätzliche ungeprüfte Berichte zu bewerten, Befunde sicher zu reproduzieren, bei Bedarf die Offenlegung zu koordinieren und Korrekturen zu pflegen?
4. Können Sie eine reproduzierbare Build-Umgebung mit den Abhängigkeiten und Tests für ein Offline-Audit bereitstellen?
5. Ist die angegebene Kontaktadresse für sensible Berichte geeignet? Die Projektkonfiguration ist öffentlich. Verwenden Sie daher ein Sicherheitsalias oder eine andere Adresse, die Sie veröffentlichen können.

Wenn Ihr Team Berichte nicht zeitnah prüfen kann, bleibt laut Anthropic das bestehende koordinierte Verfahren zur Offenlegung von Schwachstellen bestehen und liefert Projekten, die diesen Weg benötigen, von Menschen verifizierte Berichte. OSS Scanner ist ein zusätzlicher Schnellweg, kein Ersatz für Ihren Sicherheitsprozess.

## Bereiten Sie den Anmeldeantrag vor

Sie benötigen Ihr Repository und Ihre Maintainer-Berechtigung, eine Konfigurationsdatei und ein Build-Rezept. Die Anmeldung erfolgt per Pull Request an Anthropic’s [`oss-scanner` Repository](https://github.com/anthropics/oss-scanner), der `projects/<project>/project.yaml` hinzufügt. Beginnen Sie mit Anthropic’s [Projektvorlage](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) und lesen Sie vor dem Einreichen die aktuelle [OSS-Scanner-FAQ](https://red.anthropic.com/oss-scanner/); die Repository-Anweisungen können sich ändern.

Die dokumentierten Pflichtfelder der Konfiguration sind:

| Feld | Angabe |
| --- | --- |
| `repo` | Eine HTTPS-URL eines Git-Repositories zum Klonen. Anthropic’s Vorlage erlaubt die Suffixe `#branch` oder `#tag` zum Festlegen einer Revision. |
| `primary_contact` | Eine E-Mail-Adresse für Berichte und Fragen. Sie ist in der Konfiguration öffentlich. |
| Pfad zur Dockerfile | Ein relativ zum Repository angegebener Dockerfile-Pfad in `project.yaml` oder eine Datei namens `Dockerfile` neben `project.yaml` im Anmelde-Repository. Geben Sie genau eine dieser Optionen an. |

Optionale Felder sind unter anderem `auto_ccs`, `homepage`, `threat_model`, `pgp`, und `disabled`. Anthropic zufolge verschlüsselt ein öffentlicher PGP-Schlüssel per E-Mail versendete Berichte und lässt sich nicht mit `auto_ccs` kombinieren; bei aktiviertem PGP gehen Berichte nur an `primary_contact`. Behandeln Sie alle konfigurierten E-Mail-Adressen als öffentlich. `disabled: true` pausiert Berichte, ohne die Anmeldung aufzuheben; das Entfernen des Projektverzeichnisses zieht sie zurück.

### Machen Sie den Build für ein Offline-Audit geeignet

Die Dockerfile sollte die Umgebung einrichten, Abhängigkeiten installieren und das Projekt bauen. Anthropic zufolge läuft der erste Build mit Netzwerkzugriff, das Audit jedoch ohne Internet. Abhängigkeiten oder Testressourcen, die das Audit benötigt, müssen deshalb bereits bei der anfänglichen Einrichtung durch die Dockerfile abgerufen werden.

Anthropic empfiehlt, die Dockerfile im eigenen Repository abzulegen. So lässt sie sich aktualisieren, ohne das Anmelde-Repository erneut ändern zu müssen. Ein Bedrohungsmodell ist optional, wird aber dringend empfohlen. Erläutern Sie darin, welcher Code und welche Eingaben wichtig sind, was außerhalb des Umfangs liegt, wie Ihr Projekt Schweregrade einstuft, wie Befunde dedupliziert werden sollen und wie ein nützlicher Proof of Concept oder Patch-Vorschlag aussieht. Das sind Hinweise für den Scanner, kein Beleg für die Richtigkeit eines Berichts.

Vor dem Einreichen empfiehlt Anthropic zwei Prüfungen:

1. Führen Sie `tools/validate.py` aus, um die Projektkonfiguration zu prüfen.
2. Bauen und testen Sie die Dockerfile lokal. Das `tools/check <name>` des Repositorys erstellt das Image wie der Scanner und öffnet eine Shell im fertigen Image, in der das Netzwerk deaktiviert ist. Anthropic dokumentiert außerdem `tools/check --qemu <name>` für die QEMU-basierte Einrichtung.

Diese Prüfungen sind optionale Empfehlungen in den Anmeldeanweisungen. Sie belegen weder, dass Anthropic das Projekt annimmt, noch dass ein späterer Befund gültig ist. Laut Repository führt `tools/check` die Projekt-Dockerfile während des Builds mit Netzwerkzugriff aus. Der Sicherheitshinweis warnt, dass der Build Dienste auf Ihrem Computer und in Ihrem lokalen Netzwerk erreichen kann. Nutzen Sie für einen vertrauenswürdigen Docker-Build einen geeigneten Rechner oder eine isolierte Umgebung. Für die standardmäßige lokale Prüfung sind Git, Docker, Python 3 und PyYAML erforderlich. Die Variante `--qemu` verwendet statt Docker x86-64 Linux und QEMU sowie Git, Python 3 und PyYAML.

## Reichen Sie den Antrag ein und warten Sie auf die Projektentscheidung

Öffnen Sie einen Pull Request mit der Projektkonfiguration und der erforderlichen Dockerfile oder dem optionalen Bedrohungsmodell. Wenn die kritische Sicherheitsbedeutung nicht offensichtlich ist, erläutern Sie sie kurz. Anthropic prüft den Kern-Maintainer-Status manuell und kann das Projekt bei Unsicherheit auf anderem Weg kontaktieren.

Anthropics öffentliche Anmeldeunterlagen beschreiben Einzelfallentscheidungen; sie garantieren weder eine Annahme noch eine Antwortfrist. Ein eingereichter Pull Request bedeutet keine Annahme. Bei Annahme scannt Anthropic nach eigenen Angaben zuerst das Projekt und sendet anschließend ein Paket mit Berichten per E-Mail an `primary_contact` und alle konfigurierten CC-Empfänger. Weitere regelmäßige Scans sind geplant; ihre Häufigkeit kann jedoch vom Projektprozess bei Anthropic und der Verbreitung des Projekts abhängen.

Der Dienst selbst ist kostenlos. Das Projekt muss weiterhin Maintainer-Zeit für Angaben zur Eignung, Aufbau und Pflege des Containers, Triage und Reproduktion von Berichten, koordinierte Offenlegung und Behebung bereitstellen.

## Behandeln Sie jeden Bericht als Hinweis, nicht als Urteil

Anthropic zufolge können Berichte einen eigenständigen Reproducer, eine Erklärung, nach Möglichkeit eine Bisektion zur Bestimmung des Zeitpunkts der Fehlerentstehung und gegebenenfalls einen Patch-Vorschlag enthalten. Modelle erzeugen die Berichte ohne menschliche Prüfung oder Triage. Die Startunterlagen warnen vor möglichen Fehlern; Anthropic weist besonders darauf hin, dass Schweregrade übertrieben sein können oder der Scanner das Bedrohungsmodell eines Projekts missverstehen kann. Ein vorgeschlagener Fix ist kein freigegebener Fix.

Nutzen Sie Ihren üblichen Sicherheitsprozess und ordnen Sie jeden Befund nur dem Belegniveau zu, das der Bericht tatsächlich hergibt:

1. **Bewahren Sie den Bericht auf und begrenzen Sie seinen Umfang.**Bewahren Sie die Original-E-Mail und die Berichtskennung im eingeschränkten Sicherheitsablauf des Projekts auf. Prüfen Sie, ob betroffenes Repository, Branch, Commit, Komponente und behauptetes Bedrohungsmodell zum Projekt passen. Beschränken Sie den Zugriff auf Personen, die ihn benötigen.
2. **Lesen Sie die Behauptung, bevor Sie etwas ausführen.**Ermitteln Sie den behaupteten Fehler, den betroffenen Codepfad, die vom Angreifer kontrollierte Eingabe, erforderliche Berechtigungen oder Bedingungen und die behaupteten Auswirkungen. Vergleichen Sie diese Angaben mit Ihrer Architektur und Ihrem Bedrohungsmodell. Wenn der Bericht keine brauchbaren Reproduktionsdetails enthält, bitten Sie Anthropic um Klarstellung, statt fehlende Schritte zu erfinden.
3. **Reproduzieren Sie das Problem in einer isolierten Umgebung unter Ihrer Kontrolle.**Nutzen Sie einen entbehrlichen Checkout oder eine VM, eine bekannte Revision und den dokumentierten Reproducer. Führen Sie keinen vom Modell vorgeschlagenen Patch oder Proof of Concept in Produktion, mit echten Nutzerdaten oder auf einem Drittsystem aus. Deaktivieren Sie den Netzwerkzugriff, sofern Ihr eigener Test ihn nicht erfordert und Sie den Zugriff nicht bewusst begrenzt haben.
4. **Prüfen Sie das Ergebnis unabhängig.**Bestätigen Sie das Verhalten mit Projekttests oder einem minimalen Regressionstest. Prüfen Sie die behaupteten betroffenen Versionen und ob das Problem innerhalb der tatsächlichen Vertrauensgrenzen des Projekts erreichbar ist. Unterscheiden Sie in der internen Dokumentation zwischen „reproduziert“, „plausibel, aber nicht reproduziert“, „Duplikat“ und „nicht zutreffend“.
5. **Prüfen Sie Bisektion und Patch als Vorschläge.**Bestätigen Sie die genannten Commits und Codeänderungen selbst. Wenden Sie einen Patch-Vorschlag nur in einem Branch an, prüfen Sie den Diff, führen Sie relevante Tests aus und ergänzen Sie gegebenenfalls einen Regressionstest. Mergen Sie nicht allein deshalb, weil der Bericht einen Schweregrad nennt oder Code mitliefert.
6. **Koordinieren Sie Offenlegung und Behebung.**Befolgen Sie Ihre Sicherheitsrichtlinie und das einschlägige Offenlegungsverfahren des Ökosystems. Anthropic erklärt, dass für nicht validierte OSS-Scanner-Befunde keine 90-tägige Frist für koordinierte Offenlegung gilt und Anthropic sie nicht öffentlich macht. Validiert Anthropic einen Bericht später manuell über das CVD-Programm, kann laut FAQ die 90-Tage-Frist mit der Benachrichtigung über diese menschliche Validierung beginnen. Ihre eigenen rechtlichen, vertraglichen oder ökosystembezogenen Pflichten bleiben davon unberührt.
7. **Geben Sie konkretes Feedback.**Anthropic lädt Maintainer ein, auf Berichts-E-Mails mit Feedback zu antworten. Ist ein Befund ungültig, doppelt, falsch priorisiert oder beruht er auf einem Missverständnis des Bedrohungsmodells, benennen Sie den konkreten Punkt und Belege, damit der Bericht korrigiert werden kann.

Wenn sich Ihre Kapazität ändert, dokumentiert die FAQ zwei Steuerungsmöglichkeiten: Setzen Sie `disabled: true` in einem Pull Request, um Berichte zu pausieren, oder entfernen Sie das Projektverzeichnis, um die Anmeldung zurückzuziehen. Bestätigen Sie die Änderung im Repository, bevor Sie davon ausgehen, dass Scans beendet sind.

## Was Anthropics Validierungszahlen zeigen – und was nicht

Anthropic berichtet, dass Penetrationstester 97 kritische und schwerwiegende Befunde einer frühen Scanner-Version in 48 Projekten untersucht haben. 85 hätten die CVD-Schwelle erfüllt. Von den übrigen zwölf seien elf real, aber doppelt oder anderweitig überlappend gewesen; einer sei ungültig gewesen. Anthropic führt außerdem Maintainer-Feedback an und erwartet eine Trefferquote über 90 Prozent.

Das sind von Anthropic berichtete Validierungsergebnisse und Erwartungen, keine unabhängige Reproduktion und keine Garantie für einen neuen Bericht. Die Testmenge wurde aus frühen Scanner-Ausgaben ausgewählt und umfasste 48 Projekte. Sie belegt nicht, dass jedes künftige Ergebnis, jeder Schweregrad oder jeder Patch korrekt ist. Die sinnvolle praktische Schlussfolgerung ist enger: Das System kann Berichte schneller sichtbar machen; Validierung, Priorisierung und Korrekturen bleiben dennoch Aufgabe der Maintainer.

## Die große Veränderung

OSS Scanner bietet geeigneten Open-Source-Maintainern einen Opt-in-Weg, regelmäßig kostenlose, modellgenerierte Sicherheitsberichte vor einer menschlichen Prüfung zu erhalten. Es geht nicht nur darum, ob man einen kostenlosen Scan annimmt, sondern darum, ob das Projekt einen schnelleren Strom ungeprüfter Befunde sicher aufnehmen und validieren kann.

## Quellen und weiterführende Informationen

- [Anthropic OSS Scanner FAQ und Anmeldeanweisungen](https://red.anthropic.com/oss-scanner/) — Voraussetzungen, Maintainer-Prüfung, Konfigurationsfelder, Build-Anforderungen, Berichtsfrequenz, Offenlegungsrichtlinie und Abmeldeoptionen.
- [Anthropic- `oss-scanner` Repository](https://github.com/anthropics/oss-scanner) — Pull-Request-Verfahren zur Anmeldung, Validierungs- und lokale Build-Prüfwerkzeuge sowie Sicherheitsaspekte.
- [Projektkonfigurationsvorlage](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — aktuelle Beispiele für Repository, Kontakt, Dockerfile, Bedrohungsmodell, Verschlüsselung und Pausieren von Berichten.
- [Anthropic: „Start eines Opt-in-Dienstes zur Schwachstellensuche in Open-Source-Software“](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — Beschreibung zum Start, Inhalte modellgenerierter Berichte und Anthropic zugeschriebene frühe Validierungszahlen.
- [Anthropic: „Vorstellung der Anthropic Cyber Mission“](https://www.anthropic.com/news/anthropic-cyber-mission) — weiterer Programmhintergrund und Abgrenzung zwischen OSS-Scanner-Berichten und menschlich geprüfter Offenlegung.

*Dokumentationsbasierter Leitfaden, geprüft am 9. Oktober 2026. BIG CHANGE hat sich nicht angemeldet, keinen Scan ausgeführt und keine Schwachstelle reproduziert.*

## Sources

- [Anthropic OSS Scanner FAQ und Anmeldeanweisungen](https://red.anthropic.com/oss-scanner/) — Offizielle FAQ zu Voraussetzungen, Maintainer-Prüfung, Anmeldefeldern, Berichtsinhalten und -frequenz, Offenlegung, Pausieren und Zurückziehen.
- [Anthropic OSS Scanner Repository](https://github.com/anthropics/oss-scanner) — Offizielles Anmelde-README zu Konfiguration, Build- und Offline-Audit-Grenze, lokalen Validierungswerkzeugen, Voraussetzungen und Docker-Sicherheitsaspekten.
- [Anthropic OSS Scanner project.yaml-Vorlage](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — Offizielles Beispiel für erforderliche und optionale Konfigurationsfelder.
- [Start eines Opt-in-Dienstes zur Schwachstellensuche in Open-Source-Software](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — Anthropics Startbericht zu modellgenerierten Berichten und ihren Inhalten, Einzelfall-Anmeldungen und vom Anbieter gemeldeten frühen Validierungszahlen.
- [Vorstellung der Anthropic Cyber Mission](https://www.anthropic.com/news/anthropic-cyber-mission) — Anthropic-Ankündigung zu OSS Scanner im breiteren Cyber-Mission-Programm und zur Abgrenzung von menschlich geprüften CVD-Berichten.