Il settore cloud nel 2025 è arrivato a ben 8,13 miliardi di euro in Italia e, nello stesso perioro, sono stati registrati 1.549 eventi cyber nel primo semestre e 1.253 nel secondo. Ormai è sempre più chiaro che la scansione delle immagini container non è più un controllo da fare alla fine, ma è uno step che pesa sui tempi di rilascio, sulle priorità operative e sulla tenuta di tutta la pipeline.

Oggi, la container vulnerability scanning non è più solo un check tecnico ma significa guardare come si sviluppano le applicazioni: più cloud, più microservizi, più dipendenze, più immagini riutilizzate e una velocità di rilascio che lascia poco spazio agli interventi manuali. Adesso che il cloud italiano va così forte, i container smettono di essere un dettaglio infrastrutturale e diventano uno snodo vero della sicurezza applicativa. Ogni immagine porta con sé librerie, base image, pacchetti e componenti che vanno capiti prima del deploy, non dopo. Le analisi sulla sicurezza cloud-native mostrano che gli errori quotidiani come le misconfigurazioni, le vulnerabilità note non corrette e i controlli identitari incompleti sono tra le cause più concrete degli incidenti. È qui che molti luoghi comuni iniziano a crollare, non basta più fare una scansione per stare tranquilli.

Perché nel 2026 la scansione dei container non è più un tema per pochi

Il primo mito è semplice: la scansione dei container riguarderebbe solo le grandi enterprise piene di cluster e team DevSecOps. In realtà, il quadro italiano dice altro. Le PMI mantengono un’adozione cloud stabile al 67% e hanno aumentato la spesa in Public e Hybrid Cloud fino a 690 milioni di euro nel 2025. Questo significa che il perimetro cloud si è allargato anche fuori dalle organizzazioni più strutturate e, quindi, cresce il numero di immagini, registri e componenti da tenere sotto controllo.

Le analisi sulla cloud security ricordano che le vulnerabilità nei registri dei container, le immagini non sicure e le configurazioni errate di Kubernetes possono compromettere l’intera infrastruttura. Le misure di difesa devono concentrarsi sulla sicurezza delle immagini, sulla loro provenienza e su strumenti capaci di rilevare i malware e le vulnerabilità.

Il mito: basta una scansione prima del rilascio e poi il lavoro è finito?

Questo è probabilmente l’equivoco più diffuso. Si costruisce l’immagine, si lancia uno scan, si guarda se c’è qualche CVE critica e si va in produzione. Peccato che le vulnerabilità non restano ferme. Il processo utile non è lo scan una tantum, ma una routine fatta di ispezione su come nasce l’immagine, scansione periodica, mitigazioni sul processo di build e monitoraggio delle attività di runtime. È questo il motivo per cui la scansione continua ormai è entrata in modo naturale nelle pipeline DevSecOps.

C’è poi un altro punto che è diventato ancora più chiaro. Lo SBOM è uno strumento capace di aumentare la trasparenza e di ridurre il rischio cyber, proprio perché aiuta a sapere con precisione quali componenti stanno dentro un software. E senza inventario, una scansione perde profondità: trovi magari il problema del giorno, ma non costruisci una vista stabile su cosa stai davvero distribuendo. Una buona scansione, quindi, non chiude il lavoro, ma lo apre nel modo giusto.

Pensare che uno scanner trovi tutto è un modo per creare una falsa sicurezza

Un altro mito duro a morire è questo: se l’immagine passa lo scan, il container è a posto. Non funziona così. Per i container contano anche la provenienza delle immagini, il controllo degli accessi, la sicurezza di rete e la protezione dell’ambiente runtime. Ci sono altri elementi che continuano a fare danni: configurazioni errate, IAM gestito male, API esposte, dipendenze di terze parti poco controllate.

In pratica, lo scanner è necessario ma non è onnipotente. Aiuta a leggere vulnerabilità note e componenti a rischio, ma non sostituisce il controllo sul contesto in cui quell’immagine verrà eseguita. Nei container il tema è ancora più delicato perché condividono il kernel dell’host, e quindi una compromissione può avere un impatto molto ampio. Se l’immagine è pulita ma il cluster è configurato male, o i permessi sono troppo generosi, non devi farti ingannare dalla sicurezza.

Alla fine conta meno il tool e molto di più il metodo con cui lo usi

Se metti insieme i dati del 2025, il quadro è abbastanza netto. Da una parte il cloud italiano continua a crescere e porta sempre più applicazioni su piattaforme dinamiche e distribuite; dall’altra gli eventi cyber restano alti e gli incidenti cloud-native mostrano che le cause più frequenti sono le vulnerabilità note, le configurazioni sbagliate e i controlli deboli.

Da questo punto di vista, il container scanning non è né una bacchetta magica né un vezzo da compliance. È una pratica concreta che funziona davvero, ma deve essere continua, contestualizzata e inserita in un metodo fatto di inventario, di priorità e di verifica costante lungo tutta la pipeline.