DevSecOps: dal security testing alla continuous security 

Si ringrazia Michelangelo Uberti, Marketing Manager Par-Tec, per questo articolo. 

Integrare la sicurezza nel ciclo di sviluppo è un’operazione complessa ma indispensabile, soprattutto ora che la complessità delle architetture cloud e la velocità del DevOps hanno reso impraticabile una gestione manuale condotta alla vecchia maniera. 

Per spiegare il DevSecOps è necessario tornare indietro di circa 20 anni. 

Dal Waterfall al DevOps passando per Agile 

In principio c’era il metodo Waterfall (“a cascata”), caratterizzato dalle sue fasi di sviluppo sequenziali – analisi dei requisiti e progettazione, implementazione, test e rilascio – che solo alla fine presentavano un risultato misurabile. 

Con il metodo Agile è stato introdotto il concetto di iterazione o sprint, un piccolo progetto della durata di qualche settimana che contiene tutte le fasi di sviluppo e che ha l’obiettivo di introdurre un progressivo incremento nelle funzionalità del software. 

Nel 2009 è arrivato il DevOps, una metodologia di sviluppo che punta alla collaborazione e all’integrazione tra sviluppatori (Dev) e addetti all’esercizio (Ops). Le sue caratteristiche più evidenti sono la rapidità con cui si passa da una fase all’altra e l’incredibile frequenza dei rilasci, anche e soprattutto grazie all’utilizzo intensivo dell’automazione. 

Il successo di questa metodologia è attribuibile anche alla diffusione dei Linux containers e alle Platform-as-a-Service (PaaS) basate su Kubernetes e tecnologie open source come Red Hat OpenShift Container Platform. 

Nei tre approcci citati, i test di sicurezza hanno spesso un ruolo marginale e sono concentrati nelle fasi finali del progetto. Molte aziende si limitano ad eseguire i classici vulnerability assessment e penetration test senza però concentrarsi sulla robustezza del codice. 

DevSecOps: non una semplice buzzword 

Gartner definisce il DevSecOps come “the integration of security into emerging agile IT and DevOps development as seamlessly and as transparently as possible”. Lavorare secondo questo modello significa integrare la sicurezza fin dall’inizio del ciclo di sviluppo, automatizzando tutte le attività di verifica per evitare che rallentino il flusso di lavoro DevOps. 

Nel DevSecOps i test di sicurezza vengono integrati all’interno di ogni fase di uno sprint, per questo si parla di Continuous Security oltre che di Continuous Integration (CI) e Continuous Delivery (CD). 

Le sfide della Continuous Security 

Nella transizione verso il DevOps, la revisione dei processi interni è prioritaria rispetto all’adozione di nuovi strumenti. Lo stesso avviene con il DevSecOps, dove il cambio di mentalità e la creazione di una cultura della sicurezza devono arrivare prima della selezione di strumenti e tecnologie. 

Vediamo alcuni dei cambiamenti richiesti: 

• Evoluzione da una mentalità “one-time scan” a un processo di security assurance continuo effettuato in ogni fase del ciclo di sviluppo. 
• Integrazione degli strumenti per il security testing con l’IDE di sviluppo e con gli strumenti usati per il CI/CD. 
• Gestione degli strumenti per la sicurezza ed esecuzione delle scansioni mediante API, senza la necessità di accedere all’interfaccia del prodotto o coinvolgere un analista di sicurezza. 

• Impostazione e condivisione dei requisiti di sicurezza validi per tutte le nuove applicazioni, possibilmente utilizzando strumenti per il threat-modeling. 
• Tracciamento automatico di tutte le anomalie sul sistema di bug-tracking già usato dagli sviluppatori. 

Il Security Champion 

Tutte le persone coinvolte nello sviluppo del software devono ricevere un’adeguata formazione sul secure coding che includa almeno una prima sessione in aula e degli aggiornamenti periodici focalizzati sulle più frequenti o importanti vulnerabilità presenti nel codice scritto dal team, così da correggere eventuali carenze tecniche. 

Nonostante tale formazione, gli sviluppatori dovranno essere supportati da una persona con competenze multidisciplinari che agisca come consulente esperto e riesca ad anticipare potenziali problemi già in fase di progettazione: il security champion. 

Si tratta di un membro esperto del team di sviluppo che ha mostrato una forte attitudine per la sicurezza delle applicazioni ed è stato selezionato per svolgere uno specifico percorso formativo. Egli rappresenta un fondamentale punto di contatto tra i team Dev, Ops e di sicurezza perché capace di fornire consigli mirati e aiutare gli sviluppatori ad applicare immediatamente dei correttivi anziché attendere l’esito dei test automatizzati. 

Il DevSecOps Maturity Model 

L’OWASP (Open Web Application Security Project) ha impostato il DevSecOps Maturity Model (DSOMM), un modello che definisce quattro diversi livelli di maturità che vanno dalla comprensione base delle pratiche di sicurezza fino alla loro applicazione su larga scala. 

I parametri analizzati nel modello sono numerosi e dettagliati. Tra i principali troviamo: 

• Static depth: copertura statica del codice all’interno della pipeline CI. 

• Dynamic depth: copertura dinamica del codice. 
• Intensity: frequenza di analisi del codice. 
• Consolidation: completezza del processo di remediation delle anomalie riscontrate. 

Per un’organizzazione che non applica tali pratiche, anche il solo raggiungimento del livello 1 può rivelarsi piuttosto impegnativo. Per il passaggio al livello 2 è possibile prevedere dai 6 ai 12 mesi di affinamento costante. Il tempo richiesto per passare ai livelli successivi dipende invece dall’organizzazione aziendale, dal numero di risorse e dalla tipologia e quantità di progetti gestiti. 

I controlli di sicurezza 

Nel DSOMM viene posto l’accento sulla copertura statica e dinamica del codice, due temi noti a chi già si occupava di quality assurance del software ben prima dell’avvento del DevSecOps. 

La copertura statica comprende una serie di analisi che includono: 

• Secrets scanning e secrets management, cioè la ricerca e la gestione di credenziali, chiavi private, token di accesso etc. che potrebbero essere sfruttate per violare i sistemi; 
• Software Composition Analysis (SCA) per la verifica delle dipendenze e il supporto al patching di tutte le componenti (anche open source) incluse nell’applicazione; 
• Static Application Security Testing (SAST), cioè la ricerca di vulnerabilità note (es. CVE) o errori di programmazione all’interno del codice sorgente. 

Mediante altri strumenti è possibile eseguire anche il Dynamic Application Security Testing (DAST), cioè la ricerca delle vulnerabilità di un’applicazione in esecuzione nonché di eventuali problemi di configurazione dell’ambiente all’interno del quale sta girando. 

In termini di offerta, la scena open source e il mercato offrono numerosissime opzioni. La priorità del reparto IT è impostare dei processi coerenti con il modello DSOMM e individuare le tecnologie più adatte al proprio team di sviluppo e alle proprie pipeline CI/CD, anche mediante il supporto di un system integrator specializzato come Par-Tec.