Generatore di modelli di minaccia
Indica agli scanner IA cosa conta nel tuo progetto
La maggior parte dei falsi positivi deriva da un'errata interpretazione, da parte dello scanner, di chi sia l'attaccante. Un breve modello di minaccia risolve il problema. Seleziona le caselle, copia il file in .oss-scanner/threat_model.md e sia ossscanner.org sia Anthropic OSS Scanner lo seguiranno.
Patch candidate
Deduplicazione
.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.
Esegui il commit di questo file come .oss-scanner/threat_model.md nel tuo repository. Il file generato è in inglese, così ogni scanner e collaboratore può leggerlo. Puoi anche incollarlo nelle impostazioni del progetto registrato su ossscanner.org.
Perché è importante un modello di minaccia
Gli scanner basati sull'IA sono efficaci nell'individuare codice che potrebbe comportarsi in modo anomalo, ma non possono sapere se nel tuo progetto un determinato input è controllato da un attaccante. Il file di configurazione viene scritto dall'operatore o da un utente anonimo? La CLI è un binario privilegiato setuid o uno strumento per sviluppatori? Senza questo contesto, segnalano bug che non correggeresti mai e valutano la gravità in modo errato.
Anthropic raccomanda un file con il modello di minaccia proprio per questo motivo; i maintainer che hanno testato il suo scanner hanno detto che gli errori più comuni riguardavano una gravità sovrastimata e un modello di minaccia frainteso.
Cosa includere
- Cosa fa il progetto e chi lo esegue.
- Da dove provengono i dati non attendibili: rete, file, richieste, plugin.
- Cosa è considerato attendibile: configurazione dell'operatore, utenti locali, ambiente di build.
- Cosa non rientra nell'ambito: test, esempi, problemi solo locali, DoS con input enormi.
- Come valutare la gravità, affinché «critico» significhi la stessa cosa per te e per lo scanner.
- Come dovrebbero essere le segnalazioni: stile delle patch, proof of concept utili, deduplicazione.
Mantienilo breve. Una pagina basta.
Dove va il file
Entrambi gli scanner leggono .oss-scanner/threat_model.md dalla root del tuo repo per impostazione predefinita. Per lo scanner di Anthropic puoi anche impostare un percorso diverso in project.yaml oppure collocare threat_model.md accanto a project.yaml nel repo. Su ossscanner.org puoi incollarlo nelle impostazioni del progetto registrato. Le modifiche diventano effettive alla scansione successiva.