Lo sviluppo agile è diventato il mantra per qualsiasi realtà che produca artefatti software. In qualsiasi scenario, il rilascio frequente di nuove componenti ed aggiornamenti viene considerato ormai indispensabile per restare al passo sia con le opportunità offerte dallo sviluppo tecnologico, sia con le esigenze espresse dagli utenti. Ma vale anche per i cicli di sviluppo quello che abbiamo tutti imparato nella vita reale: va bene correre, ma occorre stare bene attenti a non cadere perché, se accade, correndo ci si fa più male che andando piano.

La "caduta" che rischiano i team di sviluppo software è ovviamente la produzione di codice meno che ottimale. I rischi più frequenti e più pericolosi riguardano la cyber security, e da due punti di vista. Da un lato, creare codice che non è sicuro di per sé e introduce vulnerabilità che possono essere sfruttate da malintenzionati. Dall'altro, avere catene di sviluppo non sicure in cui la configurazione ed i profili d'uso dei tool per lo sviluppo lasciano lo spazio ad intrusioni di hacker ostili.

Il primo ambito di rischio è più noto e anche maggiormente presidiato, perché tutti i team di sviluppo sanno di dover creare codice affidabile. Il secondo ambito è meno evidente perché riguarda la messa in sicurezza di un ciclo - quello del software e della sua implementazione - che coinvolge figure diverse e può presentare "aree grigie" in cui la cyber security non è chiaro come vada tutelata e da chi.
La risposta sta nel concetto oggi sempre più popolare di DevSecOps. L'approccio DevOps ha indicato che tanto lo sviluppo quanto le operations sono responsabili della stabilità degli ambienti applicativi. Così DevSecOps indica che tutte le parti coinvolte nel ciclo di vita di una applicazione sono responsabili - ovviamente ciascuna a suo modo e con le sue specificità - della sua sicurezza.

La sicurezza si fa continua

Come tutti i termini che diventano improvvisamente di moda, DevSecOps può dare una impressione troppo sintetica e quindi ingannevole del problema che mette in luce. La sicurezza in effetti non è qualcosa che sta in mezzo tra sviluppo (dev) ed operations (ops) restandone al contempo separata, per approcci e strumenti. Dovrebbe essere integrata in ogni passo dello sviluppo, degli aggiornamenti e delle implementazioni. Motivo per cui spesso si preferisce l'espressione "continuous security", che da più l'idea di una cyber security pervasiva. Altri preferiscono sottolineare che anche la sicurezza deve, come dicono gli anglosassoni, "spostarsi a sinistra" ("shift left") per essere più vicina alle fasi iniziali del ciclo di sviluppo.

Al di là dell'espressione che si usa per descriverlo, il problema oggi si fa pressante. "Il ciclo sviluppo-integrazione-rilascio oggi è sempre più veloce - spiega Massimiliano Micucci, Country Sales Manager, Italy di One Identity - sino al punto che la velocità diventa un rischio e non più un vantaggio. La risposta è anche inserire nel ciclo DevOps strumenti e metodi che facilitino una gestione sicura della velocità. Per alcuni versi la tematica è la stessa che abbiamo incontrato nello sviluppo tradizionale, ma alla velocità del DevOps e con un grado molto maggiore, oggi, di interazioni tra applicazioni e componenti software".

In quest'ottica lo "spostamento a sinistra" della cyber security non è una moda tecnologica. "Affrontare prima possibile le questioni legate alla sicurezza del processo di sviluppo - sottolinea Riccardo Fiano, Sales Manager della business unit romana di Par-Tec - significa anche non trovarsi, magari a metà di un progetto, a dover risolvere questioni di sicurezza impreviste ma allo stesso tempo inevitabili. Mantenere un controllo di sicurezza su tutto il processo di sviluppo significa procedere più tranquillamente verso la sua fase conclusiva".
Che DevSecOps non sia solo una moda è dimostrato ampiamente dalla cronaca della cyber security. Non mancano i casi anche eccellenti che dimostrano come il tradizionale approccio reattivo alla sicurezza dello sviluppo sia inadeguata: qualsiasi reazione è comunque troppo lenta e la proverbiale stalla si chiude quando i buoi sono già lontani.

Un nuovo metodo

Certo non basta introdurre un nuovo termine - DevSecOps - per mettere tutti d'accordo e soprattutto tutti tranquilli. È una questione di cultura prima ancora che di strumenti da adottare, che pure ci sono. "Come sempre - sottolinea Riccardo Fiano - la sicurezza è un processo, non è un prodotto. È fondamentale prima creare una cultura diffusa della sicurezza in azienda, poi scegliere le soluzioni per metterla in pratica".

