Il 4 agosto Docker ha pubblicato sul proprio blog, a firma del suo responsabile della sicurezza Mark Lechner, la lettura di un report della società di ricerca Omdia intitolato "Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption", uscito ad aprile 2026. Il dato che ne esce riguarda la sicurezza del software dei fornitori molto più di quanto riguardi l'antivirus o il firewall aziendale. Oltre tre organizzazioni su quattro, il 77 per cento, hanno subito un incidente sulla catena di fornitura del software nei dodici mesi precedenti all'indagine, condotta a febbraio 2026.
La catena di fornitura del software è l'insieme dei componenti, delle librerie e degli strumenti di terze parti che finiscono dentro un programma senza essere stati scritti da chi ve lo consegna. Detta così sembra una faccenda da informatici. È invece la stessa identica logica della distinta base di un prodotto industriale, e un imprenditore che ha a che fare con la produzione la capisce meglio di molti tecnici: quello che comprate non è un pezzo unico, è un assemblaggio, e la qualità dell'assemblaggio dipende da fornitori che non avete scelto voi.
Perché il rischio numero uno oggi è il codice che nessuno ha scritto in casa
Nel report Omdia, in cima alla classifica dei rischi della catena di fornitura le organizzazioni hanno messo la tecnologia AI, indicata dal 40 per cento, davanti al codice di terze parti e open source, indicato dal 39 per cento, e alle dipendenze software, indicate dal 38 per cento. Vale la pena fermarsi un secondo su questo ordine, perché è nuovo. Fino a poco tempo fa la voce in cima era sempre il software preso da altri. Oggi al primo posto c'è lo strumento che quel software lo scrive.
Il motivo non è misterioso e Mark Lechner lo mette per iscritto senza addolcirlo: "Building applications using third-party libraries, open source dependencies, and AI-generated code saves developers a ton of time, so it's no surprise this trend is on the rise. But it's code they didn't write, and as these time-saving inputs keep growing, so do the attack surfaces they expose". Costruire con pezzi presi altrove e con codice generato dall'AI fa risparmiare moltissimo tempo, ed è codice che nessuno in azienda ha scritto.
I numeri del report dicono che la quota di roba presa altrove sta crescendo in fretta. Oggi il 38 per cento delle organizzazioni dichiara che più della metà del proprio codice viene da terze parti, e secondo la stessa indagine entro dodici mesi saranno il 58 per cento. Sull'open source si passa dal 31 al 51 per cento nello stesso arco di tempo. Detto in italiano: fra un anno, in più di un'azienda su due, la maggior parte del software sarà fatta di pezzi presi da qualcun altro.
Poi c'è la parte che spiega perché tutto questo non resta un problema teorico. Il 38 per cento degli attacchi più comuni rilevati dal report sfruttava vulnerabilità già note in software di terze parti. Già note, cioè pubblicate, documentate e in attesa che qualcuno aggiorni. Fra le conseguenze degli incidenti subiti, il 46 per cento delle organizzazioni ha riportato accessi non autorizzati ad applicazioni e dati e il 35 per cento si è visto rubare credenziali, chiavi o password di accesso degli sviluppatori.
Cosa c'entra tutto questo con un'azienda da quaranta persone
C'entra perché nessuna PMI italiana scrive il proprio software, e quindi il rischio descritto dal report Omdia non è il rischio del fornitore: è il vostro, con il nome del fornitore sopra. Il gestionale, il sito, l'e-commerce, l'app dei preventivi, il portale dove i clienti scaricano i documenti. Tutta roba assemblata con pezzi presi altrove, tenuta insieme da un'azienda che ha i suoi tempi e le sue priorità, e che oggi con ogni probabilità scrive una parte di quel codice con l'AI.
La differenza fra un'azienda da quarantamila dipendenti e una da quaranta non è il rischio, è chi se ne accorge. La prima ha qualcuno pagato per guardare quella lista. La seconda scopre che un componente aveva una falla il giorno in cui il sito non risponde più o i dati dei clienti finiscono dove non dovevano.
Qui però va detta una cosa netta, perché il messaggio contrario circola parecchio e fa danni. Questo non è un argomento per rallentare sull'AI o per diffidare dei fornitori che la usano. Il codice generato dall'AI è in cima alla classifica dei rischi soprattutto perché è in cima alla classifica dell'uso, e chi ne fa a meno oggi paga un prezzo di velocità che nessuno può permettersi. Su questo blog ho già scritto che le PMI italiane stanno perdendo terreno sull'AI e resto della stessa idea. Il punto non è usarne meno, è sapere cosa entra in azienda. Sono due discorsi diversi, e vanno tenuti diversi.
Come si controlla la sicurezza del software dei fornitori
Si controlla con tre domande messe per iscritto, e nessuna delle tre richiede competenze informatiche interne.
La prima è la distinta. Chiedete al fornitore la distinta dei componenti software, quella che nel settore si chiama SBOM, cioè l'elenco di tutti i pezzi di terze parti dentro quello che vi ha consegnato, con nome e versione. Non chiedetela una volta sola: chiedete che sia allegata a ogni consegna, come si fa con la distinta base di un articolo. Il report Omdia rileva che fra chi le produce solo il 42 per cento lo fa in modo obbligatorio per tutte le applicazioni, mentre il 55 per cento le genera caso per caso. Tradotto: quasi sempre esiste già, e nessuno ve la manda perché nessuno l'ha chiesta.
La seconda è il tempo. Mettete nero su bianco entro quanti giorni il fornitore si impegna ad aggiornare un componente di terze parti quando viene pubblicata una falla nota. Un numero, non una formula. È la clausola che vale di più di tutte, perché il 38 per cento degli attacchi più comuni passa esattamente da quella finestra di tempo, e oggi in quasi nessun contratto di manutenzione quel numero è scritto.
La terza riguarda l'AI e sta in una riga: se usate strumenti AI per scrivere il codice che ci consegnate, chi lo rivede prima che arrivi da noi. Non serve una risposta lunga, serve che ci sia un nome. Il tema dei permessi con cui quegli strumenti lavorano dentro i vostri sistemi l'ho affrontato a parte, e chi lo sta valutando adesso trova il ragionamento completo nell'articolo su quali permessi dare agli strumenti AI in azienda.
Prima di tutte e tre viene una cosa più banale e più utile: l'elenco. Un foglio con i programmi da cui dipende davvero l'azienda, chi ve li fornisce e quando scade il contratto. Serve perché queste domande si fanno al rinnovo, non in mezzo all'anno, e perché nella maggior parte delle PMI quell'elenco non esiste. Se preferite arrivare a quella riunione con qualcuno che conosce le risposte giuste, è una delle cose che facciamo nella consulenza AI per PMI, insieme alla scelta dei processi da cui partire.
Quanti pezzi tira dentro un sito come questo
Un esempio che potete verificare, perché il codice di questo sito è a disposizione. Nel file package.json di marcomasut.com ci sono dodici dipendenze dichiarate da me, più dieci strumenti di sviluppo. Sono quelle che ho scelto una per una. Quando il sito viene costruito, però, l'elenco completo dei pacchetti che finiscono nell'installazione ne conta 609, di cui 215 arrivano fino alla parte che gira davvero online.
Dodici scelte mie, seicento pezzi installati. Nessuno di quei seicento è sospetto, e non è quello il punto. Il punto è che io il numero l'ho contato, e per un sito personale conta poco. Per il gestionale su cui gira la vostra fatturazione conta parecchio, e quel numero non ve lo ha mai detto nessuno.
Il software che usate in azienda non è un prodotto finito, è un assemblaggio che cambia a ogni aggiornamento. Chiedere di cosa è fatto non è diffidenza verso il fornitore: è la stessa domanda che fate da vent'anni a chi vi vende componenti per la produzione.
Domande frequenti
Cos'è la distinta dei componenti di un software?
La distinta dei componenti di un software, in inglese Software Bill of Materials o SBOM, è l'elenco di tutti i pezzi di terze parti contenuti in un programma, con nome e versione di ciascuno. Serve alla stessa cosa a cui serve una distinta base in produzione: quando esce un difetto su un componente, si sa in dieci minuti se quel componente è dentro casa vostra oppure no. Secondo il report Omdia di aprile 2026, fra le organizzazioni che le generano il 42 per cento le produce in modo obbligatorio per tutte le applicazioni e il 55 per cento solo caso per caso.
Cosa vuol dire catena di fornitura del software?
La catena di fornitura del software è l'insieme dei componenti, delle librerie e degli strumenti di terze parti che finiscono dentro un programma senza essere stati scritti da chi ve lo consegna. Un gestionale o un sito aziendale non sono blocchi unici scritti da una sola azienda: sono assemblati con centinaia di pezzi presi altrove, ed è quella catena che oggi viene attaccata.
Perché una vulnerabilità già nota è pericolosa proprio perché è nota?
Una vulnerabilità già nota è pubblicata, documentata e quindi facile da sfruttare in serie contro chiunque non abbia ancora aggiornato. Il report Omdia rilevato a febbraio 2026 indica che il 38 per cento degli attacchi più comuni alla catena di fornitura sfruttava proprio falle già note in software di terze parti. Il problema non è la scoperta della falla, è il tempo che passa fra la pubblicazione e l'aggiornamento.
Una PMI senza reparto informatico cosa può fare in concreto?
Può fare tre cose senza competenze tecniche interne. Scrivere l'elenco dei programmi da cui dipende davvero l'azienda e di chi glieli fornisce, chiedere a ogni fornitore la distinta dei componenti allegata alle consegne invece che su richiesta, e mettere per iscritto entro quanti giorni il fornitore si impegna ad aggiornare un componente quando esce una falla nota. Sono clausole da rinnovo di contratto, non progetti informatici.