DevSecOps è un termine che si è recentemente aggiunto al ben più celebre DevOps nel variegato vocabolario dell’IT, facendo facilmente intuire come quel “Sec” in più abbia in qualche modo a che fare con la sicurezza informatica. A fronte delle crescenti minacce provenienti dalla rete e degli ormai quotidiani casi di cronaca che ci raccontano di organizzazioni puntualmente martoriate dall’attività cybercriminale con ransomware, data breach e frodi di varia natura, sviluppare applicazioni nativamente sicure è un’ipotesi che ormai tutte le aziende dovrebbero prendere in seria considerazione.

Cos’è DevSecOps

Il DevSecOps, acronimo di Development Security Operations, è una metodologia finalizzata all’integrazione nativa della sicurezza informatica nelle applicazioni, a partire dalle fasi di sviluppo, proseguendo lungo il loro intero ciclo di vita. Si pone in linea di continuità rispetto a DevOps, condividendone gli obiettivi di base, ma il suo focus è prevalentemente orientato a garantire una sicurezza “by design” del software.

Il DevSecOps si avvale solitamente di strumenti e processi decisamente evoluti, basati su tecniche di intelligenza artificiale, in grado di automatizzare gli aspetti relativi alla sicurezza. DevSecOps rende il design dell’applicazione nativamente più sicuro, limitando a priori l’eventualità di subire un attacco informatico attraverso le sue vulnerabilità e facilitando l’intervento di messa in sicurezza anche qualora dovesse accadere.

L’obiettivo del DevSecOps è quello di creare software in maniera più rapida e sicura, facilitando i processi di sviluppo, gestione e manutenzione. Ciò avviene grazie ad una metodologia capace di automatizzare il ciclo di CI/CD (Continous Integration / Continous Deploy), come del resto già avviene da diversi anni con DevOps.

Un workflow DevSecOps può ad esempio essere caratterizzato dalle seguenti fasi:

  • Sviluppo (test e deploy) di una versione del componente applicativo
  • Analisi dei cambiamenti effettuati con una logica di vulnerability assessment, finalizzata a identificare possibili falle di sicurezza presenti nel codice dell’applicazione, oltre che al rilevamento dei bug generici
  • Testing dell’applicazione con procedure automatizzate in grado di verificare sia il front-end che il back-end, oltre a tutte le integrazioni
  • Deploy in produzione con elevata attenzione nei confronti delle vulnerabilità zero day, utilizzando pertanto anche strumenti di monitoraggio specifici per gli aspetti di sicurezza, oltre a quelli comunemente utilizzati in ambito DevOps.

I vantaggi

L’impiego della metodologia DevSecOps consente di rilasciare software migliore in maniera più veloce, identificando nativamente le possibili vulnerabilità che potrebbero dare luogo a seri problemi in seguito ai deploy pianificati lungo la roadmap dell’applicazione. I vantaggi dell’adozione di DevSecOps corrispondono pertanto alle caratteristiche fondamentali su cui si basa il suo programma, a patto di raggiungere determinati obiettivi.

Totale controllo e security awareness

Se implementato in modo corretto, l’appoccio DevSecOps favorisce la crescita di un senso di responsabilità collettiva per tutti i soggetti coinvolti nello sviluppo e nelle operazioni. La maturazione di una adeguata security awareness costituisce infatti una base culturale ed organizzativa da cui non si può prescindere quando si intende sviluppare applicazioni nativamente sicure.

Elevata automatizzazione

Nell’ambito dei cicli CI/CD è indispensabile predisporre un elevato livello di automazione delle procedure, questione che gli strumenti più diffusi consentono ormai di implementare in maniera piuttosto agevole. Analogamente a quanto avviene nei progetti basati su DevOps, i tool DevSecOps devono essere eseguiti con un’automazione totale, escludendo, se non in casi del tutto eccezionali, qualsiasi passaggio manuale, senza richiede modifiche di configurazioni e script personalizzati. L’automatizzazione consente soprattutto di evitare errori, dovuti ad esempio alla pigrizia o al timore del team di sviluppo di incorrere in criticità o rallentamenti procedurali che fanno passare la sicurezza come un onere in più di cui farsi carico, anziché di una qualità fondamentale del software.

