Come leggere un report di sicurezza del sito web — senza panico | Scanthra

Scanthra · 7 min di lettura · Aggiornato Maggio 2026

Perché questi report sembrano spaventosi all'inizio

La maggior parte dei report di sicurezza è stata scritta, originariamente, da penetration tester per altri penetration tester. Usano parole come "vettore", "subdomain takeover vulnerabile", "HSTS preload mancante" come se tutti li leggessero davanti al caffè. Se sei il titolare di un piccolo sito web e hai appena aperto un PDF pieno di riquadri rossi, la reazione naturale è il panico, seguito dalla chiusura della scheda.

Non farlo. Quasi ogni report moderno — incluso quello di Scanthra — è strutturato allo stesso modo sotto lo styling, e una volta che sai dove guardare, puoi leggerne uno in circa dieci minuti.

Le quattro cose che ogni problema rilevato ti dice

1. Gravità — quanto è grave, in teoria?

La gravità è l'impatto nel caso peggiore se il problema è reale e qualcuno lo sfrutta. Usa quasi sempre cinque livelli:

• CRITICO — danno diretto, immediato. Esempi: un file .env pubblicamente leggibile con le password del database; un sottodominio che un attaccante può prendere e usare per ospitare phishing. Trattalo come da correggere oggi.
• ALTO — serio ma non istantaneo. Esempi: una versione di WordPress vecchia con exploit noti; TLS (crittografia) mancante sul dominio principale. Correggilo questa settimana.
• MEDIO — aiuterebbe un attaccante che ha già un punto d'appoggio. Esempi: intestazioni di sicurezza mancanti, flag di cookie deboli. Correggilo questo mese.
• BASSO — igiene di base. Esempi: il banner del server rivela la versione del software. Correggi quando ci sei comunque.
• INFO / Osservazione — non è un problema, è solo una cosa che abbiamo notato (es. "usi Cloudflare"). Contesto utile, nessuna azione.

2. Livello di confidenza — quanto siamo sicuri?

Gli scanner passivi guardano il tuo sito dall'esterno, come farebbe un visitatore. Non possono sempre essere sicuri al 100% che un problema rilevato sia reale. Il livello di confidenza è un numero, di solito 0–100%, che indica quanto è fiducioso lo strumento nel rilevamento stesso — separatamente da quanto sarebbe grave il problema.

Scanthra usa un modello 2D: ogni problema rilevato ha sia una gravità che un livello di confidenza. Mostriamo solo i problemi rilevati con confidenza ≥ 50%. Qualsiasi cosa al di sotto va nella sezione Osservazioni, dove diciamo "abbiamo notato questo, non siamo sicuri, ecco perché" invece di suonare falsi allarmi.

Un ordine di lettura pratico:

1. Gravità ALTA o CRITICA a ≥ 80% di confidenza — inizia da qui.
2. Gravità MEDIA a ≥ 80% di confidenza — pianifica in uno sprint.
3. ALTA o CRITICA a 50–80% di confidenza — verifica prima, poi correggi.
4. Tutto il resto — raggruppa in una finestra di manutenzione.

3. La correzione — un paragrafo, in chiaro

Ogni problema rilevato che valga qualcosa viene con un breve paragrafo "come correggere" su cui uno sviluppatore può agire. Nei report Scanthra questo si trova sotto Correggilo da solo: di solito una o due frasi, a volte uno snippet di configurazione da copiare e incollare. Se non gestisci il sito da solo, questa è la parte che inoltri a chi lo fa — il tuo sviluppatore web, l'agenzia, o il supporto dell'hosting.

Non devi capire la correzione. Devi solo essere in grado di passarla e chiedere "puoi farlo, e quando?".

4. Tag di conformità — a chi interessa oltre a te?

I problemi rilevati portano spesso tag come GDPR:Art32, NIS2:Art21, OWASP:A05. Questi sono scorciatoie che dicono "questa non è solo la nostra opinione; il regolatore/standard X si aspetta che tu gestisca questo". I tre che vedrai più spesso:

• GDPR Art. 32 — la clausola generale dell'UE sulle "misure tecniche e organizzative adeguate". Cose come la crittografia in transito (HTTPS) e la configurazione resiliente alle violazioni finiscono qui.
• NIS2 (direttiva UE sulla cybersecurity) Art. 21 — le misure di base della Direttiva NIS2: gestione del rischio, gestione delle vulnerabilità, sicurezza della supply chain, crittografia, controllo degli accessi. Anche se non sei un'entità regolamentata, i grandi clienti ti chiederanno sempre più spesso di queste cose.
• OWASP (standard di sicurezza delle app) Top 10 — la lista standard del settore dei rischi più comuni delle applicazioni web. A05 è la configurazione errata, A07 è l'identificazione e i fallimenti di autenticazione, e così via.

E i falsi positivi?

Nessuno scanner passivo è perfetto. A volte uno strumento segnala qualcosa che, nelle specifiche del tuo setup, non è in realtà un problema. Esempi:

• Un "header di sicurezza mancante" che è in realtà impostato dalla tua CDN più a monte e che lo scanner non ha potuto vedere.
• Un avviso "versione CMS (sistema di gestione contenuti) obsoleta" dove la stringa di versione è deliberatamente falsificata da un plugin di hardening.
• Un "sottodominio che non punta a nulla" dove il sottodominio è intenzionalmente parcheggiato per un lancio imminente.

In caso di dubbio: correggi comunque. Quasi ogni "falso positivo" è economico da neutralizzare, e farlo rimuove anche il rumore dalla tua prossima scansione. Le eccezioni sono i casi in cui la correzione richiederebbe lavoro reale — lì, chiedi al tuo sviluppatore di confermare prima di spendere ore.

Come condividere un report con uno sviluppatore

Se stai inoltrando il PDF, tre frasi sono sufficienti:

"Ciao — abbiamo eseguito una scansione di sicurezza. Potresti guardare i problemi rilevati ALTO e CRITICO a partire da pagina 4 e dirmi quali puoi correggere in questo sprint e quali richiedono più analisi? Sono disposto a posticipare tutto ciò che è BASSO per ora."

È tutto. Lo sviluppatore non ha bisogno di una traduzione del report; ha bisogno del permesso di dare priorità.

Come appare un report "pulito"

Spoiler: nessuno ottiene zero problemi rilevati alla prima scansione. Un tipico sito WordPress di piccole imprese ottiene ~8–15 problemi rilevati, principalmente intestazioni MEDIE e igiene dei cookie. Un obiettivo ragionevole per "pulito" è:

• Zero CRITICI.
• Zero ALTI più vecchi di 30 giorni.
• Un voto complessivo di B o migliore sulla copertina.

Qualsiasi cosa oltre è gold-plating — utile, ma non è il divario tra te e i tuoi clienti.

Come Scanthra scrive i suoi report

Teniamo deliberatamente il linguaggio semplice. Ogni problema rilevato ha una riga di impatto sul business ("se sfruttato, un attaccante potrebbe leggere le e-mail dei clienti, il che sarebbe una violazione del GDPR"), un paragrafo correggilo da solo, e una mappa di conformità all'inizio così puoi vedere a colpo d'occhio a quali enti regolatori interessa. Se un problema rilevato è borderline, lo spostiamo in Osservazioni invece di spaventarti. L'obiettivo è un report che puoi leggere sul treno di ritorno e su cui puoi agire la mattina dopo — non un PDF di 60 pagine che archivia sotto "spaventoso, ci penso dopo".