Indice

Introduzione

Quando parliamo di sicurezza informatica, la maggior parte degli imprenditori italiani pensa a due cose: antivirus e backup. Sono due pezzi importanti del puzzle, ma non sono più il cuore del problema. Il cuore del problema oggi sta nel software che la tua azienda usa internamente o offre ai clienti — gestionali custom, e-commerce, aree riservate, applicazioni interne, integrazioni tra sistemi. Quel software ha delle vulnerabilità, e le ha sempre avute. La novità è che oggi esistono strumenti di intelligenza artificiale in grado di trovarle molto più velocemente di quanto chiunque potesse immaginare fino a due anni fa.

Questo articolo prova a spiegare, con linguaggio non da esperti, cosa sta cambiando davvero e perché anche una PMI che non si considera "tech" dovrebbe iniziare a ragionare su queste cose con più serietà.

Perché "non siamo un'azienda software" non è più una scusa

La frase "noi non siamo un'azienda software, siamo un'azienda di produzione/servizi/commerciale" ha protetto mentalmente molte PMI italiane dal prendere sul serio la sicurezza del codice. Il ragionamento era: "se non sviluppiamo software, non siamo vulnerabili al tipo di attacchi che colpiscono le aziende tech". È sempre stata una semplificazione pericolosa, ma oggi è completamente superata.

Il motivo è che ogni azienda sopra una certa dimensione, oggi, usa software che contiene codice scritto su misura. Può essere un gestionale customizzato, un e-commerce costruito su una piattaforma con plugin modificati, un'area clienti con login e password, un'integrazione tra sistemi via API, una piccola web app per il tuo magazzino o per i preventivi. Tutto quel codice ha vulnerabilità, anche quando è stato scritto bene. Quando è stato scritto in fretta o da persone diverse nel tempo, ne ha tantissime.

Il consiglio operativo è di fare un censimento onesto: scrivi in una pagina tutti i pezzi di software "personalizzati" che la tua azienda usa o espone su internet. Gestionale interno, e-commerce, portali fornitori, aree riservate, tool interni. Ogni voce di quella lista è un potenziale punto di ingresso. Non serve che tu diventi un esperto di sicurezza, ma serve che tu sappia cosa hai.

Dove si nascondono le vulnerabilità nelle PMI italiane

Lavorando con codice di aziende di medie dimensioni si riconoscono sempre gli stessi pattern di fragilità. Non sono cose esoteriche: sono errori diffusi, spesso ereditati da anni di sviluppi stratificati senza una vera revisione.

Il primo punto fragile è la gestione delle sessioni utente. Sistemi che non scadono mai, token prevedibili, password memorizzate in modi approssimativi, pagine di login che non limitano i tentativi di accesso. Un attaccante con gli strumenti giusti trova queste cose in pochi minuti.

Il secondo è l'upload di file. Gestionali e e-commerce che accettano file dai clienti — grafiche, documenti, allegati — sono un vettore classico. Se non controlli con attenzione cosa viene caricato, dove finisce e chi può leggerlo, stai regalando una porta sul retro.

Il terzo è l'esposizione di dati via API. Integrazioni fatte per uno scopo e poi lasciate aperte, endpoint non documentati che restituiscono più informazioni di quelle che dovrebbero, token di accesso salvati in chiaro dentro file di configurazione committati per errore.

Il quarto è il codice legacy che nessuno tocca più. Quel vecchio script in PHP o ASP che "funziona così da anni". È il candidato perfetto per ospitare una vulnerabilità che, se trovata, apre un accesso a dati molto più recenti di lui.

L'azione pratica che consiglio è di fare una lista dei tuoi tre punti di ingresso più esposti — quelli che ricevono traffico dall'esterno — e di metterli in coda per un controllo serio. Non serve fare tutto, serve iniziare dai punti che l'attaccante guarderebbe per primi.

Come l'AI sta cambiando il lavoro di chi difende (e di chi attacca)

