Lo sviluppo software non può più prescindere dall'applicazione delle migliori best practice di sicurezza. Ecco i consigli di un esperto per abbassare i rischi.
Autore: Redazione SecurityOpenLab
Il caso SolarWinds ha fatto emergere l'enorme problema dello sviluppo sicuro. Come avevamo rimarcato a suo tempo, in molte imprese i processi di sviluppo software sono tutt'altro che in linea con le esigenze contingenti di sicurezza informatica. La cronaca della cyber security parla troppo spesso di repository violati, malware che si diffonde via piattaforme come GitHub.
Il fatto è che lo sviluppo di codice deve troppo spesso far fronte all'esigenza di velocità, quando la sicurezza dovrebbe assumere un ruolo centrale. La soluzione c'è: il processo di sviluppo delle applicazioni deve passare dal modello DevOps a quello DevSecOps.
La differenza è sostanziale, come sottolinea Phil Richards, Chief Security Officer di Ivanti. "DevOps è una metodologia di progettazione agile del software che integra i team di sviluppo e quelli operativi, abbattendo i silos e aumentando la capacità di un’azienda di fornire applicazioni e servizi più velocemente rispetto ai modelli tradizionali, caratterizzati da processi laboriosi e molto lenti".
Con il passare del tempo, tuttavia, lo sviluppo agile del software consiste nel rilascio di soluzioni e applicazioni in tempi brevissimi, aumentando il rischio di commettere errori e introdurre vulnerabilità. Ecco perché le aziende che vogliono rafforzare la propria cybersecurity devono abbandonare la “cultura DevOps” a favore di quella incentrata sul modello DevSecOps.
DevSecOps assegna priorità assoluta alla sicurezza in tutto il processo di sviluppo, assicurando la presenza di una buona igiene informatica in tutte le diverse fasi. Questo cambiamento di approccio spinge le aziende ad adottare diversi percorsi per implementare codici e applicazioni sicure, attraverso vari strumenti e strategie.
Fra questi ci sono framework di sicurezza, formazione sul codice, security gate. A proposito dei framework di sicurezza, Richards consiglia alle aziende di prendere spunto dalle migliori soluzioni già implementate. Per esempio, The Building Security In Maturity Model (BSIMM) è uno strumento di benchmarking che elenca più di 120 best practice di sicurezza, permettendo ai team di sviluppo di prendere in considerazione queste misure quando progettano le proprie soluzioni.
C'è poi la necessità di informare gli sviluppatori sulle minacce esistenti e sulle best practice, mediante un processo di formazione continua che insegni loro a rilevare e correggere qualsiasi vulnerabilità nei propri sistemi. Sfruttando i security gate è poi possibile bloccare un rilascio, dando ai team di sicurezza il tempo necessario per determinare il livello di gravità dei bug e porvi rimedio.
I team di sicurezza entrano in gioco in tutto il processo di sviluppo, in base al principio che la sicurezza è una responsabilità condivisa. Questo implica che gli sviluppatori dovrebbero possedere strumenti in grado di rilevare le vulnerabilità mentre scrivono il codice, il team interno dovrebbe eseguire test di sicurezza statica e dinamica delle applicazioni e, inoltre, eventuali esperti esterni avrebbero il compito di svolgere i test black-box e gray-box, ricercando le vulnerabilità più complesse e nascoste.
Spesso i problemi di sicurezza sono dovuti all'impiego di librerie di terze parti, come Apache Struts. Richards le definisce sia una benedizione sia una maledizione. Da un lato le aziende possono trarre beneficio dal lavoro altrui, dall’altra sono necessari continui aggiornamenti e revisioni per mantenere una base di codice pulita, poiché è facile importare codice dannoso dai repository di codice.
Per uscire dall'impasse gli sviluppatori devono aggiornare regolarmente i toolkit per sincerarsi che i materiali di terze parti includano tutte le patch di sicurezza pubblicate.