DevSecOps rivoluziona la sicurezza nello sviluppo software #finsubitoagevolazioni

Nell’attuale era digitale, la cultura del software e la sua produzione sono fortemente collegati ai concetti di sicurezza informatica e, per questo motivo la garanzia di sicurezza diventa una componente fondamentale delle DevOps.

L’adozione di prassi di DevSecOps infatti, riduce i tempi, aumenta la velocità di distribuzione e aiuta gli sviluppatori a creare applicazioni sicure e di alta qualità.

La GSA americana definisce formalmente la DevSecOps come una pratica culturale e ingegneristica che apre la collaborazione tra organizzazioni di sviluppo, sicurezza e operazioni che utilizzano l’automazione per concentrarsi sulla distribuzione rapida e frequente di infrastrutture e software.

Comprende l’immissione al rilascio del software e gestisce tali flussi in modo prevedibile, trasparente e con un intervento/sforzo umano minimo (Fonte “guida alla DEVSECOPS”).

Le maggiori sfide del DevSecOps

Abbiamo chiesto a chi si occupa giornalmente di sviluppo sicuro, di commentare alcune indicazioni per affrontare la sfida legate allo sviluppo sicuro lungo tutto il ciclo di vita del codice.

Luca Famà, application security consultant in SORINT.lab, spiega che: “tra le sfide maggiori per un software sicuro c’è la complessità delle applicazioni moderne (in termini di logica e design delle app, integrazioni, framework, n.d.r.), che causa una espansione della superficie di attacco e la presenza di un maggior numero di potenziali punti di ingresso per i criminali. Inoltre, lo sviluppo di applicazioni con la metodologia agile, complica le questioni di sicurezza a causa dell’esigenza di velocità di delivery nella creazione di nuove funzionalità.

Ne consegue uno sviluppatore sempre troppo sotto pressione, che spesso mette in secondo piano la sicurezza per prioritizzare nuovi sviluppi. Infine, non va inoltre dimenticato che le app al giorno d’oggi usano molto il software open source, tra il 70 e il 90% circa, per fini di riuso, ma questa pratica si porta dietro sia aggiornamenti sia purtroppo anche vulnerabilità.

Il caso della backdoor nella libreria Xz per Linux, ha sollevato il problema degli errori introdotti volutamente; E in effetti come poter sapere se un contributor di software open source è un attore malevolo? Nel dubbio si devono analizzare sempre le vulnerabilità durante lo sviluppo”.

Sono proprio le buone pratiche di sicurezza applicate durante il ciclo di vita del software a fare la differenza.

Le pratiche di sicurezza nel ciclo di sviluppo del codice

Per la DevSecOps Luca Famà spiega che: “il concetto base è di spostare quanto prima possibile una serie di processi di sicurezza nel ciclo di vita attuando il cosiddetto ‘shift left di security’, a partire dal design del codice.

Si parte da un modello delle possibili minacce e mitigazioni da inserire. Questo fornisce informazioni sul “perimetro di fiducia” (Trust boundary dell’applicazione).

Si procede poi alla verifica delle sorgenti affidabili, per evidenziare i punti di interesse di un attaccante. Catalogate le minacce, si prioritizzano quelle più severe e quindi si introducono mitigazioni per minimizzare i rischi.

Come secondo passo nell’implementazione si introduce l’automazione per l’analisi del codice (SAST- static application security testing) e delle dipendenze da importazione di altre fonti software e versioni di software; grazie a strumenti di analisi della composizione (SCA- composition analysis) si mappano le vulnerabilità che vengono incluse insieme al codice.

È utile integrare almeno questi due strumenti nelle pipeline di sviluppo, inserendo anche gate di sicurezza (che operano come asticelle di sicurezza superate le quali bloccare la build del codice). Per usare tali strumenti è opportuno adottare una piattaforma di repository del codice per poter tenere sotto controllo le varie componenti.

I fornitori dovrebbero comunque sempre dare evidenza di come sviluppano con report di tenuta sotto controllo. Anche nei contratti sarebbe utile inserire dei vincoli sulla sicurezza del codice e sugli strumenti di controllo della sicurezza.

Nella fase di release il dato è impacchettato con artefatti in applicazioni containerizzate (specialmente per le applicazioni in Cloud). Anche in questa casistica sono necessari test e strumenti di analisi usando strumenti di container security.

Durante la fase di deploy sono previsti test di runtime, analisi dinamica del codice da fare in un ambiente di preproduzione e l’analisi della robustezza del codice, con una simulazione di attacco. Si possono aggiungere attività di fuzzyng, e in ogni punto dove l’applicazione acquisisce dati, si verifica il controllo errori.

I test delle API sono dello stesso tipo. Infine, durante la fase di monitoraggio avvengono analisi (tipicamente erogate da un security operation center) che controlla che l’applicazione sia disponibile, integra, rilevando incidenti di sicurezza ed avviandone la gestione.

Outsourcing dello sviluppo: cosa fare

Nel caso in cui si ricorra a sviluppi da un fornitore esterno, è necessario chiedere evidenze sui test di sicurezza e del risultato ottenuto.

Luca Famà chiarisce come sia un punto delicato, ma suggerisce di stabilire un canale di comunicazione fra chi richiede codice (team di security) e il team di sviluppo definendo dei gate di sicurezza concordati.

Awareness e cultura della sicurezza