Fino a pochi anni fa, l'analisi di sicurezza del codice era un lavoro da specialisti costosi, lento, che richiedeva settimane per coprire anche solo una parte del patrimonio applicativo di un'azienda. Oggi esistono modelli di intelligenza artificiale capaci di leggere milioni di righe di codice in ore, individuare pattern di vulnerabilità, produrre proof-of-concept di attacchi e suggerire correzioni. Sono gli stessi strumenti che possono essere usati per proteggere e per attaccare. Questa asimmetria è il punto critico.

Per chi difende, la buona notizia è che il costo e il tempo di un audit serio sono crollati. Una PMI che dieci anni fa non si sarebbe potuta permettere un'analisi di sicurezza esterna oggi può ottenere risultati importanti con investimenti molto più bassi. Per chi attacca, la brutta notizia è che anche gli attaccanti usano gli stessi strumenti. Chi vive di attacchi automatizzati può scansionare migliaia di bersagli alla volta cercando vulnerabilità che prima sarebbero rimaste nascoste per anni.

La conseguenza pratica è che l'equilibrio difensivo si è spostato. Prima potevi contare sull'oscurità — "chi mai andrà a cercare una falla nel nostro gestionale?" — adesso non più. I gestionali delle PMI vengono scansionati ogni giorno da bot automatici, e le falle vengono trovate da modelli AI senza che ci sia un essere umano dietro ogni scansione.

Il passaggio concreto da fare è smettere di fidarsi dell'assenza di attacchi come prova di sicurezza. Il fatto che finora non ti sia capitato nulla non significa che sei al sicuro, significa che non sei ancora stato bersaglio. È un criterio di probabilità, non di certezza.

Cosa può fare concretamente una PMI oggi

Non servono budget da grande impresa per iniziare a difendersi in modo ragionevole. Servono tre cose, in questo ordine.

Prima: mappa e aggiorna. Fai un inventario del tuo software personalizzato e di tutti i componenti esterni che usa — librerie, plugin, framework. Verifica che siano aggiornati. Un numero sorprendente di violazioni avviene sfruttando vulnerabilità note per cui esiste già una patch da mesi, ma nessuno l'ha applicata. La pratica semplice è definire un ritmo mensile di aggiornamento e farlo davvero, anche quando non si rompe nulla.

Seconda: analizza il codice con strumenti moderni. Oggi esistono servizi di analisi statica che usano modelli AI, costano poco e producono report leggibili anche da chi non è sviluppatore. Non sostituiscono un audit professionale, ma fanno emergere i problemi più grossi. La regola è: una scansione completa ogni sei mesi come minimo, e dopo ogni rilascio importante come buona abitudine.

Terza: proteggi ciò che è esposto su internet con un livello in più. Un web application firewall (WAF), una gestione seria dei backup, logging delle anomalie, alerting quando qualcosa va fuori normalità. Sono strati che non dipendono dal codice: anche se il tuo codice ha bug, il WAF ferma una buona parte degli attacchi automatizzati prima che li raggiungano.

Se non sai da dove partire, scegli una di queste tre azioni — la più realistica per il tuo contesto — e mettila a calendario per questo trimestre. L'errore più grande è cercare di fare tutto e finire per non fare niente.

Gli errori più comuni nella gestione della sicurezza applicativa

Ci sono quattro errori ricorrenti che ho visto fare anche a imprenditori molto attenti ad altri rischi.

Il primo è considerare la sicurezza una spesa, non un investimento. Viene vista come un costo da rimandare, finché qualcosa non succede. A quel punto il costo è dieci volte più alto, e spesso arrivano anche sanzioni, perdita di clienti e di reputazione.

Il secondo è affidarsi ciecamente a un fornitore esterno senza verificare. "Ci pensa il nostro consulente informatico." Può essere vero, ma il minimo che serve è che tu sappia che cosa sta facendo: quali strumenti usa, con che periodicità, con quali risultati. Se il tuo consulente non sa risponderti in modo chiaro, hai un problema.

Il terzo è confondere backup con sicurezza. Il backup ti protegge dalla perdita di dati, non da un attacco che li ha già esfiltrati o criptati per ricatto. Sono due livelli diversi, entrambi necessari, e uno non sostituisce l'altro.

