Un elenco di controllo per la sicurezza in ambito DevSecOps

Ecco una checklist per la sicurezza DevSecOps in dieci passaggi per permettere a qualsiasi team di rimanere allineato sul tema.

Capire in quali momenti del processo di sviluppo la sicurezza crea difficoltà

Il nostro sondaggio DevSecOps globale 2022 rivela che il divario tra sviluppatori e sicurezza si sta colmando, ma alcuni ostacoli persistono. Il 57% degli intervistati concorda sul fatto che la sicurezza sia una metrica associata alle prestazioni degli sviluppatori nella propria organizzazione, ma il 56% ha affermato che è stato difficile convincere gli sviluppatori a dare priorità alla correzione delle vulnerabilità del codice. Alla fine, il 59% ha affermato che il team di sicurezza aveva maggiori probabilità di trovare vulnerabilità di sicurezza dopo il merge del codice in un ambiente di test. Non c'è nemmeno accordo su chi sia effettivamente responsabile della sicurezza: il 43% dei professionisti della sicurezza si ritengono responsabili in prima persona, mentre il 53% ha affermato che la responsabilità dev'essere condivisa tra tutti. In sostanza: c'è molta confusione. Il primo passo dovrebbe essere quello di capire cosa comporta più difficoltà all'interno della pipeline DevSecOps.

Allineare tutti su un obiettivo comune

Data la presenza di tante supposizioni diverse sulla sicurezza e su chi ne sia responsabile, stabilire obiettivi chiari permetterà al team di avere qualcosa di tangibile su cui lavorare. Includere la sicurezza nel ciclo di vita del software non è d'aiuto a nessuno se il team non comprende le proprie responsabilità e aspettative. Ad esempio, allinearsi sull'obiettivo di testare maggiormente il codice, potrebbe portare a rilasci più frequenti, dopo un primo periodo di rodaggio. Analogamente, stabilire l'obiettivo di migliorare la pianificazione collaborando fin dall'inizio con un esperto di sicurezza significa tenere in considerazione la sicurezza in ogni fase del processo, riducendo gli ostacoli e accelerando di conseguenza i cicli di rilascio. Una pratica DevSecOps efficace responsabilizza anche i membri dei team non dedicati alla sicurezza, favorendo una cultura in cui la riduzione dei rischi è responsabilità di tutti.

Effettua una verifica interna per individuare le perdite di tempo nel flusso di lavoro

Quando non è in atto un approccio DevSecOps, i team di sicurezza individuano le vulnerabilità utilizzando i propri strumenti, di solito alla fine del ciclo di sviluppo, e poi ri-assegnano il lavoro di correzione al team di sviluppo. Fare avanti e indietro in questo modo comporta uno stato di continuo attrito tra i due team e fa perdere tempo a causa di comunicazioni inefficienti. Comprendere quanto tempo viene sprecato dal team nella gestione delle vulnerabilità dopo il merge del codice può aiutare a individuare dei pattern ricorrenti e ad apportare miglioramenti. Ad esempio, i team di sicurezza hanno problemi a monitorare lo stato di correzione delle vulnerabilità critiche, il che significa dover interpellare continuamente il team di sviluppo? Ciò potrebbe indicare la necessità di una dashboard centralizzata che permetta a sviluppatori e professionisti della sicurezza di visualizzare lo stato di correzione delle vulnerabilità critiche.

Discutere le criticità e i colli di bottiglia

La sicurezza può rappresentare un grosso impedimento al rilascio rapido di software, ma è troppo importante per sottovalutarla o ignorarla. La metodologia DevSecOps promette di tenere in considerazione la sicurezza in tutto il ciclo di sviluppo software, ma per arrivare a questo obiettivo bisogna intraprendere un percorso. Un passo importante è discutere delle criticità e dei colli di bottiglia relativi alla sicurezza con tutti (team di sviluppo, di sicurezza e operativi). Dopo aver fatto emergere ogni criticità, è necessario creare un piano per risolvere ciascuna di esse e poi eseguire quel piano. Questo tipo di discussione aiuta tutti a esprimersi e individua le criticità che potrebbero non emergere dai dati concreti.

