DevOps, senza la sicurezza, non basta più; ci vuole DevSecOps

Da DevOps a DevSecOps

Ambienti eterogenei, enterprise o no, che necessitano di un approccio strutturato allo sviluppo di applicazioni, non possono fare a meno di una metodologia come DevOps. La comparsa dei primi DevOps Engineer all’interno delle aziende è avvenuta circa dieci anni fa e di acqua sotto i ponti ne è passata parecchia.

La priorità legata al time-to-market ha sempre surclassato qualsiasi altro aspetto e ciò è sempre accaduto a discapito anche della sicurezza. Le metodologie di sviluppo software, alcune con maggior successo ed altre meno, si prefiggono l’obiettivo di migliorare, quantomeno agevolare, tutte le fasi che compongono la vita di un software; continuando su questa similitudine, si potrebbe caratterizzare la sicurezza come la fase anziana del ciclo di vita di uno sviluppo.

La morale è che, fin quando le cose sono semplici, può certamente andar bene continuare a posticipare questo aspetto; ma oramai nessuno sviluppo è semplice. Immaginare lo sviluppo di un applicativo come qualcosa di semplice, suona un po’, oltre che errato nella quasi totalità dei casi, anacronistico. E visto che tutte le metodologie nate in questi anni nascono dal seme del buonsenso, anche DevOps si è potenziata introducendo un’importante nuova pratica migliorativa: DevSecOps.

Introdurre la metodologia DevSecOps in azienda

Riorganizzare un flusso di lavoro, di per sé, non è mai facile. Il primo passo è senz’altro coinvolgere figure chiave nella riorganizzazione dell’interno del ciclo di sviluppo. Queste figure altamente specializzate (DevSecOps engineer) applicheranno nuove logiche e creeranno automatismi ad alto valore aggiunto. Il training dei team coinvolti, in questa fase di cambiamento, risulta essere più che necessario; tutta la filiera sarà coinvolta.

Il dipartimento QA dovrà essere rimodulato in questo nuovo paradigma. Ciò che ieri era visto come un’entità separata, domani si dovrà riorganizzare per essere un ulteriore tassello della nostra pipeline. La sfida più ardua rimane comunque far comprendere al management meno lungimirante che il costo generato dall’adozione di questa tecnologia è la chiave per una importante riduzione dei costi. In ottica di ritorno dell’investimento (ROI), la riduzione del rischio introdotta dalla metodologia sarà il suo valore aggiunto.

Sicurezza come fondamento

Un ambiente di lavoro caratterizzato da un approccio cloud-native, il minimo sindacale per realizzare prodotti scalabili e velocemente deliverable, necessita sempre più di un’attenzione maggiore al tema sicurezza.

Lo sviluppo cloud-native ha reso interdipendenti applicativi ed infrastruttura, generando di fatto una indispensabile sinergia che, di contro, aumenta le complessità generale.

In questa ottica, la sicurezza non deve dipendere dai singoli o affrontata separatamente, ma piuttosto fare parte integrante del ciclo di sviluppo.

L’integrazione deve avvenire direttamente nelle pipeline, con l’introduzione di tool e processi che verificano lo stato della sicurezza dell’applicativo in ogni fase di rilascio.

L’utilizzo di un approccio DevSecOps riduce notevolmente il rischio di vulnerabilità e regressioni dovute a fix di sicurezza applicati a posteriori e migliora apprezzabilmente l’intero ambiente di lavoro. Introdurre la sicurezza come fondamento porta da subito a sensibilizzare tutte le parti coinvolte ed i benefici sono tangibili, soprattutto dal committente.

Sicurezza come automatismo

Da un punto di vista puramente pratico, l’aspetto fondamentale che caratterizza un approccio DevSecOps è l’automazione.

L’analisi del codice sarà eseguita da un test costante, automatizzato nella nostra pipeline grazie all’ausilio di tool specifici. Static e Dynamic Application Security Test (DAST/SAST) consentiranno di prevenire con estrema efficacia le problematiche che potrebbero emergere in produzione.

In una fase di prerilascio andrebbero inseriti automatismi di vulnerability assessment e penetration test. Una volta effettuato il rilascio, la sicurezza non deve essere mai trascurata. Andrebbero integrati software specifici per Runtime Auto Self Protection (RASP) ed Interactive Application Security Testing (IAST), per essere immediatamente pronti ad intervenire. Non dimentichiamoci che il costo generato da una issue in ambiente produttivo è molto superiore al costo generato per individuarla in fase di test.

Manutenzione della sicurezza

Gli aspetti legati alla sicurezza non possono essere tutti automatizzati. È necessario mantenere sempre alta la soglia dell’attenzione e del monitoraggio, non solo sulle delivery effettuate ma su tutta la pipeline. L’intera architettura deve sempre essere conforme ad un alto livello di sicurezza; una singola falla potrebbe compromettere tutta la filiera. Inoltre, una costante attività di threat investigation completa le funzioni di monitoraggio e rende più dinamica ed incisiva la manutenzione della sicurezza.

La verifica delle dipendenze che vivono all’interno del nostro sviluppo applicativo è uno dei punti più trascurati. Il dependency check deve essere una costante.

Il pericolo: data breach

L’ambito di competenze ed esigenze esposto finora è un mondo estremamente vasto. È necessario dotarsi di DevSecOps qualificati e, soprattutto, che il management abbia ben chiaro il costo che una falla di sicurezza potrebbe generare.

Qualche numero: nel 2019 è stata messa in vendita una lista contenente 2,7 miliardi di account e sempre nello stesso anno è stato registrato un aumento di violazioni dei dati del 54% rispetto al 2018. Le password violate nel 2019 sono state più di 500 milioni. Tutto ciò è direttamente proporzionale all’aumento della complessità nell’IT.

La conclusione è che il mercato intorno alla metodologia DevSecOps arriverà a 6,5 miliardi di dollari entro il 2025. Non facciamoci trovare impreparati.

Immagine di apertura di Piron Guillaume su Unsplash.