Generador de modelos de amenazas
Indica a los escáneres de IA qué es importante en tu proyecto
La mayoría de los falsos positivos se deben a que el escáner no entiende quién es el atacante. Un modelo de amenazas breve lo corrige. Marca las casillas, copia el archivo en .oss-scanner/threat_model.md y tanto ossscanner.org como OSS Scanner de Anthropic lo seguirán.
Parches candidatos
Deduplicación
.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.
Confirma este archivo como .oss-scanner/threat_model.md en tu repo. El archivo generado está en inglés para que todos los escáneres y colaboradores puedan leerlo. También puedes pegarlo en la configuración de tu proyecto inscrito en ossscanner.org.
Por qué es importante un modelo de amenazas
Los escáneres de IA son buenos para detectar código que podría comportarse de forma incorrecta, pero no pueden saber si una entrada determinada está bajo el control de un atacante en tu proyecto. ¿El archivo de configuración lo escribe el operador o un usuario anónimo? ¿La CLI es un binario privilegiado setuid o una herramienta para desarrolladores? Sin ese contexto, informan de errores que nunca corregirías y clasifican mal la gravedad.
Anthropic recomienda un archivo de modelo de amenazas precisamente por este motivo, y los mantenedores que probaron su escáner dijeron que los errores más comunes eran exagerar la gravedad y malinterpretar el modelo de amenazas.
Qué incluir
- Qué hace el proyecto y quién lo ejecuta.
- Dónde entran datos no confiables: red, archivos, solicitudes, plugins.
- Qué es confiable: configuración del operador, usuarios locales, entorno de compilación.
- Qué queda fuera del alcance: pruebas, ejemplos, problemas solo locales, DoS con entradas enormes.
- Cómo evaluar la gravedad, para que «crítico» signifique lo mismo para ti y para el escáner.
- Cómo deberían ser los informes: estilo de parche, pruebas de concepto útiles, deduplicación.
Que sea breve. Una página es más que suficiente.
Dónde va el archivo
Ambos escáneres leen .oss-scanner/threat_model.md desde la raíz de tu repositorio de forma predeterminada. Para el escáner de Anthropic, también puedes establecer una ruta diferente en project.yaml o colocar threat_model.md junto a project.yaml en su repositorio. En ossscanner.org, puedes pegarlo en la configuración de tu proyecto registrado. Los cambios se aplican en el siguiente análisis.