Sicurezza delle applicazioni: il modello DevSecOps

Nov 01, 2019 Trend Micro RSS, Trend Micro_Vocabolario della Sicurezza 0

Spesso si parla di sicurezza come se ci si riferisse a qualcosa di “esterno” alle applicazioni e ai sistemi. In realtà il livello di sicurezza di un software è strettamente legato al suo processo di sviluppo. Questo tema, emerso con prepotenza negli ultimi anni, è strettamente legato al concetto di DevOps.

“Con questo termine si intende una metodologia di sviluppo del software che mette in comunicazione gli sviluppatori e chi utilizzerà l’applicazione” spiega Salvatore Marcis di Trend Micro. “DevOps in questo senso rappresenta un’evoluzione dei normali processi di sviluppo”.

Normalmente, infatti, i processi di sviluppo sono “egemonizzati” dai programmatori, che lavorano in piena autonomia e, nella migliore delle ipotesi, operano semplicemente su indicazioni preventive. I primi feedback da parte di chi utilizzerà il software arrivano solo in una fase avanzata, quando l’applicativo ha già raggiunto un certo livello di usabilità.

Con la metodologia DevOps, la logica cambia radicalmente. I due reparti (sviluppo e operativo) collaborano in un processo che permette di verificare quotidianamente le caratteristiche dell’applicativo attraverso la comunicazione, la collaborazione e l’integrazione.

“Al posto di aspettare una fase avanzata per introdurre eventuali modifiche, con il rischio di dover stravolgere buona parte dell’architettura del software, si punta piuttosto a introdurre ogni cambiamento appena ci si accorge che ne serve uno” puntualizza Marcis.

Un sistema che, apparentemente, può sembrare più complesso e arzigogolato, ma che in realtà offre risultati migliori nel lungo periodo sia per quanto riguarda la qualità degli applicativi sviluppati, sia per quanto riguarda il “time to market”, cioè il momento in cui l’applicazione può essere effettivamente implementata.

“La nuova frontiera di questo processo di evoluzione nello sviluppo software è il DevSecOps” spiega Marcis. “Oltre allo sviluppo (Dev) e alle operations (Ops) viene integrato anche l’aspetto del “Sec”, cioè della sicurezza”.

In molti casi (per la verità nella maggioranza dei casi) il tema della sicurezza viene considerato solo a posteriori quando l’applicazione è già pronta per l’implementazione. Il rischio che si corre è simile a quello descritto in precedenza: accorgersi troppo tardi che esiste un problema introdotto all’inizio del processo di sviluppo.

“Con il modello DevSecOps i test di sicurezza vengono effettuati nel corso dello sviluppo stesso” prosegue Marcis “verificando che non ci siano vulnerabilità o componenti non aggiornati nell’applicazione”.

Il processo si basa sul rilascio di diverse versioni dell’applicazione, con frequenza quotidiana o addirittura superiore. “Un tempo una procedura simile sarebbe stata considerata una perdita di tempo, ma oggi tutti i vantaggi sono evidenti. Anche perché nei processi di sviluppo vengono spesso coinvolti soggetti esterni per curare aspetti specifici”.

Il paragone che rende meglio il concetto è quello della costruzione di una casa in cui carpentieri, muratori, idraulici ed elettricisti si consultano continuamente per ottimizzare il rispettivo lavoro. Magari impiegheranno qualche ora in più, ma non correranno il rischio di dover buttare giù un muro portante perché si sono accorti troppo tardi che impedisce di far passare tubazioni indispensabili per il funzionamento del sistema idrico”.

La modalità DevSecOps, in definitiva, permette di parlare di un vero “Security by design”, cioè di un livello di sicurezza garantito già a livello di progettazione. “In termini di costi, intervenire su un problema di sicurezza in fase di sviluppo costa venti volte meno di quanto costi farlo a sviluppo terminato” sottolinea Marcis.

Per capire il reale impatto pratico, è bene anche tenere in considerazione di alcuni aspetti che caratterizzano i processi di sviluppo più avanzati. Il primo riguarda il fatto che lo stesso processo viene frequentemente esternalizzato, affidando porzioni di sviluppo a soggetti esterni.

Una scelta che consente di risparmiare tempo ma che ha un impatto anche sulle caratteristiche dei software a livello di sicurezza. L’uso di porzioni di codice o di librerie utilizzate anche in altre applicazioni, infatti, rappresentano sempre un rischio. Prima di tutto perché può succedere di “trascinarsi dietro” una falla di sicurezza preesistente, in secondo luogo perché si rischia di essere colpiti da attacchi tramite exploit che sono stati ideati per colpire un’altra applicazione che usa gli stessi componenti.

Per quanto riguarda i controlli di sicurezza, normalmente viene preferita la soluzione “casalinga”, affidandone la valutazione a esperti interni. Nell’era dell’Intelligenza Artificiale e dell’automazione, però, si registrano anche situazioni “ibride” in cui le verifiche a livello di security vengono effettuate con strumenti forniti da terze parti che analizzano in maniera del tutto automatica il codice degli applicativi per verificarne il livello di sicurezza.

“L’automatizzazione di questi processi permette di eseguire scansioni a ogni passaggio, in modo che a ogni release sia assegnato un punteggio che, se positivo, certifica la possibilità di implementare il software. In caso contrario, si torna indietro per correggere quello che non va” conclude Salvatore Marcis.

Condividi l'articolo