Un’abbreviazione difficile da capire. David Pickering, Senior Technical Marketing Engineer di Ivanti vuole spiegare cosa significa realmente il termine DevSecOps.
Nella Babele di parole chiave dell’IT, DevSecOps è una delle abbreviazioni più difficili da capire. Si tratta di un nome di fantasia per uno strumento specifico? È forse una best practice, una priorità per il team IT o una filosofiaaziendale? In realtà più che un termine di tendenza, DevSecOps è l’evoluzione dei processi di sviluppo completi per le organizzazioni più evolute.
La naturale evoluzione di DevOps rispetto ai classici cicli di vita del software
Nell’iniziale approccio al DevOps, che risale agli inizi del 2008, i cicli di vita dello sviluppo del software seguivano un modello a cascata. La dipendenza dal completamento di parte dei processi portava rallentamenti nella consegna di applicazioni e aggiornamenti. Per soddisfare la domanda del mercato e le scadenze, i team di sviluppo dovevano essere tempestivi nella consegna dei prodotti. Da qui l’affermarsi della metodologia ‘Agile’ che prevedeva rilasci del software ridotti ma frequenti. Mentre i team sviluppavano e testavano funzionalità aggiuntive. Ciò ha generato un processo di sviluppo continuo attraverso la collaborazione e l’automazione, identificabile nell’odierno DevOps.
Perché DevOps deve orientarsi verso lo Shift Left per la sicurezza?
La velocità e l’automazione di un moderno processo DevOps, tuttavia, possono causare un aumento del rischio e un maggior numero di vulnerabilità. Questo perché all’interno di un processo DevOps tradizionale, la valutazione della sicurezza avviene solamente al termine della fase di sviluppo, generando:
Rallentamenti nei processi di sviluppo con l’approccio reattivo e obbligatorio alla sicurezza.
Sfiducia e frustrazione degli sviluppatori verso il team di sicurezza, poiché devono rielaborare il software quasi pronto per risolvere i problemi di sicurezza che avrebbero potuto essere identificati e corretti prima.
Il modello Shift Left
Per questo motivo, le organizzazioni hanno iniziato ad avvicinarsi al modello “Shift Left”. Ovvero a introdurre proattivamente la sicurezza nella fase di sviluppo, anziché integrarla alla fine. Gli sviluppatori sono però riluttanti a farsi carico della sicurezza per l’impatto sulla loro produttività e perché non ritengono di avere la competenza necessaria. Lo sviluppo però non è l’unico processo che richiede una maggiore integrazione della sicurezza.
Il termine DevSecOps
Anche il team di gestione operativa deve essere incluso nella nuova assegnazione delle priorità. Poiché i sistemi operativi, i database, i server web e altre parti dell’infrastruttura tecnologica ospitano spesso potenziali vulnerabilità. In definitiva, DevSecOps garantisce un perfetto equilibrio tra l’agilità e la rapidità dello sviluppo e il mantenimento di un ambiente operativo e applicativo sicuro.
Questo processo collaborativo richiede consapevolezza e automazione tra i tre team di Development, Operations and Security. I primi devono riconoscere l’importanza della sicurezza. Includendo proattivamente le valutazioni dei rischi e le correzioni nella fase di sviluppo. Mentre i team di sicurezza e di gestione operativa devono facilitare il continuo ciclo di vita di sviluppo, assegnando la giusta priorità alle vulnerabilità.
Non esiste uno strumento DevSecOps universale
Nessuno strumento o soluzione è, però, in grado di soddisfare le molteplici esigenze di una pipeline di continuous integration/continuous delivery (CI/CD). DevSecOps racchiude troppe caratteristiche e potenziali criticità aggiuntive per poter disporre di un’unica tecnologia o applicazione in grado di rispondere a tutte le esigenze. Come parte di un protocollo DevSecOps efficiente, un’organizzazione deve implementare l’analisi dell’infrastruttura. Così come le scansioni dinamiche delle applicazioni e del software e prevedere i penetration test automatizzati e il fuzzing delle API. Oltre a questo elenco parziale bisogna considerare tutte le altre fonti di informazioni sulle vulnerabilità che devono essere sintetizzate, codificate e gestite per poter comprendere meglio l’urgenza, l’impatto e assegnare la giusta priorità.
Assegnare la giusta priorità a DevSecOps senza aumentare il carico di lavoro
In sintesi, DevSecOps non si deve considerare come un unico strumento ma un modello basato su automazione, integrazione e collaborazione tra i team. Dopotutto lo Shift Left richiede che l’intero team prenda in considerazione potenziali vulnerabilità, debolezze e rischi fin dall’inizio del progetto.
Cosa significa realmente il termine DevSecOps
Questa nuova ottica richiede la verifica del software mentre è in fase di sviluppo e la risoluzione dei problemi come parte integrante dell’operazione complessiva. I test di sicurezza automatizzati devono essere eseguiti parallelamente allo sviluppo del software, integrati durante la revisione del software e aggiunti ai criteri in fase di collaudo. Inoltre, se la sicurezza deve essere inclusa direttamente nelle operazioni generali e nei processi di sviluppo, l’aggregazione e la prioritizzazione dei dati sulle vulnerabilità e sulle debolezze diventano di vitale importanza.
Lo schema tecnico automatizzato e integrato di un progetto DevSecOps avanzato
Sebbene DevSecOps non disponga di un’unica soluzione che copra tutte le fasi del processo, deve avere un solido set di strumenti per tracciare il lavoro dei vari team e coordinare le attività critiche per eliminare le vulnerabilità del software prima che diventino pubbliche. Gli sviluppatori di solito utilizzano strumenti ad hoc come Jira o Azure DevOps per la gestione dei workload. Mentre il team di gestione operativa probabilmente ricorrerà a strumenti di service management come Ivanti Neurons per ITSM. I team di sicurezza si appoggeranno, invece, a suite differenti non necessariamente compatibili con le soluzioni tecnologiche in uso agli altri team.
Ivanti spiega cosa significa realmente il termine DevSecOps
Per le organizzazioni che cercano di collegare questi diversi programmi in un processo DevSecOps unificato, esistono algoritmi e strumenti più avanzati che consentono una capacità di automazione senza pari che va dalla raccolta dei dati grezzi alla prioritarizzazione del rischio in base alle vulnerabilità peculiari dell’organizzazione. Sono previsti anche tools per la focalizzazione sulle priorità di sicurezza in base alle tendenze attuali del ransomware alle vulnerabilità, dall’esecuzione di codice remoto all’escalation dei privilegi.
Le conclusioni
Molte organizzazioni che implementano il processo DevSecOps riscontrano che l’automazione e la gestione centralizzata di questi dati in un unico hub integrato consente a tutti i team di lavorare sull’attività giusta al momento giusto. Consentendo al contempo la misurazione e la definizione di report trasversali rispetto ai principali KPI. In conclusione, DevSecOps si fonda sulla collaborazione tra i team di Development, Operations and Security, che comprendono e condividono aspettative, report e KPI comuni. Questa trasparenza è fondamentale per il successo dell’implementazione del processo DevSecOps.
Nell’iniziale approccio al DevOps, che risale agli inizi del 2008, i cicli di vita dello sviluppo del software seguivano un modello a cascata. La dipendenza dal completamento di parte dei processi portava rallentamenti nella consegna di applicazioni e aggiornamenti. Per soddisfare la domanda del mercato e le scadenze, i team di sviluppo dovevano essere tempestivi nella consegna dei prodotti. Da qui l’affermarsi della metodologia ‘Agile’ che prevedeva rilasci del software ridotti ma frequenti. Mentre i team sviluppavano e testavano funzionalità aggiuntive. Ciò ha generato un processo di sviluppo continuo attraverso la collaborazione e l’automazione, identificabile nell’odierno DevOps.