Velocità

Analogamente a quanto avviene in DevOps, anche i tool DevSecOps devono garantire una risposta in tempo reale, o più precisamente in near real time, in quanto la velocità dei cicli CI/CD e la riduzione del time to market delle applicazioni costituiscono tuttora uno dei principali driver per l’adozione delle metodologie di sviluppo agili. Ottimizzare, entro tempistiche ragionevoli, anche i requisiti di sicurezza dell’applicazione costituisce un valore aggiunto fondamentale.

Accuratezza e qualità

Automatizzazione e velocità devono fare il paio con accuratezza e qualità, altrimenti i risultati del lavoro rischiano di essere vanificati da una user experience scadente, dovuta a funzioni sviluppate male o, nella peggiore delle ipotesi, instabili e piene di bug.

In termini di sicurezza, è ad esempio necessario limitare il fenomeno dei falsi positivi e dei falsi negativi, che rischiano di rallentare in maniera drammatica un’applicazione, generando alert di sicurezza che non avrebbero alcuna ragione di esistere, in quanto totalmente infondati.

Una corretta implementazione di DevSecOps prevede che I suoi tool sappiano eseguire test di sicurezza in grado di eliminare, o ridurre ai minimi termini, gli alert dovuti a falsi positivi e falsi negativi, soprattutto rilevando informazioni utili affinché il team di sviluppo possa porvi puntualmente rimedio.

Sicurezza nativa…

Nella letteratura di settore si parla spesso di “shift left” e “shift right”, identificando con il primo termine le valutazioni di sicurezza nelle prime fasi di sviluppo, appunto alla sinistra di una roadmap, mentre a destra ritroviamo le fasi orientate alla produzione. Se il principale merito di DevSecOps risiede nel porre l’attenzione sui temi relativi alla sicurezza dall’inizio del ciclo di vita dell’applicazione, i vantaggi più significativi si hanno quando questa si rivela effettivamente sicura in produzione, laddove è priva di qualsiasi nicchia protettiva.

Tale premessa risulta strategica ai fini di affermare, con buona certezza, che DevSecOps deve adottare tutti gli strumenti e le procedure necessarie per valutare la sicurezza in fase di produzione, per una serie di ragioni imprescindibili:

  • La stragrande maggioranza degli attacchi avviene quando il software è rilasciato in produzione
  • Le temute vulnerabilità zero day sono identificabili nell’ambiente di produzione
  • La scansione del codice sorgente durante le fasi di testing non è completa come quella di un’applicazione eseguita in produzione
  • In produzione molto spesso si utilizzano ambienti che non corrispondono del tutto a quelli impiegati durante le fasi di sviluppo, quindi è necessario considerare il monitoraggio della sicurezza ponendo estrema attenzione nel valutare tutte le condizioni possibili, tenendo sempre a mente che oltre a lavorare per scrivere un codice sicuro, qualsiasi attacco reale verrà eseguito quando il codice stesso viene eseguito in produzione.

… in cloud native

Le applicazioni basate su DevOps e DevSecOps vengono sviluppate su piattaforme cloud, utilizzando tecnologie come i container stateful, nel caso del PaaS in senso ampio, o stateless, nel caso delle architetture serverless, con tutte le possibili ibridazioni e i sistemi utilizzati per orchestrare questa complessità, come nel caso di kubernetes.

Gli strumenti utilizzati per monitorare gli aspetti di sicurezza durante lo sviluppo devono necessariamente garantire la loro efficienza lungo tutta la filiera, anche in ambienti ibridi e multicloud, altrimenti la loro utilità risulterebbe poco esaustiva.

Allo stesso modo, i tool DevSecOps devono fornire indicazioni e informazioni per tutte le applicazioni, a prescindere dal fatto che siano proprietarie, open source o personalizzate per rispondere a particolari esigenze funzionali.

