Generator für Bedrohungsmodelle
Teile KI-Scannern mit, was in deinem Projekt wichtig ist
Die meisten Fehlalarme entstehen, weil ein Scanner falsch einschätzt, wer der Angreifer ist. Ein kurzes Bedrohungsmodell schafft Abhilfe. Aktiviere die Kästchen, kopiere die Datei nach .oss-scanner/threat_model.md und sowohl ossscanner.org als auch Anthropic OSS Scanner halten sich daran.
Patches in Vorbereitung
Deduplizierung
.oss-scanner/threat_model.md
# Threat model ## About the project _Describe what the project does and who runs it._ ## Untrusted input (treat as adversarial) - Bytes received over the network (sockets, protocol messages, peers). - Files that users open or upload (documents, images, media, fonts). ## Out of scope (do not report) - Test code, fixtures and fuzzing harnesses. - Examples, demos and documentation snippets. - Build scripts, CI configuration and developer-only tooling. - Denial of service that needs very large inputs or sustained traffic. ## Severity rubric - **critical**: Remote code execution or full authentication bypass on a default configuration. - **high**: Memory corruption, privilege escalation or exposure of other users' data with a realistic attack path. - **medium**: Limited impact, or significant preconditions such as non-default settings or an authenticated attacker. - **low**: Hardening issues with no demonstrated security impact. ## Report format - Keep reports short: one-paragraph summary first, then affected file and lines, impact, reproducer and fix. - Candidate patches: minimal, enough to show the root cause and how to fix it. - Deduplicate by root cause: one report per underlying bug even if it is reachable from several places.
Committe diese Datei als .oss-scanner/threat_model.md in dein Repository. Die generierte Datei ist auf Englisch, damit jeder Scanner und jeder Beitragende sie lesen kann. Du kannst sie auch in die Einstellungen deines registrierten Projekts auf ossscanner.org einfügen.
Warum ein Bedrohungsmodell wichtig ist
KI-Scanner erkennen gut, welcher Code sich möglicherweise fehlerhaft verhält. Sie können aber nicht wissen, ob eine bestimmte Eingabe in deinem Projekt von einem Angreifer kontrolliert wird. Wird die Konfigurationsdatei vom Betreiber oder von einem anonymen Benutzer geschrieben? Ist die CLI ein privilegiertes setuid-Binary oder ein Entwicklerwerkzeug? Ohne diesen Kontext melden sie Fehler, die du nie beheben würdest, und stufen den Schweregrad falsch ein.
Anthropic empfiehlt aus genau diesem Grund eine Bedrohungsmodelldatei. Maintainer, die den Scanner getestet haben, sagten, die häufigsten Fehler seien ein überhöhter Schweregrad und ein falsch verstandenes Bedrohungsmodell gewesen.
Was enthalten sein sollte
- Was das Projekt tut und wer es ausführt.
- Wo nicht vertrauenswürdige Daten eingehen: über das Netzwerk, Dateien, Anfragen oder Plugins.
- Was vertrauenswürdig ist: Betreiberkonfiguration, lokale Benutzer, Build-Umgebung.
- Was außerhalb des Geltungsbereichs liegt: Tests, Beispiele, Probleme, die nur lokal auftreten, DoS mit sehr großen Eingaben.
- Wie der Schweregrad einzustufen ist, damit „kritisch“ für dich und den Scanner dasselbe bedeutet.
- Wie Meldungen aussehen sollten: Patch-Format, nützliche PoCs, Deduplizierung.
Halte es kurz. Eine Seite reicht völlig.
Wohin die Datei gehört
Beide Scanner lesen standardmäßig .oss-scanner/threat_model.md aus dem Stammverzeichnis deines Repositorys. Beim Scanner von Anthropic kannst du in project.yaml auch einen anderen Pfad festlegen oder threat_model.md neben project.yaml in dessen Repository ablegen. Auf ossscanner.org kannst du die Datei in die Einstellungen deines angemeldeten Projekts einfügen. Änderungen werden beim nächsten Scan wirksam.