Una cultura della sicurezza che, lato sviluppo, va fatta anche attraverso formazione specifica sul secure coding e con elementi di etical hacking di base. Serve poi individuare un membro esperto del team di sviluppo che abbia mostrato attitudine per la cyber security, a cui dare una formazione ancora più spinta sulla sicurezza. "Una figura del genere - spiega Fiano - diventa il punto di contatto ideale tra team di security e team di sviluppo/DevOps, ed è anche in grado di individuare in autonomia le tematiche di sicurezza più ricorrenti ed i punti deboli del processo di sviluppo".

ImpresaCity, Par-Tec e One Identity hanno organizzato un webinar incentrato su DevSecOps e secrets management: visita questa pagina per saperne di più

Il maggior rischio per chi spinge verso lo "shifting left" della sicurezza è che questo venga percepito come un rallentamento dello sviluppo dovuto a maggiori controlli e magari anche a strumenti aggiuntivi da mettere in campo. "L'approccio alla sicurezza nello sviluppo deve essere il più possibile trasparente", spiega Massimiliano Micucci: "Non possiamo costringere i team di sviluppo, che devono essere veloci e sempre all'avanguardia, ad adeguarsi a soluzioni in più. Queste ci sono ma agiscono dietro le quinte, mentre gli sviluppatori apparentemente continuano ad usare le funzioni di sicurezza integrate negli strumenti che già utilizzano. Per loro non cambia nulla, per la sicurezza complessiva dei sistemi cambia invece molto".
In questo senso le parole chiave sono automazione ed integrazione trasparente. "Velocità ed automazione sono due elementi chiave già per DevOps, non possono non esserlo anche per DevSecOps", sottolinea Riccardo Fiano: "con rilasci ogni pochi minuti, come avviene ormai in molti ambienti DevOps, non c'è tempo per la security a posteriori". A questi ritmi è impossibile garantire uno sviluppo "blindato" senza strumenti automatizzati che effettuino da soli i controlli necessari, chiamando in causa il personale umano solo quando si verifica qualcosa di specifico, nuovo oppure inatteso.

L'automazione si porta dietro la necessità di integrazione: le soluzioni mirate che garantiscono la sicurezza dei processi DevOps devono sapersi integrare direttamente con i tool di sviluppo. Il che normalmente avviene attraverso interfacce applicative: quello di DevSecOps è un mondo decisamente "API first" in cui è il dialogo dietro le quinte dei componenti software a garantire l'automazione sicura.

Il secrets management

Tutto questo si vede chiaramente in uno degli ambiti chiave di DevSecOps: il cosiddetto secrets management. Una pipeline DevOps è fatta di un numero elevato di tool specifici (da Git a Jenkins, da Kubernetes ai repository in cloud, sino al tool di sviluppo preferito del singolo sviluppatore), ciascuno dei quali può avere gerarchie di ruoli e di account, con una conseguente pletora di password, chiavi di cifratura, certificati digitali e quant'altro.

Proprio per questa complessità, un ambiente DevOps è comunque vulnerabile ad attacchi esterni, attraverso furti o abusi di account, a meno che non si implementi una strategia complessiva di secrets management. Ossia, come indica il termine, una gestione automatizzata, centralizzata e blindata di tutti i "segreti", cioè le credenziali che utenti umani, servizi digitali e componenti software usano per poter operare.
Il secrets management è per moltissimi versi assimilabile alla gestione ed alla protezione degli account privilegiati, che sempre più sono associati - come nelle pipeline DevOps - ad entità digitali e non a persone fisiche. Analogamente, il secrets management non è fatto solo di password più o meno complesse che uno sviluppatore deve ricordare. È fatto in prevalenza di chiavi e codici che vanno attivati e disattivati in funzione di determinate procedure di sicurezza e dei diritti di accesso ed utilizzo che un certo componente software può avere verso un altro o verso una risorsa. Tutto troppo complesso per basarlo su una gestione manuale, soprattutto alla velocità del DevOps.

Proprio questa complessità impone anche la "invisibilità" del secrets management. Le attività di sviluppo sarebbero enormemente rallentate, e non certo "agili", se gli sviluppatori dovessero autenticarsi esplicitamente ed in maniera sicura a tutte le risorse che usano loro stessi e i loro tool. Gli strumenti di secrets management hanno per questo un approccio frictionless: si calano nella infrastruttura esistente in modo da abilitare tutti gli aspetti di sicurezza necessari nella gestione dei "segreti", ma restano nascosti "dietro" le consuete procedure di autenticazione ed autorizzazione degli strumenti che gli sviluppatori già usano.