Implementare la metodologia DevSecOps garantisce applicazioni più sicure e robuste. Riuscire a farlo con successo, però, è il risultato di un percorso graduale, composto da piccoli passi attraverso cui l’importanza della sicurezza viene prima spiegata agli sviluppatori e poi diffusa in tutta l’organizzazione.
Molte aziende hanno un ampio team di sviluppatori e mirano a implementare il metodo DevSecOps per risolvere i problemi di sicurezza che riscontrano nei loro applicativi ma temono le ripercussioni che ciò può avere nello svolgimento del lavoro quotidiano.
Attraverso un approccio pratico e un affiancamento personalizzato, Sorint.lab costruisce, insieme al cliente, un percorso di avvicinamento al DevSecOps per disporre delle strategie migliori, che coinvolgono workshop e formazione, per avvicinare gli sviluppatori e le figure addette alla sicurezza informatica per creare, infine, quell’alchimia operativa necessaria alla metabolizzazione dei pilastri del DevSecOps.
Senza DevSecOps le applicazioni sono meno sicure
Nessuna realtà aziendale è esente da problemi di sicurezza. In alcuni casi, un’applicazione sviluppata internamente può essere vulnerabile, mettendo a rischio sia l’azienda sia i suoi clienti. L’obiettivo è sempre quello di realizzare applicazioni più sicure; ma in assenza del metodo DevSecOps, quando si sviluppa un nuovo applicativo è più facile riscontrare delle vulnerabilità, anche di livello critico, che spesso sono figlie di una mancanza di visione complessiva sulla sicurezza a monte del progetto, cioè in fase di progettazione.
Come implementare DevSecOps: i due passi
È importante considerare che l’implementazione di DevSecOps non è, in realtà, un progetto che ha un inizio e una fine, ma è un processo: significa rielaborare l’organizzazione del lavoro di sviluppo affinché introduca nuovi paradigmi e nuove figure riguardanti la sicurezza e che tutto ciò è in continua evoluzione.
Sono tre le fasi che prevede Sorint.lab per avvicinare le aziende al DevSecOps.
L’indispensabile formazione ai dipendenti
Il primo passo è l’organizzazione di workshop dedicati agli sviluppatori, che possono essere sia specifici, per esempio riguardanti un determinato linguaggio di programmazione, sia generici per i nuovi assunti o per quelle figure aziendali che non hanno un livello di seniority alto.
Aumentare la consapevolezza della sicurezza in maniera pratica è essenziale: i workshop devono lasciare alla persona uno o più strumenti, introdotti a livello teorico, con cui poter fare pratica per alcune ore alla settimana.
L’integrazione degli strumenti per il DevSecOps
Nei casi in cui è già prevista una pipeline di CI/CD
per rendere lo sviluppo rapido e automatizzato, è centrale focalizzarsi sugli strumenti di sviluppo usati ogni giorno, puntando sia ad aumentare la qualità dei tool sia all’integrazione, nella pipeline, di una serie di strumenti che sono poi il cuore del DevSecOps.
Attraverso tali strumenti, uno sviluppatore può venire immediatamente notificato di un bug introdotto mentre lavora a un progetto: in quel caso, la modifica non va in produzione e il programmatore riceve un feedback. A quel punto può scegliere di registrare un’eccezione oppure di lavorare al codice per correggere il problema.
Gli strumenti da implementare lavorano su diversi ambiti: esistono tool che controllano il codice, alla ricerca di schemi vulnerabili, mentre altri monitorano i software correlati di terze parti.
Le organizzazioni devono puntare a mettere in sicurezza i software e le dipendenze usate, prima di scoprire, per esempio, che quelle dipendenze non sono state aggiornate o sono state trovate vulnerabili, rendendo così vulnerabile di fatto l’azienda stessa.
L’importanza del threat model
Una terza fase dell’introduzione del DevSecOps riguarda la fase di design di un applicativo. All’inizio di un progetto è importante che venga eseguita una valutazione del rischio (risk assessment) prima di mettere mano al codice. Anche in questa fase è imperativo che sia coinvolta la voce della security, per conoscere le possibilità attraverso cui un dato pezzo di codice può esporre l’azienda a dei rischi: si tratta del cosiddetto threat model.
È fondamentale per:
- confrontarsi sui potenziali rischi
- conoscere le mitigazioni appropriate e quali misure implementare
- introdurre le opportune verifiche per misurare il livello di successo delle misure attuate in fase di mitigazione.
Oggi un software non può prescindere da un threat model.
Le metriche del DevSecOps
Infine, poiché il DevSecOps è un approccio che viene introdotto gradualmente nell’azienda, è altrettanto importante impiegare delle metriche che possano permettere all’organizzazione di valutarsi indipendentemente e di comprendere, in sostanza, quale sia la situazione esistente e quale sia il prossimo obiettivo.
Non ci sono delle metriche assolute che valgono per ogni azienda allo stesso modo. Un esempio di metrica applicabile riguarda il numero di interventi di manutenzione correttiva eseguiti in un dato periodo a seguito dell’introduzione del DevSecOps vs il numero di interventi prima dell’introduzione. Oppure la disponibilità – o al contrario la carenza – di una specifica competenza rispetto a una specifica tematica di sicurezza informatica, che può indicare, quindi, una scarsa capacità dell’organizzazione di rispondere a situazioni di un certo tipo.
Sorint.lab ha applicato essa stessa i dettami del metodo DevSecOps: li conosce direttamente e quindi può affiancare le imprese per integrare gradualmente questa metodologia affinché l’intero team di sviluppatori sia al corrente di come lavorare e gli esperti di sicurezza vengano coinvolti nei progetti fin dalla fase di design.
Il DevSecOps non è un progetto come gli altri. Sorint.lab aiuta i suoi clienti nella configurazione delle fasi necessarie e a misurare l’impatto che stanno avendo nell’operatività per rafforzare i processi di sviluppo e ridurre le vulnerabilità.