Criador de modelo de ameaças
Informe aos scanners de IA o que é importante no seu projeto
A maioria dos falsos positivos ocorre porque o scanner interpreta mal quem é o invasor. Um modelo de ameaças curto resolve isso. Marque as opções, copie o arquivo para .oss-scanner/threat_model.md e tanto ossscanner.org quanto Anthropic OSS Scanner seguirão essas orientações.
Patches candidatos
Deduplicação
.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.
Faça o commit deste arquivo como .oss-scanner/threat_model.md no seu repositório. O arquivo gerado está em inglês para que todos os scanners e colaboradores possam lê-lo. Você também pode colá-lo nas configurações do seu projeto cadastrado em ossscanner.org.
Por que um modelo de ameaças é importante
Scanners de IA são bons em detectar código que pode apresentar comportamento inesperado, mas não conseguem saber se determinada entrada é controlada por um invasor no seu projeto. O arquivo de configuração é escrito pelo operador ou por um usuário anônimo? A CLI é um binário setuid privilegiado ou uma ferramenta para desenvolvedores? Sem esse contexto, eles relatam bugs que você nunca corrigiria e classificam a gravidade incorretamente.
A Anthropic recomenda um arquivo de modelo de ameaças exatamente por esse motivo, e os mantenedores que testaram seu scanner disseram que os erros mais comuns eram a gravidade exagerada e a interpretação equivocada do modelo de ameaças.
O que incluir
- O que o projeto faz e quem o executa.
- Onde dados não confiáveis entram: rede, arquivos, requisições, plugins.
- O que é confiável: configuração do operador, usuários locais, ambiente de build.
- O que está fora do escopo: testes, exemplos, problemas que só ocorrem localmente, DoS com entradas enormes.
- Como avaliar a gravidade, para que crítico signifique a mesma coisa para você e para o scanner.
- Como os relatórios devem ser: no estilo de patches, com provas de conceito úteis e deduplicação.
Seja breve. Uma página é suficiente.
Onde o arquivo deve ficar
Por padrão, ambos os scanners leem .oss-scanner/threat_model.md na raiz do seu repo. No scanner da Anthropic, você também pode definir outro caminho em project.yaml ou colocar threat_model.md ao lado de project.yaml no repo. No ossscanner.org, você pode colar o arquivo nas configurações do projeto cadastrado. As alterações entram em vigor na próxima varredura.