Nella programmazione si chiama Continous Delivery quella modalità di lavoro secondo la quale gli sviluppatori di codice rilasciano aggiornamenti e variazioni del software anche più volte al giorno.
Questa modalità a rilascio continuo, secondo gli esperti dovrebbe presupporre l’utilizzo di un gateway destinato alla sicurezza dei dati, anzi degli open data.
Uscendo di continuo dalla società che sviluppa il software, infatti, la governance deve presupporre misure di sicurezza particolari.
In alternativa, alcuni esperti suggeriscono di impostare una gestione del Continous Delivery che preveda un sistema di trasmissione dei dati diverso e dedicato. Come devono comportarsi, dunque, le aziende e le software house in particolare?
Continuous Delivery: perché mettere in sicurezza la governance
In un modello a rilascio continuo del codice i tempi necessari per correggere i bug, le vulnerabilità o per migliorare i servizi delle applicazioni software sono di norma molto brevi. Infatti un nuovo codice che può contenere anche una sola piccola variazione rispetto al programma installato, viene rilasciato non appena è pronto, senza aspettare altri cambiamenti che gli sviluppatori possono andare a creare a ruota.
Il problema principale, dal punto di vista della sicurezza, deriva dal fatto che molte implementazioni nel continous delivery si concentrano esclusivamente sui test e sul rilascio di nuove caratteristiche e funzionalità. Questa modalità di aggiornamento super rapido del software molto spesso però si traduce in una scarsa attenzione alla sicurezza del nuovo codice. Il feedback richiesto agli utenti sulle novità presenti nell’ultima release rilasciata, infatti, è fortemente sbilanciato verso l’usabilità e la funzionalità del software, piuttosto che sulla sua sicurezza. Nonostante questo, non c’è alcun motivo per cui in modello a rilascio continuo del codice dovrebbe essere abbandonato per problemi di sicurezza: la premessa è che tutte le politiche di salvaguardia dei dati e di sicurezza siano integrate nel processo globale di rilascio di tale codice.
Continuous Delivery: come mettere in sicurezza la governance
L’idea base di un modello di rilascio continuo del codice prevede la creazione di unità automatizzate che eseguono test di integrità per eliminare eventuali difetti che possono verificarsi nel corso della programmazione. Questa funzione garantisce lo sviluppo costante di un software, ma solo se il team di sviluppo lavora a stretto contatto con quello deputato alla sicurezza. L’erogazione continua del codice, realizzata con processi di sicurezza-accettazione, migliora la sicurezza e la capacità del software di far fronte in maniera positiva ad eventi che minano la sua sicurezza, in quanto vengono integrati controlli di sicurezza continui nelle fasi cruciali dello sviluppo e nel processo di distribuzione. Lo sviluppo di un software tradizionale, di norma, prevede un gran numero di modifiche al codice che vengono rilasciate tutte in una volta sola. Questo rende più difficile la revisione: se un test fallisce, infatti, non è sempre facile capire quale particolare cambiamento del codice abbia causato il problema. La valutazione del codice nel continous delivery rende più semplice identificare i problemi, e si ha così a disposizione sempre l’ultimo codice privo (quasi sempre) di bug o vulnerabilità.
È molto importante anche stabilire regole di codifica sicura che vietino l’uso di codice e funzioni pericolose in arrivo da librerie e componenti di terze parti non approvati dal team di sicurezza, mentre tutti gli errori e le eccezioni che si dovessero verificare dovrebbero essere valutati e risolte attentamente così come il resto delle funzioni critiche che normalmente emergono durante un aggiornamento del codice.
L’importanza dei test di sicurezza nel continuous delivery
Non appena viene sviluppato del nuovo codice, questo deve essere sottoposto il più velocemente possibile a revisioni automatiche di sicurezza, per verificare che non siano state accidentalmente introdotte vulnerabilità note.
Questo tipo di test sono particolarmente adatti ad essere automatizzati, ma è altresì importante aggiungere ulteriori test basati su scenari identificati e casi di abuso dei dati finalizzati a identificare comportamenti insoliti. Anche in questo caso i test possono essere automatizzati utilizzando strumenti di automazione presenti nei browser che soddisfino le richieste di accettazione-test.
Questa sequenza di prove è essenzialmente lo stesso test che viene eseguito per l’accettazione automatizzata. Oltre a verificare se le caratteristiche di sicurezza – come log in e log out – funzionino come previsto, analizza anche se un comportamento anomalo possa portare a un risultato inatteso. La chiave è quella di creare test delle applicazioni che includano anche la possibilità di poter subire un attacco, in modo da rendere maggiormente consapevoli gli sviluppatori sui tipi di minacce che devono affrontare.
È sicuramente importante concentrarsi e velocizzare le risoluzione dei problemi riscontrati durante i test di sicurezza, ma il team di sicurezza dovrebbe avere la capacità di bloccare il rilascio se i risultati dei test indicano la presenza di un rischio inaccettabile.
