L’ICT propone modelli di ciclo di vita ed esecuzione del software sempre più integrati e sempre più stringenti per il successo dell’azienda. In passato, l’area IT doveva costruire manualmente l’infrastruttura sulla quale il codice potesse essere testato e distribuito, mantenendo una distanza tra i due team dei developer e delle IT operations. Successivamente l’infrastruttura è stata resa accessibile via software, permettendo l’integrazione dei due team: siamo arrivati all’approccio DevOps, nel quale l’intero processo è stato automatizzato.

Le risorse infrastrutturali sono quindi modulate direttamente nella fase di sviluppo: per la gran parte, i colli di bottiglia possono essere evitati nei normali cicli della filosofia CI/CD, continuous integration, continuous delivery.

Con DevOps si intende quindi la combinazione di strumenti, pratiche e filosofie che permettono di fornire servizi e applicazioni ICT con cicli di lavoro integrati e di breve durata.

SecOps: che cosa vuol dire?

Così come DevOps sottintende la fusione dei team e delle competenze di IT operations e Development, SecOps fonde i team di security e IT operations. SecOps è quindi una metodologia che mira ad automatizzare le attività di sicurezza, combinandole con le competenze IT Operations.

La sicurezza è certamente una attività mission critical, che richiede evoluzioni continuamente imposte da variazioni tecnologiche o normative. Guardando alla sola privacy, si pensi alla necessità di adeguarsi non solo al GDPR europeo, ma anche e contemporaneamente al CCPA californiano (California Consumer Privacy Act) e l’APPI giapponese (Act Protection of Personal Information), o qualsiasi altro framework normativo.

Il team SecOps è in grado di considerare le minacce alla sicurezza durante l’intero ciclo di sviluppo e come queste minacce potrebbero influenzare sia il software, sia gli utenti che potrebbero incontrarle. L’azione di sicurezza in SecOps cerca di essere proattiva, prevenendo i rischi nella loro fase iniziale, prima che diventino un problema difficile da gestire.

Anche in questo caso, come per i DevOps, risorse generalmente viste come silo monolitico -quelle destinate alla sicurezza – vengono rese disponibili alle altre fasi di sviluppo e distribuzione di soluzioni. Non si avrà più un team di sicurezza isolato dagli altri: il senior developer apprenderà dal security expert e viceversa.

DevSecOps: che cosa vuol dire?

Il processo di integrazione dei team può essere ulteriormente raffinato. È quello che succede modificando la metodologia per la coesistenza da due a ben tre team quali IT Operations, Developer e Security. Siamo giunti al DevSecOps, un approccio nel quale le necessità di sicurezza vengono inserite nella robusta trama DevOps.

Infatti, adottando la metodologia DevOps in modo separato dalla sicurezza, la linearità del flusso di lavoro risentirebbe comunque del confronto con un team di sicurezza ovviamente anch’esso separato.

Con la metodologia DevSecOps (DevOps + Security) gli aspetti critici del controllo sulle vulnerabilità del codice e delle modalità d’erogazione dei servizi vengono considerati tutti insieme, fin dalle fasi iniziali dello sviluppo. Questo procedimento aiuta l’integrazione non solo nello sviluppo del software, ma anche di competenze e sensibilità che devono essere ben distribuite nei membri del team complessivo.

DevSecOps fa in modo che la sicurezza dei dati non faccia da collo di bottiglia nel ciclo di sviluppo e di rilascio DevOps, permettendo a tutti i membri dei team di condividere l’impegno nella tutela dei dati e trarre grande vantaggio dall’automazione.

L’automazione ottenuta in questo modo rende la sicurezza un elemento chiave, facendo rientrare il software così sviluppato nella categoria del security by design per l’intero ciclo di vita del software.

La fusione di tre aspetti in uno implica un passaggio importante. I Direttori IT devono creare le condizioni affinchè sicurezza e velocità possano coesistere nel ciclo di sviluppo. DevSecOps risolve questo nodo, implementando dei test che permettano di identificare sezioni dubbie del codice e rimandarle al team di sviluppo prima che vengano mandate in produzione. In questo modo, la metodologia risolve by design la gran parte dei rischi di codice insicuro e al contempo aumenta la sensibilità del team verso pratiche apparentemente valide, ma che nascondono rischi ancora inesplorati.

DevSecOps VS SecOps: quale scegliere?

Le due metodologie sono sostanzialmente molto simili. Questa somiglianza si fa più sottile se l’azienda è già ben addentro al processo di trasformazione in chiave DevOps.

Per una corretta scelta, gli approcci SecOps e DevSecOps devono essere confrontati in fase di valutazione del singolo progetto. Il livello di automazione e l’esposizione ad attacchi possono fare la differenza.

Ovviamente si tratta di una alternativa solo temporanea. Anche se con modalità più o meno lineari, la trasformazione digitale in atto sta portando verso un’inevitabile adesione al modello completo DevSecOps.

Inoltre, se un’azienda costituisce un nuovo team di sviluppo, o se si costituisce una nuova azienda, la scelta migliore è di aderire fin dall’inizio alla metodologia DevSecOps. In questo caso, il vantaggio competitivo verso chi non aderisce completamente sarà determinante nel successo dell’acquisizione di clienti.