Le criticità di adozione di DevSecOps

Se la risoluzione delle sfide in fase di sviluppo si traducono automaticamente in vantaggi per chi si avvale di un approccio DevSecOps allo sviluppo delle applicazioni, non possiamo trascurare alcuni aspetti critici, che possono manifestare delle vere e proprie barriere di adozione.

In primo luogo, i team di sviluppo potrebbero essere restii a modificare le loro abitudini, soprattutto quando implementano già DevOps, che fa sì che i singoli team possano lavorare in maniera del tutto indipendente tra loro, sfruttando anche a livello organizzativo il proverbiale disaccoppiamento dei microservizi.

DevSecOps “obbliga” necessariamente i team ad una certa collaborazione, almeno per quanto concerne gli aspetti relativi alla sicurezza. Tale condizione non può essere circoscritta all’attività dei project manager e di coloro che devono connettere le funzioni sviluppate in separata sede. Per certi versi, ciò introduce una maggior complessità da affrontare e gestire.

Il maggior dialogo tra le parti richiesto da DevSecOps rispetto a DevOps comporta l’impiego di tool interoperabili, ai fini di evitare dei silos da cui ben difficilmente potrebbe uscire un approccio collaborativo. Questo fattore aggiunge un elemento di complessità che proprio DevOps era di fatto riuscito a risolvere con successo, favorendo una visione agnostica in merito alle tecnologie utilizzate.

È pertanto necessario trovare una buona soluzione di compromesso dal punto di vista operativo. La sfida, in questo frangente, risiede nell’individuare strumenti adeguati e integrarli nella pipeline DevOps cercando di vincolare il meno possibile l’autonomia tecnologia dei singoli team di sviluppo.

Tradizionalmente, gli aspetti relativi alla sicurezza erano tipicamente concentrati a destra del ciclo di sviluppo, quando le parti funzionali dell’applicazione erano ormai complete e funzionanti. DevSecOps ha ribaltato ed in parte stravolto questa visione, obbligando ad una risposta anche sul piano puramente operativo, integrando la sicurezza lungo tutto il ciclo CI/CD.

Secondo tale prospettiva, risulterebbe poco logico prendere un progetto DevOps già strutturato e vedere la sicurezza come un qualcosa che cade miracolosamente dall’alto. La sicurezza deve diventare una componente nativa del ciclo di sviluppo. Tale aspetto, soprattutto quando si interviene in contesti laddove si adotta DevOps con profitto da lungo tempo, può comportare diverse criticità di adeguamento.

DevSecOps e DevOps

DevSecOps e DevOps sono metodologie che si basano sugli stessi presupposti di sviluppo agile. Le principali differenze consistono nel fatto che DevSecOps nasce proprio per collocare la sicurezza delle applicazioni il più possibile a sinistra (shift left) nella roadmap di sviluppo, ossia di integrarla nella maniera più nativa possibile.

Questo non vuol dire che il DevOps classicamente inteso, privilegiando la velocità di rilascio di un software, ignori gli aspetti relativi alla sicurezza, né tantomeno che non li consideri un fattore essenziale per il successo dell’applicazione. Semplicemente la sicurezza non viene necessariamente coinvolta nel design dell’applicazione, viene vista come un layer addizionale rispetto al consueto ciclo di sviluppo, demandandola ad un team di specialisti che prende l’applicazione finita e risolve a posteriori le eventuali vulnerabilità presenti.

DevSecOps non si limita invece ai principi e alle buone prassi in materia di sicurezza che ogni sviluppatore dovrebbe sempre seguire, ma prevede attività pratiche in grado di automatizzare i task relativi alla sicurezza, integrando lungo il workflow DevOps appositi strumenti di controllo e monitoraggio.

Alla luce di queste considerazioni, è opportuno sottolineare come DevSecOps costituisca un’estensione della cultura di sviluppo agile già introdotta da DevOps, coinvolgendo con decisione anche gli aspetti relativi alla sicurezza informatica.

Come adottare il modello DevSecOps

