Dreigingsmodel opstellen
Vertel AI-scanners wat belangrijk is in je project
De meeste fout-positieven ontstaan doordat een scanner verkeerd inschat wie de aanvaller is. Een kort dreigingsmodel lost dat op. Vink de vakjes aan, kopieer het bestand naar .oss-scanner/threat_model.md en zowel ossscanner.org als Anthropic OSS Scanner zullen de instructies volgen.
Kandidaatpatches
Deduplicatie
.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.
Commit dit bestand als .oss-scanner/threat_model.md in je repository. Het gegenereerde bestand is in het Engels, zodat elke scanner en bijdrager het kan lezen. Je kunt het ook plakken in de instellingen van je ingeschreven project op ossscanner.org.
Waarom een dreigingsmodel belangrijk is
AI-scanners zijn goed in het opsporen van code die zich verkeerd kan gedragen, maar ze kunnen niet weten of een bepaalde invoer in jouw project door een aanvaller kan worden beheerd. Wordt het configuratiebestand geschreven door de operator of door een anonieme gebruiker? Is de CLI een bevoorrecht setuid-binair bestand of een ontwikkelaarstool? Zonder die context melden ze bugs die je nooit zou oplossen en schatten ze de ernst verkeerd in.
Anthropic raadt juist daarom een dreigingsmodelbestand aan. Maintainers die de scanner hebben getest, zeiden dat de meest voorkomende fouten een overdreven ernstinschatting en een verkeerd begrepen dreigingsmodel waren.
Wat je moet opnemen
- Wat het project doet en wie het uitvoert.
- Waar niet-vertrouwde gegevens binnenkomen: via het netwerk, bestanden, verzoeken of plug-ins.
- Wat vertrouwd is: configuratie van de operator, lokale gebruikers, buildomgeving.
- Wat buiten de scope valt: tests, voorbeelden, uitsluitend lokale problemen, DoS met enorme invoer.
- Hoe de ernst moet worden beoordeeld, zodat ‘kritiek’ voor jou en de scanner hetzelfde betekent.
- Hoe meldingen eruit moeten zien: patchstijl, nuttige proof-of-concepts, deduplicatie.
Houd het kort. Eén pagina is ruim voldoende.
Waar het bestand hoort
Beide scanners lezen standaard .oss-scanner/threat_model.md vanuit de hoofdmap van je repo. Voor de scanner van Anthropic kun je ook een ander pad instellen in project.yaml, of threat_model.md naast project.yaml in de repo van je project plaatsen. Op ossscanner.org kun je het bestand plakken in de instellingen van je aangemelde project. Wijzigingen worden van kracht bij de volgende scan.