Il quarto è sottovalutare il fattore umano. La maggior parte delle violazioni iniziano da un clic su una mail. Tutti gli investimenti in tecnologia valgono meno della formazione di base del personale sul phishing e sull'uso responsabile delle credenziali. Una sessione pratica ogni sei mesi, con esempi reali, sposta il livello di rischio più di molti firewall.

Conclusione

La sicurezza del software non è più un tema da esperti riservato alle aziende tech. È una preoccupazione di business che riguarda chiunque dipenda da applicazioni custom per far girare la propria azienda — e oggi riguarda praticamente tutti. L'arrivo di modelli AI capaci di scovare vulnerabilità in autonomia ha accelerato sia il lato dei difensori sia quello degli attaccanti, spostando l'equilibrio verso chi si muove con metodo e chiude le finestre che fino a ieri poteva permettersi di lasciare aperte.

L'invito operativo è molto semplice: prenditi un'ora questa settimana e scrivi, su un foglio, le risposte a tre domande. Quali applicazioni custom usa la mia azienda? Chi le aggiorna e con che ritmo? Quando è stata fatta l'ultima analisi di sicurezza? Se anche una sola di quelle risposte è "non lo so", quello è il punto da cui iniziare.

Le domande più comuni

Come si integra un'analisi AI di sicurezza nel ciclo di sviluppo?

La via più semplice è collegare lo scan AI al sistema di controllo versione (Git) e farlo girare sulle pull request o sulle branch principali. L'output va trattato come un report di revisione: ogni segnalazione viene valutata da uno sviluppatore e classificata come falso positivo, problema minore o vulnerabilità reale. Non va automatizzata la correzione, solo la rilevazione. L'AI individua, l'uomo decide. Questo è il modello che funziona oggi.

Quanto costa far analizzare il codice da un'AI di sicurezza?

I costi variano in base al volume di codice e alla frequenza di scan. Per una PMI con un repository medio, una prima analisi una tantum può costare da poche decine a qualche centinaio di euro in API. Scan continui integrati nel CI/CD si attestano tra i 50 e i 300 euro al mese. Il vero costo non è l'AI, è il tempo di un developer esperto per valutare i risultati. Preventivalo.

Qual è la differenza tra code review tradizionale e analisi AI?

La code review umana coglie intenzione, contesto e logica di business, cose in cui l'AI è ancora debole. L'analisi AI coglie pattern sospetti, vulnerabilità note, uso improprio di librerie, scalando a volumi che una review umana non copre. Le due si completano. Affidarsi solo all'AI lascia scoperto il livello strategico del codice; affidarsi solo all'uomo lascia scoperto il livello di copertura. La combinazione è l'unica strategia sensata.

Cosa fare se l'AI segnala una vulnerabilità in codice legacy?

Prima di tutto, valuta l'effettiva esposizione: il codice è realmente esposto su internet? I dati che tratta sono sensibili? Solo se sì, prioritizza la fix. In codice legacy la correzione può essere costosa e rischiosa, a volte conviene isolare il modulo dietro un layer di validazione invece di riscriverlo. L'obiettivo non è "eliminare tutte le segnalazioni", è ridurre il rischio complessivo nel modo più efficiente.

Quando conviene affiancare un'AI ai penetration test tradizionali?

Quando la base di codice è abbastanza grande da rendere impraticabile una revisione manuale completa, e quando il ciclo di rilascio è rapido. L'AI copre la parte quantitativa (molti controlli su molto codice), il pen test umano copre la parte qualitativa (scenari reali, attacchi creativi). Non si sostituiscono, si rinforzano. Per aziende con un solo applicativo piccolo e rilasci semestrali il pen test tradizionale basta ancora.

Quali rischi comporta usare un'AI che accede al codice sorgente?

Il principale è la fuga di proprietà intellettuale se il fornitore AI usa il tuo codice per allenare i propri modelli. Verifica sempre la policy del fornitore, cerca piani enterprise con data privacy garantita per contratto e scarta i servizi che non offrono garanzie scritte. Un secondo rischio è che credenziali o token nel codice finiscano nei log del provider: pulisci sempre il codice dai segreti prima dello scan, anche se il fornitore dichiara di non loggare.