A fronte della crescente minaccia di sicurezza informatica e degli attacchi che ogni giorno si succedono nelle aziende, mettendo a rischio la loro continuità di business, le organizzazioni hanno intrapreso dei programmi di formazione per incrementare la security awareness dei propri dipendenti. Questo aspetto costituisce certamente un fattore favorevole quando si tratta di implementare una corretta igiene informatica: una base indispensabile, ma non sufficiente.

Alla cultura diffusa in fatto di sicurezza, dal punto di vista delle tecniche e delle procedure da adottare nel quotidiano, andrebbe infatti associato il concetto di responsabilità condivisa, favorendo la formazione di un mindset finalizzato a far comprendere, in primis ai C-level, che una realtà può definirsi sufficientemente sicura soltanto quando il suo anello più debole è sufficiente solido da garantire questa condizione. Parlando di sicurezza informatica, nessuno, enfatizzando il concetto, dovrebbe essere lasciato indietro. A fare le spese di alcune negligenze sarebbe l’intera organizzazione.

Questa premessa potrebbe apparire ad alcuni ovvia, persino scontata, ma all’atto pratico non lo è. Basterebbe avere un contatto quotidiano con le realtà aziendali, tech e non, per rendersi conto delle incoerenze e delle disomogeneità che emergono nelle varie linee di business.

Alcuni manager, fino a quando non vengono travolti dalla criticità di un incidente informatico, ignorano gli avvisi che ormai quotidianamente ci ammoniscono in merito al livello di tossicità presente nella rete, e ritengono di non costituire un bersaglio dei cybercriminali, con il più classico dei “figurati se capita o proprio a noi” o, ancor peggio: “se alla peggio dovessero attaccarci paghiamo, non c’è problema, siamo sufficientemente solidi…”.

Sottovalutare I rischi di un attacco informatico può essere oggi letale per il business di un’azienda, sia in termini di mancata erogazione dei servizi che per il fatto che i dati esfiltrati possono mettere a repentaglio anche la sicurezza dei partner e dei clienti.

Sul fronte delle applicazioni, è possibile fare molto per colmare qualsiasi gap in termini di sicurezza informatica, ma fino a quando tutti gli stakeholder coinvolti nel garantire la sicurezza informatica a livello generale, tali sforzi rischiano di rimanere vani. Questo non vale soltanto per le tech company, ma per qualsiasi azienda utilizzi la rete per rendere disponibili i propri servizi e i propri prodotti.

Il ruolo fondamentale dei progetti pilota

Le aziende che utilizzano già DevOps per sviluppare le proprie applicazioni, costituiscono un terreno d’azione privilegiato per introdurre il modello DevSecOps, in quanto ciò è possibile integrando alcuni metodi e tecniche senza stravolgere integralmente le pipeline.

Più in generale, è opportuno che i decisori aziendali comprendano come DevSecOps, riducendo i rischi derivanti dagli attacchi che vengono eseguiti sfruttando le vulnerabilità presenti nelle applicazioni, contribuisca in maniera sostanziale all’incremento della performance, evitando le interruzioni di servizio, oltre a favorire un corretto approccio nei confronti della sicurezza a 360 gradi.

Per conquistare la fiducia dei decisori aziendali è opportuno che i CISO e i responsabili della sicurezza favoriscano almeno l’avvio di un progetto pilota, capace di dimostrare in maniera tangibile i vantaggi di DevSecOps prima di implementarlo su larga scala. Tale iniziativa deve soprattutto essere mirata a raggiungere gli obiettivi di performance come si sarebbe fatto con DevOps, focalizzandosi sul valore aggiunto di un’applicazione più sicura per design, progettata inoltre per risultare coerente con le normative vigente in materia di trattamento e conservazione dei dati personali.

Non bisogna infatti mai dimenticare che il GDPR impone alle organizzazione di adottare tutte le iniziative tecniche e organizzative per garantire la sicurezza dei dati. In caso di data breach, chi non riesce a dimostrare questi adempimenti rischia davvero grosso in termini di sanzioni, soprattutto se opera nell’ambito dei servizi fondamentali e delle infrastrutture critiche. Grazie a DevSecOps tale adempimento può essere recepito in maniera nativa durante lo sviluppo dell’applicazione stessa.

