Il rispetto dei requisiti funzionali per lo sviluppo sicuro del software è garantito anche dall’applicazione del principio della security by design, ormai ampiamente diffuso anche nella community degli sviluppatori.
In questo contesto, però, occorre osservare che il deciso cambio di passo nei rilasci software sospinti dal time to market esasperato e dalle mutevoli esigenze di mercato stanno progressivamente sostituendo gli ingombranti progetti con orizzonti temporali pluriennali in modalità waterfall con progetti in modalità agile, caratterizzati da cicli di sviluppo brevi e continuativi che partono con l’obiettivo di un prodotto con le caratteristiche essenziali e di valore per l’utente finale (il “minimum viable project”) per poi arricchirlo progressivamente con iterazioni di sviluppo successive o abbandonarlo laddove non si dimostrasse remunerativo.
Tale approccio, che si adatta perfettamente alle attuali esigenze del mondo IT, si ripercuote inevitabilmente nel modo di fare sicurezza sia dal punto di vista tecnologico che organizzativo.
Indice degli argomenti
Sviluppo sicuro del software: identificazione delle vulnerabilità
La tecnologia nell’ambito della sicurezza software si sta orientando verso strumenti di analisi automatica per consentire di eseguire scansioni di vulnerabilità in modo sistematico e veloce: ad ogni rilascio deve seguire un’analisi statica del codice, un’identificazione delle vulnerabilità e una loro prioritizzazione.
Queste attività devono seguire i tempi di risposta dello sviluppo software: i rilasci possono avere cadenze mensili, settimanali o addirittura inferiori (dell’ordine di decine di secondi nel caso di Amazon) e devono farlo con una precisione che non comprometta la soglia di rischio che rimane sempre il riferimento per le scelte in ambito sicurezza.
Detto quindi che è fondamentale che tutte le aziende siano dotate di questi strumenti, è altrettanto importante che siano inseriti all’interno dei processi aziendali e che siano utilizzati in modo sistematico per ogni rilascio: devono essere dei security gate che impediscano la promote di codice affetto da vulnerabilità ritenute non accettabili.
Ovviamente il superamento di analisi statica del codice non garantisce di per sé che il codice sia sicuro (anche perché non tiene conto del suo comportamento all’interno dell’ecosistema, cosa che è più specifica dell’analisi dinamica), ma permette un’analisi completa del codice (coverage) e la mancanza, molto pericolosa, di validazioni degli input (sanitization).
Sviluppo sicuro del software e analisi di sicurezza
Nonostante gli indubbi benefici, le analisi di sicurezza vengono viste come un impedimento al raggiungimento degli obiettivi IT che sono tipicamente sinonimo di quantità di software rilasciato, prima ancora che di qualità.
Dotarsi di strumenti che riducono falsi positivi, che facilitano l’interpretazione dei risultati e che aiutino l’individuazione delle remediation non solo migliorano l’output ma favoriscono un atteggiamento favorevole al suo utilizzo.
Le caratteristiche essenziali per questi tool di analisi statica del codice (SAST) sono:
- la possibilità di essere completamente automatizzabili e quindi inseribili all’interno di pipeline di sviluppo;
- capacità di analizzare tutte le dipendenze del codice in esame visto l’uso estensivo di librerie open source;
- essere integrabile con la maggior parte degli IDE in modo da portare i test di sicurezza il più possibile “a sinistra”, all’inizio delle fasi di sviluppo se non addirittura durante la scrittura dello stesso.
Quest’ultimo punto è un elemento molto importante perché consente di individuare bug di sicurezza fin dalle prime fasi dello sviluppo riducendone al minimo il costo di remediation (com’è noto un bug in produzione è stimato avere un costo medio anche mille volte superiore rispetto allo sviluppo).
È dunque evidente il miglioramento in termini di efficienza ed è la ragione per la quale tutti i software di analisi statica di livello Enterprise si stanno orientando proprio in questa direzione.
In sintesi, quindi, i punti di attenzione per i tool di analisi statica includono:
- la predisposizione all’automazione per ridurre i tempi di risposta e l’effort di gestione dei bug;
- la possibilità di scan delle dipendenze per offrire una copertura software completa;
- l’integrabilità con framework di sviluppo (IDE) per offrire controlli già dalle prime fasi individuando in anticipo i bug di sicurezza minimizzando drasticamente i tempi di fixing.
Diffondere la cultura della sicurezza
Un altro effetto significativo dello spostamento dei controlli di sicurezza verso le fasi inziali di sviluppo del codice è quello di distribuire sugli sviluppatori una maggiore cultura della sicurezza, portandoli ad analizzare e correggere i bug di sicurezza anziché rimandarli ad uffici di sicurezza in fasi successive come avviene frequentemente nei modelli sviluppo software più tradizionali.
Diffondere controlli più vicino allo sviluppatore ha il doppio effetto benefico, quindi, di ridurre i tempi di rimedio dei bug e di diffondere una maggiore cultura della sicurezza.
Quanto detto, poi, si amplifica per tutte quelle aziende con una leva verso fornitori molto accentuata perché in questo caso i temi di rimedio devono tenere conto di una comunicazione tipicamente più lenta e subordinata a clausole contrattuali.
Da questo punto di vista esistono strumenti che consentono di applicare gli stessi controlli di sicurezza del codice agli sviluppatori interni ed esterni. Tecnicamente, infatti, è possibile fare in modo che gli IDE di sviluppo di fornitori esterni applichino le stesse regole valide per gli sviluppatori interni all’azienda uniformando il livello di sicurezza, identici controlli per tutti, indipendentemente da chi lo ha sviluppato:
- personale interno;
- personale conosciuto di società terze;
- personale che opera dall’altra parte del mondo con conoscenza e stile di scrittura del codice anche molto diverso.
Il punto chiave per un’iniziativa di questo tipo però non è tanto quello di trovare uno strumento di analisi statica che implementi questi controlli (questo tecnicismo è ormai prerogativa della maggior parte dei tool di questa categoria), quanto piuttosto “obbligare” i fornitori a consegnare il solo codice che abbia rispettato i controlli suddetti a garanzia della qualità del codice.
Non è infatti scontato che il fornitore accetti di buon grado di applicare controlli stabiliti da un cliente sul codice scritto da loro, soprattutto se poi intervengono altre clausole sui tempi di consegna.
Ad oggi molto spesso la qualità del codice è gestita secondo generiche clausole contrattuali che non si traducono nei fatti in obblighi specifici e quindi poco applicabili verso terze parti: del resto i controlli devono essere il più possibile oggettivi e misurabili.
Sviluppo sicuro del software e metodologia agile
Nella maggior parte dei casi la metodologia agile si realizza tramite il devops, di dui l’agile è un fattore abilitante.
Nel concreto, questo significa un radicale cambiamento nell’organizzazione del lavoro e quasi sempre nella creazione di pipeline di sviluppo in cui lo sviluppo del codice passa attraverso una “catena di montaggio” composta da repository, builder, tool di analisi di qualità, di sicurezza e deployer, tutti generalmente diretti da un tool di orchestrazione.
Oltre ad inserire l’analisi statica, è indispensabile anche che tutta la catena di sviluppo sia sicura gestendo in modo corretto gli accessi e applicando configurazioni di integrità del software. Creare utenze profilate nel modo corretto e avvalersi di controlli di integrità tramite la firma del codice diventano strumenti mandatori in questo tipo di implementazioni.
La tendenza generale della sicurezza applicata allo sviluppo software si sta orientando verso un sempre maggiore automatismo e verso uno “slittamento a sinistra” dei controlli per anticipare bug e vulnerabilità e ad un’applicazione degli stessi a SDLC di tipo agile.