Apportare piccole modifiche incrementali al codice

Uno dei valori fondamentali di GitLab è l'iterazione: quando apportiamo modifiche, queste devono essere alterazioni piccole e rapide su cui poi sviluppare il resto. Lo stesso principio è valido quando si passa dal DevOps al DevSecOps. Modifiche al codice piccole e incrementali sono meglio gestibili in un'ottica di revisione e sicurezza, e possono essere avviate più rapidamente rispetto alle modifiche di progetto monolitiche. Produrre codice in piccoli blocchi o unità e poi eseguire test automatici su tali unità man mano che se ne esegue il commit, consente agli sviluppatori di risolvere subito le eventuali vulnerabilità rilevate, invece di dover attendere un feedback che potrebbe arrivare giorni, settimane o addirittura mesi dopo. Eseguire i test regolarmente consente di risparmiare tempo alla fine del processo, quando viene testata l'app completa prima di mandarla in produzione.

Automatizzare e integrare

L'automazione e l'integrazione sono fondamentali in un'ottica DevOps, ma sono anche ciò che rende estremamente efficaci le analisi di sicurezza. Analisi eseguite continuamente consentono di rivedere ogni modifica al codice e di individuare vulnerabilità molto prima nel processo. Le analisi devono essere integrate nel flusso di lavoro dello sviluppatore. La sicurezza integrata consente agli sviluppatori di trovare e correggere le vulnerabilità mentre si stanno ancora occupando di quel codice specifico. Ciò riduce anche la quantità di ticket di sicurezza inviati al team apposito, semplificandone la revisione.

Consentire agli sviluppatori di accedere ai risultati dei report sulla sicurezza

Invece di lasciare i risultati del test statico di sicurezza delle applicazioni (SAST) e del test dinamico della sicurezza delle applicazioni (DAST) confinati nei team di sicurezza, è bene fare in modo che queste informazioni siano condivise in tutto il team, in particolare con gli sviluppatori. Non solo è una pratica importante ai fini della correzione, ma è anche uno strumento prezioso per aiutare gli sviluppatori a integrare i controlli di sicurezza necessari nel ciclo di vita di sviluppo software.

Completare una verifica interna dei processi di sicurezza a cascata

Nel tradizionale approccio alla sicurezza a cascata, le vulnerabilità vengono rilevate in genere alla fine del ciclo di sviluppo. Dedica del tempo a controllare i flussi di lavoro di sicurezza esistenti all'interno del ciclo di vita di sviluppo software. Se trovi processi a cascata, prendi in considerazione la possibilità di eliminarli o almeno di esserne il meno dipendente possibile. Dovresti sempre poter cambiare direzione in base alle esigenze preservando l'agilità della tua organizzazione.

Assicurarsi che il team di sicurezza abbia visibilità sullo stato delle vulnerabilità

Il sondaggio DevSecOps globale 2022 ha mostrato che la sfida più grande per i professionisti della sicurezza è dare priorità alla correzione delle vulnerabilità. La quantità di falsi positivi e la difficoltà di monitorare lo stato di vulnerabilità sono altre preoccupazioni concrete. Questo potrebbe essere uno dei fattori alla base delle prospettive, in qualche modo negative per il futuro, che hanno i professionisti della sicurezza: solo il 56% ha dichiarato di sentirsi "in qualche modo" o "molto preparato" per il futuro (quasi 20 punti in meno rispetto alla risposta media di team di sviluppo e operativi). È chiaro che i team di sicurezza devono poter avere una maggiore visibilità sulle vulnerabilità risolte e non risolte, su dove si trovano, su chi le ha create e sullo stato di correzione.

Semplificare gli strumenti in un'unica piattaforma DevOps

È difficile per tutti i membri del team essere responsabili della sicurezza quando mancano gli strumenti giusti. Il modo migliore per adottare un approccio Shift Left è utilizzare una piattaforma end-to-end che aiuti i team DevOps ad abbandonare i processi a cascata, che semplifichi la comunicazione, che preveda l'automazione e l'integrazione continua e che funga da unica fonte di riferimento per i risultati delle analisi di sicurezza e lo stato delle vulnerabilità critiche.