A cura di Gabriel Agatiello, Senior Security Sales Executive, Dynatrace
Oggi, le organizzazioni devono affrontare molte pressioni per fornire servizi nuovi e innovativi. Per tenere il passo, i team DevOps e di sicurezza si stanno rivolgendo sempre di più al codice open source per avvantaggiarsi. Le librerie open source forniscono visibilità sul codice base, che consente agli sviluppatori di sviluppare sul codice esistente mentre creano nuove applicazioni e funzionalità digitali. Una ricerca di Red Hat ha rilevato che il 90% delle organizzazioni utilizza l’open source e il 54% lo utilizza per lo sviluppo di applicazioni. Tuttavia, l’esplosione di tecnologie, piattaforme e librerie di codice open source ha introdotto una nuova complessità nel mantenimento della sicurezza, poiché più collaboratori esterni, repository e servizi Web sono coinvolti nel processo di sviluppo.
GitHub ha calcolato oltre 56 milioni di sviluppatori che utilizzano la sua piattaforma di sviluppo e rilevato che oltre 1,9 miliardi di contributi open source sono stati aggiunti solo nel 2020. Oltre all’ascesa delle architetture cloud-native e delle piattaforme di orchestrazione dinamica come Kubernetes, è chiaro che gli stack tecnologici sono diventati più complicati che mai.
Dal punto di vista della sicurezza, la sfida è che con una maggiore complessità derivano più vulnerabilità. I già sovraccarichi team DevOps e di sicurezza devono spesso scegliere tra velocità e sicurezza, poiché la maggior parte del loro tempo è prosciugato dagli alert di potenziali vulnerabilità. È sempre più difficile per questi team capire quali vulnerabilità sono più critiche e dovrebbero avere la priorità, il che rallenta il time-to-market di nuove innovazioni.
Aprire la porta a nuovi problemi
La sfida principale con il codice open source deriva dalla sua principale caratteristica: la sua natura pubblica liberamente disponibile. Chiunque può accedere al codice, compresi i malintenzionati.
Tradizionalmente, la comunità di sviluppatori corregge le vulnerabilità e le carica nei forum o nel National Vulnerability Database, in modo che altri possano aggiornare le applicazioni che utilizzano il codice. La crescente adozione del cloud dinamico e degli ambienti Kubernetes ha reso le applicazioni Web altamente distribuite e complesse; quindi, è sempre più difficile individuare il codice open source e determinare quanto sia aggiornato. I team DevOps e di sicurezza non hanno il tempo di esaminare il codice e correggere ogni potenziale vulnerabilità, il che rende le organizzazioni più vulnerabili agli attacchi.
Inoltre, l’enorme volume di codice open source in uso significa che questi team devono confrontarsi con una raffica costante di avvisi provenienti dalle soluzioni di sicurezza. La ricerca di Dynatrace indica che, in media, le organizzazioni devono reagire a 2.169 potenziali vulnerabilità ogni mese.
Ad aggravare il problema, gli approcci tradizionali alla gestione delle vulnerabilità si basano su processi manuali, per i quali i team DevOps semplicemente non hanno tempo. Devono essere concentrati sulla fornitura di nuovi servizi il più rapidamente possibile, il che ha portato più di due terzi (71%) dei CISO ad ammettere di non essere sempre completamente sicuri che il loro codice sia privo di vulnerabilità prima che entri in produzione.
Scegliete le vostre battaglie per vincere la guerra
Le aziende che utilizzano librerie di codice open source devono non solo determinare dove si trovano le vulnerabilità, ma anche dare la priorità a quali problemi dovrebbero essere risolti per primi. Trovare un modo per farlo è difficile perché la gravità delle vulnerabilità varia notevolmente da un ambiente all’altro. Una falla nella libreria di codice che potrebbe essere sfruttata con effetti catastrofici all’interno di un’organizzazione potrebbe non essere un problema per un’altra.
Il contesto è fondamentale per comprendere quali vulnerabilità hanno il maggiore impatto potenziale sull’organizzazione e devono pertanto essere affrontate immediatamente. Anche se emerge una vulnerabilità in un’applicazione critica, questa potrebbe non avere accesso a dati sensibili e quindi non richiederebbe un’azione urgente. D’altra parte, una vulnerabilità in un’applicazione apparentemente minore che potrebbe essere utilizzata come backdoor per un database contenente dati personali altamente sensibili richiede un’attenzione immediata.
Con così tanti avvisi e così poco tempo, i team DevOps e di sicurezza hanno bisogno di automazione e intelligenza artificiale per affrontare le vulnerabilità. Per sfruttare queste capacità in modo efficace, le organizzazioni devono garantire che l’AI possa attingere da un’unica fonte di dati che offra l’osservabilità nell’intero ambiente cloud in tempo reale, comprese tutte le applicazioni e l’infrastruttura, nonché un database di vulnerabilità. Questo fornisce agli avvisi basati sull’intelligenza artificiale il contesto necessario per dare la priorità alle vulnerabilità delle librerie open source, identificando dove si trovano e qual è il loro potenziale impatto. Con l’AI, i team DevOps e di sicurezza possono anche ottenere le risposte precise di cui hanno bisogno per risolvere queste vulnerabilità. Ciò riduce quindi il tempo dei team dedicato agli sforzi manuali e libera tempo per l’innovazione.
Tenere il passo in sicurezza
Innovazione il cui ritmo non farà che accelerare e il codice open source continuerà a svolgere un ruolo chiave per i team responsabili della fornitura di nuovi servizi. Tuttavia, per evitare che debolezze della sicurezza potenzialmente catastrofiche sfuggano alla rete, le organizzazioni devono adottare un approccio automatizzato alla gestione delle vulnerabilità. Questo consentirà ai team DevOps e di sicurezza non solo di identificare le minacce, ma anche di collaborare per comprenderne il contesto, il potenziale impatto e la priorità. Con questo approccio DevSecOps, i team non devono più sacrificare la sicurezza per aumentare la velocità di sviluppo e possono essere certi che le vulnerabilità ad alta priorità verranno affrontate prima che abbiano un impatto. In definitiva, ciò riduce il rischio organizzativo mentre i team possono innovare e rilasciare applicazioni più rapidamente.
