Threat model builder
Tell AI scanners what matters in your project
Most false positives come from a scanner misunderstanding who the attacker is. A short threat model fixes that. Tick the boxes, copy the file to .oss-scanner/threat_model.md and both ossscanner.org and Anthropic's OSS Scanner will follow it.
Candidate patches
Deduplication
.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 this file as .oss-scanner/threat_model.md in your repository. The generated file is in English so every scanner and contributor can read it. You can also paste it into your enrolled project's settings on ossscanner.org.
Why a threat model matters
AI scanners are good at spotting code that could misbehave, but they can't know whether a given input is attacker-controlled in your project. Is the config file written by the operator or by an anonymous user? Is the CLI a privileged setuid binary or a developer tool? Without that context they report bugs you'd never fix and rank severity wrongly.
Anthropic recommends a threat model file for exactly this reason, and maintainers who tested its scanner said the most common mistakes were inflated severity and a misunderstood threat model.
What to include
- What the project does and who runs it.
- Where untrusted data enters: network, files, requests, plugins.
- What is trusted: operator config, local users, build environment.
- What is out of scope: tests, examples, local-only issues, DoS with huge inputs.
- How to rate severity, so critical means the same thing to you and the scanner.
- What reports should look like: patch style, useful proofs of concept, deduplication.
Keep it short. A page is plenty.
Where the file goes
Both scanners read .oss-scanner/threat_model.md from the root of your repository by default. For Anthropic's scanner you can also set a different path in project.yaml, or place threat_model.md next to project.yaml in their repository. On ossscanner.org you can paste it into your enrolled project's settings. Changes take effect on the next scan.