Come adottare un approccio Shift Left grazie all'integrazione continua

L'approccio Shift Left sposta i test all'inizio del ciclo di sviluppo del software ("shift left" significa "spostamento a sinistra" in una linea immaginaria). Se i test di sicurezza vengono eseguiti quando il codice è pronto per la produzione, risolvere i problemi può rivelarsi difficile e spesso impossibile a causa delle tempistiche ristrette. Questo può causare ritardi nei passaggi di consegna, problemi di sicurezza e silo di comunicazione fra i team di sicurezza e gli altri gruppi di lavoro DevOps.

Poiché molte aziende puntano ad assimilare un approccio più orientato al DevSecOps, è fondamentale eseguire i test di sicurezza sin dalle prime fasi del ciclo di sviluppo. Per farlo è necessario integrarli nelle pipeline di deployment, in modo che il codice venga testato continuamente, non solo in relazione agli altri commit presenti nel repository condiviso ma anche in termini di sicurezza.

L'integrazione continua (CI) è un processo che migliora la qualità del codice attraverso le pipeline di deployment. La sicurezza può essere integrata in queste pipeline sin dalle prime fasi del processo, aiutando gli sviluppatori a tenere questo aspetto in considerazione fin dall'inizio.

Implementare la sicurezza nelle pipeline di integrazione continua

Il test statico di sicurezza delle applicazioni (SAST) permette di automatizzare la sicurezza attraverso l'integrazione continua. Il SAST analizza il codice sorgente e consente agli sviluppatori di risolvere i problemi all'inizio del ciclo di sviluppo software.

Nella CI/CD di GitLab, la pipeline di deployment controlla il report SAST e confronta le vulnerabilità fra i rami di origine e quelli di destinazione. I risultati vengono visualizzati nella richiesta di merge.

Il test dinamico della sicurezza delle applicazioni (DAST) spesso opera insieme al SAST. Mentre il SAST analizza il codice sorgente, il DAST esegue un'analisi degli errori di runtime nelle applicazioni eseguite. Dopo il deployment, l'applicazione è esposta a nuove forme di rischi per la sicurezza, come il cross-site scripting o le vulnerabilità Broken Authentication.

Proprio come avviene per il SAST, GitLab controlla il report DAST, confronta le vulnerabilità fra i rami di origine e quelli di destinazione e visualizza i risultati. Tuttavia, il raffronto prende in considerazione solo l'ultima pipeline eseguita per il commit di base del ramo di destinazione.

Fra gli altri tipi di test di sicurezza figurano quello interattivo delle applicazioni (IAST) e l'autoprotezione delle applicazioni di runtime (RASP). IAST posiziona un agente all'interno di un'applicazione, mentre RASP funziona più come uno strumento di sicurezza nell'applicazione in grado di rispondere agli attacchi in tempo reale.

Ridurre la complessità della toolchain

Oltre a richiedere una lunga manutenzione, una toolchain complessa può esporre il sistema a rischi per la sicurezza. Molti team DevSecOps utilizzano plug-in, script o integrazioni personalizzate hardcoded per integrare i propri strumenti. Poiché alcuni di questi devono essere eseguiti manualmente, queste toolchain sono soggette a errori umani. Inoltre, avere a disposizione diversi strumenti significa doversi autenticare più spesso e andare incontro a un numero maggiori di autorizzazioni e requisiti di sicurezza nonché meno visibilità nel ciclo di sviluppo del software. Questi livelli di astrazione rendono più difficile non solo individuare i problemi, ma anche risolverli.

Un sistema complesso è caratterizzato da diversi punti critici. Le aziende che desiderano adottare un approccio Shift Left possono mitigare in parte questa complessità, permettendo ai team di sicurezza e conformità di partecipare al ciclo di sviluppo in modo più agevole. Inoltre, una toolchain complessa o un ambiente plug-in possono determinare pipeline fragili che richiedono particolare attenzione.

Protezione avanzata per i sistemi di integrazione continua

L'hardening o protezione avanzata è il processo di protezione di un sistema che ne riduce la superficie di vulnerabilità. La protezione avanzata delle checklist, simile alla riduzione della complessità della toolchain finalizzata alla mitigazione delle fonti di rischio, permette alle organizzazioni di esaminare i propri sistemi interni per assicurarsi che le best practice sulla sicurezza vengano rispettate.

Una delle pratiche più diffuse suggerisce di rafforzare i sistemi che ospitano i repository degli artefatti di origine e del processo di sviluppo, i server CI e di distribuzione continua (CD) e i sistemi che ospitano gli strumenti di gestione, programmazione, deployment e rilascio della configurazione. Assicurati che il tuo team sappia quali attività vengono svolte on-premise, quali altre nel cloud e come incidano nell'insieme sui flussi di lavoro.

La protezione avanzata del sistema di integrazione continua, oltre a incorporare le analisi di sicurezza nelle pipeline di deployment, può agevolare l'adozione di un approccio Shift Left. I team DevOps esperti applicano naturalmente i test di sicurezza nel loro processo di integrazione continua e adottano l'approccio Shift Left. Invece di pensare alla sicurezza solo in un secondo momento, i team DevSecOps la considerano una priorità.