I container vivono un periodo di crescente successo e oggi aziende di tutte le dimensioni sviluppano piani su come containerizzare le proprie applicazioni. Com'è noto,
Kubernetes ha vinto la sfida di mercato dei container, nell’ambito della loro orchestrazione. In realtà la gestione del ciclo di vita dell’immagine dei container è stata vinta da
Docker, come confermano i dati sulla loro diffusione, con oltre 1 miliardo di container Docker scaricati ogni due settimane in base alla ricerca “
The state of open source security Report 2019” di
Snyk, e con Docker Hub che è diventato per le aziende quello che l'App Store e Google Play rappresentano per i consumatori.
Le immagini del container oggi sono eseguite nell’intera infrastruttura, dai sistemi operativi di base agli stack applicativi, ai database al middleware fino agli app engine che supportano node.js, Python e Go e comprendono anche l’integrazione con l’ecosistema per i servizi applicativi. La maggior parte delle aziende che fanno deployment di app mediante container utilizzano Kubernetes come sistema di orchestrazione di immagini Docker. In molti casi però si tratta di immagini vulnerabili.
La
ricerca di Snyk ha rivelato che "
ognuna delle prime dieci immagini Docker predefinite più utilizzate contiene almeno 30 librerie di sistema vulnerabili”. Queste librerie di sistema sono presenti su molte immagini Docker, dato che si basano su un'immagine principale che utilizza comunemente come base una distribuzione Linux”. I dati di Snyk lo confermano: il numero di vulnerabilità è in costante aumento in tutte e tre le principali distribuzioni Linux.In sintesi, ci troviamo di fronte a un’enormità di immagini vulnerabili che vengono scaricate in ogni momento dalle organizzazioni.
Non sorprende, quindi, che lo "
State of container security 2019" di
Tripwire abbia riscontrato una percentuale allarmante:
il 60% degli intervistati, negli ultimi dodici mesi ha subito un incidente di sicurezza che ha riguardato i container. Circa un intervistato su cinque (il 17%) ha dichiarato che l'organizzazione in realtà era a conoscenza delle vulnerabilità, ma che ha comunque deciso di implementare le immagini. Tutto questo nonostante sia noto che il 44% delle immagini Docker contiene vulnerabilità conosciute e che fossero disponibili immagini di base più recenti e sicure. In altre parole, implementare un'immagine aggiornata avrebbe consentito di mitigare il rischio e un altro 22% delle immagini con vulnerabilità si poteva affrontare e risolvere semplicemente ricostruendo l'immagine.
Lori MacVittie, Principal Technical Evangelist di F5 NetworksLa situazione sembra per certi versi assurda: gran parte dell’attenzione quando si parla di “shift security left” è rivolta tanto all'implementazione di servizi adeguati per applicare la sicurezza (difesa dai Bot, web application firewall, controllo dell'identità e degli accessi) quanto all’integrazione di security practice nel ciclo di sviluppo e implementazione dei container. Tali pratiche includono la scansione del codice e dei container per identificare vulnerabilità note e quindi risolverle.
Una cosa è certa: si può fare di meglio. La velocità è importante, anche nella containerizzazione, ma
la velocità senza la sicurezza è pericolosa, non solo per l'organizzazione, ma anche per i clienti che alla fine utilizzeranno le app che saranno distribuite. Per questo motivo credo che
una containerizzazione sicura debba prevedere cinque passaggi fondamentali:
- Valutare il reale utilizzo - Molte organizzazioni non sono consapevoli di quanto sia pervasivo il loro consumo di immagini/sorgenti open source e di terze parti. Averne la consapevolezza rappresenta un primo passo importante. Non si può pensare di affrontare le vulnerabilità di un software senza nemmeno sapere che lo si sta utilizzando.
- Standardizzare - cercare di identificare un terreno comune tra applicazioni e le operation per standardizzare il minor numero possibile di immagini/componenti del container. Un approccio di questo tipo consente di distribuire l'onere della sicurezza in tutta l'organizzazione e si traduce alla fine in un livello di sicurezza maggiore per tutti.
- Controllare la sicurezza del codice tramite review costanti - Nel caso vengano incluse componenti o script di terze parti (cosa che avviene quasi sempre) vanno sempre analizzate e distribuite/costruite a partire da un repository privato.
- Promuovere gli audit sulla sicurezza del container. Quando si consumano immagini di terze parti, è necessario promuovere audit specifici e certificare la loro sicurezza, per poi effettuare la delivery da un repository privato.
- Tenersi informati sulle nuove vulnerabilità – Se si fa affidamento su un’immagine o codice sorgente, è necessario iscriversi ai canali dedicati alla sicurezza dei container che comunicano le potenziali vulnerabilità. Dopo tutto, il sapere rappresenta sempre l’arma più potente per vincere ogni battaglia.
* Lori MacVittie è Principal Technical Evangelist di F5 Networks