Scritto da
L'approccio DevOps rende la fase di software delivery più veloce e affidabile. Tuttavia, secondo questa metodologia, le pratiche di sicurezza vengono lasciate alla fine del ciclo di sviluppo, esclusivamente in carico gli specialisti della security.
Capita che questo tipo di organizzazione crei dei colli di bottiglia e metta sotto pressione il reparto sicurezza. Inoltre, sebbene altri aspetti dell’applicazione vengano costantemente testati nella procedura di release, anche più di una volta, la sicurezza viene testata una sola volta: alla fine.
Cos'è DevSecOps?
DevSecOps, integrando la metodologia DevOps, inserisce la sicurezza in ogni fase del ciclo di vita del software, invece di confinarla alla fine del processo di delivery. Un cambiamento che promuove la cultura della "Security as Code" attraverso la collaborazione tra software engineers e security specialists.
DevSecOps integra la sicurezza in modo efficace e porta quindi i suoi frutti solo se introdotto a tutti i livelli dell’organizzazione, coinvolgendo persone con ruoli diversi (come suggerisce lo stesso termine DevSecOps), ma anche processi e nuove tecnologie. Secondo questa metodologia, d’altronde, tutte le parti coinvolte nel rilascio del software sono responsabili della sicurezza. Ecco che la sicurezza non è più un concetto sconosciuto e distante per i team, anzi: tutte le conoscenze sul tema sono condivise tra tutti i membri del gruppo di lavoro.
Come introdurre DevSecOps
Prima di vedere nel dettaglio il come, iniziamo dal perché.
I vantaggi della filosofia DevSecOps sono innumerevoli. Introdurre DevSecOps significa rendere i team più agili, avere una migliore capacità di risposta ai cambiamenti e identificare più rapidamente le vulnerabilità. Non da ultimo, DevSecOps genera un migliore lavoro di squadra, riducendo le tensioni tra team.
Sono tutti elementi che possono rivelarsi strategici per aziende nel contesto contemporaneo. Come avvicinarsi quindi all’approccio DevSecOps?
Vediamo quali sono i sei elementi da prendere in considerazione per introdurre correttamente DevSecOps.
LEGGI ANCHE:
- Consigli per introdurre la cultura DevOps in azienda senza friction
- Le best practice DevOps da adottare subito in azienda
1. ANALISI DEL CODICE
Partiamo con l’analisi del codice. DevSecOps porta la sicurezza in tutti i livelli dei processi di sviluppo del software, anziché lasciarla alla fine. Ogni volta che c'è una modifica alla codebase che deve essere committata sul repository, la modifica non viene accettata se i test di sicurezza non validano la modifica. In questo modo la sicurezza delle applicazioni diventa una priorità per gli sviluppatori, che hanno quindi la responsabilità di consegnare codice sicuro alla pipeline di sviluppo.
Ci sono vari tool sul mercato - molti dei quali open source - che si possono usare per scansionare il codice contro le vulnerabilità. Per nominarne alcuni: Anchore, Clair e Dagda, tool ancora più importanti quando si sviluppano applicazioni basate su container, dove le vulnerabilità potrebbero essere presenti anche tra le dipendenze di sistema.
LEGGI ANCHE:
2. TESTING AUTOMATIZZATO
Oggi i test automatizzati svolgono un ruolo cruciale nella continuous delivery: aiutano ad accelerare il processo di release e a prevenire problemi di falle nel codice prima di arrivare alla produzione. Va da sé che anche la sicurezza andrebbe testata, così come avviene per le altre funzionalità. I test di sicurezza automatizzati aiutano a identificare i problemi di security e le vulnerabilità già nella fase iniziale, facendo risparmiare molto tempo a sviluppatori e team DevOps.
Per implementare test automatizzati non è necessario reinventare la ruota. Fortunatamente esistono numerosi strumenti che sono di grande aiuto in questo senso. Alcuni dei più famosi sono Selenium, Katalon, Ranorex e SmartBear.
LEGGI ANCHE:
3. CHANGE MANAGEMENT
Nel settore IT, la gestione delle modifiche è una procedura standard che viene definita da qualsiasi organizzazione per controllare i cambiamenti nel software o nell'infrastruttura, al fine di ridurre al minimo il numero di incidenti.
Gli sviluppatori vengono formati per fornire prove adeguate di un test e i possibili impatti di eventuali modifiche durante la produzione. Dovrebbero essere formati sul tema della security e ricevere gli strumenti necessari per poter valutare e affrontare le questioni critiche. Ciò aumenta la qualità del processo di gestione delle modifiche e permette ai membri del team di individuare i potenziali problemi di sicurezza prima del rilascio.
In questo processo è fondamentale adottare delle buone pratiche di review del codice che poi viene integrato. Prima di portare il nuovo codice in un branch di integrazione, questo deve essere adeguatamente testato in modo automatico tramite la CI e poi va chiesta una peer review manuale da parte del team di sviluppo. Questo permette di aumentare la qualità, il livello di sicurezza e la consapevolezza del team sul codice sviluppato.
4. MONITORAGGIO DELLA COMPLIANCE
La compliance è un aspetto cruciale per ogni organizzazione, specialmente per settori come quello finanziario o bancario. Ci sono molte normative da seguire, e questo talvolta rende difficile avere un processo di release senza intoppi. Per ottenere un processo di software delivery veloce e conforme si dovrebbe inserire l'auditing come parte della pipeline CI/CD in cui i passaggi principali sono registrati come prova per i controlli, e tutte le operazioni sono trasparenti.
Ci sono anche tool specifici per questa operazione, come Netwrix, Libryo e Integrum.
5. THREAT INVESTIGATION
Quando il codice viene consegnato all’ambiente di produzione, il monitoraggio diventa importante per controllare costantemente le prestazioni. La security è cruciale per qualsiasi organizzazione quando un'applicazione è esposta agli utenti finali, soprattutto su internet o su una rete pubblica. Per questo motivo dovrebbe esserci almeno un'implementazione minima delle soluzioni di monitoraggio per la scansione di sicurezza, in modo da controllare costantemente il traffico in entrata e in uscita e trovare eventuali anomalie.
Anche qui è importante tenere sempre sotto controllo tutte le dipendenze delle nostre applicazioni (compreso il sistema operativo) che potrebbe essere le porte di compromissione.
6. FORMAZIONE DEL PERSONALE
L’ultimo suggerimento per introdurre DevSecOps riguarda la formazione. Con DevSecOps non esiste un team specifico dedicato alla sicurezza, ma sono tutti i membri del team ad occuparsene nel proprio lavoro. Inutile dirlo, le organizzazioni possono avere successo con l’approccio DevSecOps solo se il team è formato sugli aspetti di sicurezza.
Esistono diverse opzioni per creare conoscenza condivisa e favorire i cambiamenti culturali necessari all'interno della aziende: programmi di certificazione, workshop, laboratori pratici ed eventi come gli hackathon per coinvolgere persone con diversi ruoli e farle sentire parte di un unico team.
DevSecOps per container e microservizi
Abbiamo visto quali sono le best practice per passare a DevSecOps e guadagnare vantaggi in termini di processi, efficienza e sicurezza. Ora, facciamo un focus sul tema dei container e microservizi. Sono rispettivamente una tecnologia e un approccio architetturale alla realizzazione di applicazioni e stanno diventando la nuova unità di misura delle moderne applicazioni Cloud Native. Proprio per questo è sempre più importante garantire la sicurezza dei container e dotarsi di processi adeguati.
Anche in questo contesto l’approccio shift-left - ovvero l’anticipazione delle pratiche di sicurezza a partire dalle fasi iniziali del software development lifecycle descritto in precedenza - è implementabile a diversi livelli di profondità. Infatti, è possibile approcciarsi alla sicurezza di questa tipologia di workload sia da un punto di vista di ambiente e dati, sia dal punto di vista del processo di CI/CD. Vediamole nel dettaglio.
Sicurezza di ambiente e dati
Ecco i consigli per garantire la sicurezza di ambiente e dati:
- Limitare nella misura massima possibile gli accessi e i collegamenti non autorizzati;
- adottare meccanismi rigidi di autenticazione centralizzata e di controllo degli accessi;
- separare tra loro e dalla rete i container che eseguono i microservizi;
- cifrare il traffico in transito tra applicazioni/servizi diversi;
- adottare un API Gateway per implementare un single pane of glass su tutti i servizi esposti.
Sicurezza del processo di CI/CD
Vediamo invece quali sono le best practice per assicurare la sicurezza del processo di CI/CD:
- Integrare un'analisi di sicurezza per i container e per le immagini prodotte e utilizzate;
- abilitare il continuous testing come precedentemente descritto;
- automatizzare gli aggiornamenti di sicurezza, come le patch per le vulnerabilità note;
- automatizzare la gestione della configurazione del sistema e dei servizi.
Esulando dagli approcci tecnologici, una buona prassi utilizzabile come fondazione di una DevSecOps strategy è la redazione di una Compliance Map - o Export Control map - con l'obiettivo di censire e monitorare le dipendenze e librerie di terze parti utilizzate all’interno della codebase. Questa pratica aiuta ad evitare l’eccessiva proliferazione di dipendenze e possibili problemi legati alla tipologia di licenza che tale libreria o dipendenza utilizza.
DevSecOps: un trend crescente
Secondo la ricerca DevSecOps Market – Forecast (2020-2025), il mercato DevSecOps raggiungerà i 6,5 miliardi entro il 2025. Per riprendere le parole dello studio, c'è una "crescente necessità di sicurezza nella continuous application delivery e di una maggiore attenzione alla security e alla compliance", così come "una maggiore consapevolezza delle minacce alla sicurezza nelle grandi imprese".
DevSecOps sta crescendo nelle aziende perché è in grado di soddisfare tutte queste esigenze: la sua implementazione può essere una mossa vincente, purché si operi seguendo le principali linee guida.