Una volta implementati determinati accorgimenti e gli strumenti necessari per automatizzare la maggior parte delle procedure richieste, DevSecOps non risulta molto differente da DevOps in termini di impegno, a patto di disporre di un team con adeguate competenze.

Il team di sviluppo e i responsabili della sicurezza possono trarre reciprocamente vantaggio dal fatto di avere a disposizione applicazioni più sicure e facili da gestire lungo il loro intero ciclo di vita, anche per rimediare le vulnerabilità che potrebbero presentarsi.

Prevenire, grazie ad un atteggiamento proattivo, è decisamente meglio che curare, e soprattutto costa decisamente meno, sia in termini economici che nell’evitare i danni reputazionali che una perdita di dati o un downtime critico e prolungato rischierebbe di procurare all’aziende.

Best practice di implementazione di un programma DevSecOps

Nel corso del presente approfondimento abbiamo più volte ribadito come un approccio basato su DevSecOps favorisca l’integrazione della sicurezza lungo tutto il ciclo di vita dell’applicazione. Ovviamente, non basta pensarlo. Occorre dotare la pipeline di sviluppo di adeguati strumenti per proteggere i dati e l’applicazione stessa durante il ciclo CI/CD, automatizzando il più possibile tutte le procedure necessarie.

È pertanto opportuno considerare come le applicazioni basate sui microservizi ormai siano sviluppate con logiche cloud native in ambienti di esecuzione in PaaS (Platform-as-a-Service), come nel caso dei container e di tutte le tecnologie legate alla loro creazione, gestione e orchestrazione in ambienti ibridi e multicloud.

Per quanto riguarda la sicurezza degli ambienti di runtime e dei sistemi di dati utilizzati dai microservizi, è opportuno considerare le seguenti best practice, personalizzando gli accorgimenti in funzione degli obiettivi specifici:

  • Cercare di standardizzare il più possibile i container, automatizzando il controllo degli accessi e dei collegamenti non autorizzati
  • Utilizzare sistemi di directory per centralizzare il controllo delle identità e delle autorizzazioni degli utenti che provano ad accedere alle applicazioni
  • Cercare di mantenere il più possibile isolati i container e i dati da essi utilizzati, in quanto sono proprio questi, nella maggior parte dei casi, il principale bersaglio degli attaccanti. Qualora l’attacco andasse a segno, la violazione non dovrebbe mai propagarsi nelle aree critiche della rete, dove sono conservati i dati più sensibili
  • Utilizzare gateway API dotate di una adeguata protezione per aumentare la visibilità sulle autorizzazioni. Le API che godono di un basso livello di protezione risultano ovviamente esposte agli attacchi e contribuiscono ad aumentare la superficie d’attacco che i malintenzionati possono sfruttare per le loro attività
  • Utilizzare in maniera consapevole le funzioni di crittografia dei sistemi di orchestrazione dei container, in modo da limitare il più possibile le opportunità di violazione da parte degli attaccanti.

Per quanto riguarda il ciclo CI/CD, DevSecOps andrebbe implementato automatizzando le procedure, ai fini di ridurre i rischi di errore umano, tenendo necessariamente conto almeno dei seguenti fattori:

  • Automatizzare i test di sicurezza delle fasi di continous integration, eseguendo l’analisi delle build e la scansione delle immagini dei container ai fini di rilevare eventualità vulnerabilità
  • Automatizzare i test di convalida degli input e di verifica delle autenticazioni e delle autorizzazioni previste
  • Automatizzare l’applicazione degli aggiornamenti di sicurezza
  • Automatizzare la gestione della configurazione del sistema e di tutti i servizi dell’applicazione, in modo che risultino conformi ai criteri di sicurezza, prevedendo al tempo stesso le operazioni di auditing e di correzione automatica degli errori.