Générateur de modèle de menace
Indiquez aux scanners IA les éléments importants de votre projet
La plupart des faux positifs proviennent d’une mauvaise compréhension de l’identité de l’attaquant par le scanner. Un modèle de menace succinct permet d’y remédier. Cochez les cases, copiez le fichier dans .oss-scanner/threat_model.md et ossscanner.org ainsi qu’Anthropic OSS Scanner en tiendront compte.
Correctifs candidats
Déduplication
.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.
Validez ce fichier dans votre dépôt sous .oss-scanner/threat_model.md. Le fichier généré est en anglais afin que tous les scanners et contributeurs puissent le lire. Vous pouvez également le coller dans les paramètres de votre projet inscrit sur ossscanner.org.
Pourquoi un modèle de menace est important
Les scanners IA repèrent efficacement le code susceptible de mal fonctionner, mais ils ne peuvent pas savoir si une entrée donnée est contrôlée par un attaquant dans votre projet. Le fichier de configuration est-il écrit par l’opérateur ou par un utilisateur anonyme ? L’interface en ligne de commande est-elle un binaire setuid privilégié ou un outil destiné aux développeurs ? Sans ce contexte, ils signalent des bogues que vous ne corrigeriez jamais et évaluent mal leur gravité.
Anthropic recommande un fichier de modèle de menace précisément pour cette raison, et les mainteneurs qui ont testé son scanner ont indiqué que les erreurs les plus courantes concernaient une gravité exagérée et une mauvaise compréhension du modèle de menace.
Éléments à inclure
- Ce que fait le projet et qui l’utilise.
- Où les données non fiables entrent : réseau, fichiers, requêtes, plugins.
- Ce qui est considéré comme fiable : configuration de l’opérateur, utilisateurs locaux, environnement de build.
- Ce qui est hors périmètre : tests, exemples, problèmes limités à l’environnement local, DoS avec des entrées volumineuses.
- Comment évaluer la gravité, afin que « critique » ait le même sens pour vous et pour le scanner.
- À quoi les rapports doivent ressembler : format des correctifs, preuves de concept utiles, déduplication.
Restez concis. Une page suffit.
Emplacement du fichier
Par défaut, les deux scanners lisent .oss-scanner/threat_model.md à la racine de votre repo. Pour le scanner d’Anthropic, vous pouvez également définir un autre chemin dans project.yaml, ou placer threat_model.md à côté de project.yaml dans son dépôt. Sur ossscanner.org, vous pouvez le coller dans les paramètres de votre projet inscrit. Les modifications prennent effet lors de l’analyse suivante.