Il DevSecOps ha cambiato le priorità e ha reindirizzato le strategie delle organizzazioni verso un approccio che non solo valorizzi la sicurezza informatica, ma la renda un pilastro fondante dello sviluppo dei nuovi applicativi. Le aziende – e ancora di più i clienti delle aziende – si sono accorte che non è più accettabile che i software possano avere vulnerabilità capaci di far entrare un attaccante all’interno dei sistemi e di mettere in pericolo i dati, cioè il tesoro più prezioso del patrimonio aziendale.
D’altronde, i valori in gioco sono molto alti. Secondo l’annuale indagine Global Digital Trust Insights di PwC, basata su interviste a 3.500 dirigenti senior in 65 Paesi, il 27% delle aziende nel mondo ha sofferto un data breach che è costato fra 1 e 20 milioni di dollari negli ultimi tre anni. Eppure, meno del 40% dei dirigenti intervistati ritiene che l’azienda abbia mitigato pienamente le falle di sicurezza e l’esposizione di varie aree aziendali, dall’implementazione del lavoro da remoto all’adozione accelerata del cloud. Poiché si tratta di alcuni dei punti fermi dell’evoluzione tecnologica e aziendale, non riuscire a renderli sicuri rischia di diventare un problema sempre più vasto.
Puntare su sistemi migliori, quindi, non è una semplice scelta: è imperativo; è fondamentale per riuscire a produrre software robusti, sicuri e performanti. Il viaggio verso DevSecOps deve diventare uno step del percorso di trasformazione digitale di tutte le imprese che sviluppano applicativi.
Perché serve DevSecOps: i limiti dell’approccio tradizionale
Il tradizionale approccio alla security per anni è servito al suo scopo. In un mondo però dove gli attacchi informatici sono sempre di più, le organizzazioni hanno bisogno di adattare le loro strategie per rafforzare la security introducendo nuovi elementi di protezione. A proposito della quantità di attacchi, basti pensare che secondo il rapporto Clusit del 2021 sono aumentati del 24% su base annua gli attacchi gravi e che il 74% degli attacchi informatici ha effetti molto critici o devastanti per l’azienda. Nel 59% dei casi analizzati, gli attaccanti sfruttano vulnerabilità note.
È chiaro che un approccio nuovo è necessario. Dev’essere un metodo agile e che allo stesso tempo abbracci il paradigma “secure by design”: gli applicativi devono essere sicuri dalle fondamenta; la sicurezza non può più aggiunta dopo la scrittura del codice. Quando la sicurezza non viene considerata fin da subito come una priorità, i rischi che provengono dalla fase di progettazione non potranno mai davvero essere azzerati: il software non sarà mai davvero sicuro. Correggere un bug generato da un problema di design o di architettura, infatti, prevede la riscrittura del codice: non un’operazione veloce né semplice da attuare.
La metodologia DevSecOps nasce proprio per rispondere all’esigenza, come visto sempre più impellente, di allineare le esigenze degli sviluppatori e quelle dei team di sicurezza e di far collaborare i due reparti fin da subito. Il risultato finale prevede una forte riduzione delle vulnerabilità e ottimizzazione delle performance.
Arrivare a tale risultato, però, non è scontato: il journey per arrivare all’implementazione del DevSecOps deve superare alcune sfide.
Passare a DevSecOps: il cambio di mentalità
La prima sfida da superare prevede un deciso cambio di mentalità.
Per anni, la security è stata percepita – e in tanti casi è ancora così – come un elemento bloccante, anziché come un fattore che potesse migliorare la qualità del software e, in definitiva, la soddisfazione finale del cliente. Ciò perché l’integrazione dei modelli di security nei sistemi agili, che devono essere rapidi e rispondere rapidamente a cambiamenti durante il ciclo di vita di un progetto e sono sempre più frequenti, può sembrare controproducente.
La realtà è molto diversa: le organizzazioni possono raggiungere entrambi gli obiettivi – essere veloci e sicuri – senza far perdere tempo agli sviluppatori integrando la sicurezza nel modo meno invadente possibile.
Uno dei modi in cui le organizzazioni possono superare questa sfida è attraverso l’integrazione di strumenti digitali che automatizzino i controlli d sicurezza sul codice, così da avere un feedback immediato ed evitare che un bug o una vulnerabilità arrivi fino alla fase di produzione. Inoltre, questo tipo di sistemi può essere personalizzato e calibrato in modo che gli alert siano precisi e che non interrompano il lavoro dello sviluppatore quando non serve.
Un ulteriore fattore che accelera l’integrazione di modelli DevSecOps è l’inclusione di una o più figure esperte dell’ambito security che conoscano i nuovi strumenti e sappiano come configurarli, avendo un contesto dell’applicazione che l’azienda sta sviluppando. La condivisione delle informazioni, se adeguatamente strutturata, renderà più robusta l’applicazione finale.
Formazione e nuove competenze
La componente umana è alla base del successo o del fallimento di qualunque progetto. Per questo motivo, è centrale che le organizzazioni superino la barriera culturale che separa uno sviluppatore – che ha un atteggiamento orientato alle performance – da un esperto di security, le cui capacità e mentalità sono rivolte invece a scoprire modi di “rompere” un applicativo.
Affinché il journey verso il DevSecOps abbia successo è necessario che questi due approcci lavorino insieme.
Un risultato che si raggiunge, innanzitutto, attraverso momenti di allineamento puntuale e attento: i team di sviluppo e quello di security devono confrontarsi il più possibile ed effettuare un lavoro di threat modeling per valutare i possibili rischi, come mitigarli e quali misure implementare per verificare che le mitigazioni stiano funzionando. L’allineamento servirà agli sviluppatori per comprendere come la scrittura del codice può aprire nuove falle e, viceversa, il team di sicurezza conoscerà l’applicazione e il contesto.
Per avvicinare gli sviluppatori alle tematiche della sicurezza, le aziende devono anche prevedere l’organizzazione di programmi di training e workshop dedicati a connettere gli sviluppatori al metodo DevSecOps. Ciò può avvenire anche attraverso corsi verticali su singoli linguaggi di programmazione, per esempio, oppure sull’ambito specifico, come il backend.
Nell’ottica di inquadrare lo sviluppo degli applicativi nel contesto del DevSecOps, un’attenta considerazione va fatta anche in fase di recruiting: una fase di screening delle competenze sul tema, infatti, servirà a comprendere quali tematiche andranno approfondite.
I benefici di passare a DevSecOps
Interpretare il DevSecOps parte dalla comprensione che la sicurezza deve diventare patrimonio informativo condiviso in azienda: il valore della sicurezza, in altre parole, non deve più essere solo del reparto del team di sicurezza, ma dev’essere compreso pienamente a tutti i livelli, a partire dagli sviluppatori.
Il viaggio verso DevSecOps implica una serie di step evolutivi e graduali: il DevSecOps non è un progetto che ha un inizio e una fine, bensì una metodologia che va implementata, manutenuta ed evoluta. Sorint.lab ha trasformato questa idea in un progetto aziendale chiaro, che punta a rendere le imprese più consapevoli dei rischi che corrono e come possano, attraverso il metodo DevSecOps, migliorare sotto punti di vista trasversali.
I benefici sono evidenti: le aziende possono vantare software più sicuri e riuscire a prevenire problemi di sicurezza che, nei casi peggiori, possono anche significare costi significativi in termini di mitigazione dell’attacco e poi di correzione dei bug. Ottimizzare i costi e le performance può quindi condurre le organizzazioni verso un traguardo di piena integrazione della cybersecurity nel ciclo di sviluppo del software.
