"Shift-left": Insidie e come evitarle

Gli sviluppatori di app svolgono un ruolo fondamentale nel garantire il successo delle aziende e nel mantenere la competitività. Ma la filosofia del "shift-left", che ha dominato il pensiero su DevOps (o meglio, DevSecOps), ha avuto l'effetto di lasciarli sovraccarichi di lavoro, stressati e stanchi di essere incolpati per ogni problema o vulnerabilità che appare al momento del deployment delle app su cui le organizzazioni fanno affidamento.

Soprattutto ora, quando il talento degli sviluppatori è sempre più difficile da trovare, il ricambio dei dipendenti e la perdita di produttività che deriva dagli sviluppatori esauriti è terribilmente costoso. Fortunatamente, questo è un problema che può essere risolto.

Cos'è il shift-left?

Nei tempi antichi, gli sviluppatori codificavano le app, e poi gli ingegneri QA avrebbero verificato le app per funzionalità e facilità d'uso, e poi i team di sicurezza le avrebbero controllate per le vulnerabilità. E solo dopo che tutto è stato controllato le app sarebbero state distribuite per l'uso operativo.

Nessuno ha più quel tipo di tempo. Abbiamo bisogno che queste app siano operative ora ora ora! La soluzione era, ed è, shift-left, che si riferisce allo spostamento di QA e sicurezza a sinistra nel ciclo di vita dello sviluppo software (SDLC) (precedentemente) lineare. QA e sicurezza sarebbero quindi affrontati durante lo sviluppo iniziale dell'app, o anche nella fase di progettazione.

Teoria vs. pratica

Un'idea eccellente in linea di principio. In linea di principio, significava che gli ingegneri QA, gli esperti di sicurezza e gli sviluppatori avrebbero lavorato insieme durante tutto il SDLC, collaborando in tempo reale per accelerare drasticamente il processo e distribuire le app prima.

In pratica, tuttavia, questo approccio significa fin troppo spesso che i team di sviluppo sono ritenuti responsabili di cose che esulano dalla loro area di competenza. Le questioni culturali rendono più impegnativo del previsto raggiungere quel livello di collaborazione, e in molti casi ai sviluppatori sono stati affidati i compiti di QA e sicurezza oltre alla loro descrizione di lavoro di base.

Ovviamente, non c’è niente di male nel chiedere agli sviluppatori di pensare seriamente alla sicurezza fin dall'inizio. Se riescono a identificare una potenziale vulnerabilità nella fase di progettazione, allora può essere risolta facilmente. Mentre se viene alla luce solo dopo che l'app è stata codificata e compilata, allora potrebbe essere un processo molto più lungo per risolverla, specialmente se il codice vulnerabile ha anche delle dipendenze codificate. 

Come spiega Shannon McFarland in questo post sul blog di Cisco, i benefici previsti del shift-left sono significativi: 

1. Collaborazione migliorata, poiché i team di QA, sicurezza e sviluppo lavorano insieme e tutti migliorano la loro comprensione dell'intero processo SDLC
2. Costi ridotti grazie all'identificazione e alla risoluzione dei problemi nelle prime fasi del processo, il che significa più veloce e più facile
3. Aumento della sicurezza poiché gli sviluppatori imparano a integrare la sicurezza nel processo di progettazione
4. Migliore qualità del software poiché è meno probabile che problemi di qualità sopravvivano al deployment operativo

Ma al posto di questi benefici, troppo spesso i risultati sono:

1. Aumento del carico di lavoro poiché gli sviluppatori assumono nuovi compiti per i quali non sono formati, senza alcuna riduzione del loro carico di lavoro esistente
2. Apprendimento continuo come sviluppatori è necessario per padroneggiare costantemente nuovi strumenti, processi e tecnologie man mano che più cose vengono spostate prima nel ciclo di vita dello sviluppo.
3. Burnout, poiché gli sviluppatori si trovano sotto una pressione crescente per creare app sicure e di alta qualità ancora più velocemente di prima
4. Dinamiche di squadra interrotte poiché i confini organizzativi tradizionali si confondono.

Da lineare a continuo

Come sostiene Melinda Marks in questo articolo di TechTarget, parte del problema con lo shift-left è che si basa su una comprensione tradizionale e lineare dell'SDLC. Ma i processi di sviluppo basati sul cloud di oggi sono dominati da pipeline di integrazione continua/consegna continua (CI/CD).

Per dirlo in modo troppo semplice, questo significa che nuove funzioni e caratteristiche—nuovi rami di una base di codice in costante crescita—vengono continuamente sviluppati, distribuiti e integrati nelle app esistenti. Non c'è un momento in cui l'app è finita, timbrata "APPROVATA" sia dai team QA che di sicurezza e distribuita per andare e fare del bene nel mondo. Le app critiche per il business sono sempre in uno stato continuo di divenire.

Questo rende molto più difficile indicare un punto lungo un processo lineare e dire "Ora faremo QA qui, invece che più tardi". E significa che sviluppatori, ingegneri QA e specialisti della sicurezza stanno tutti esercitando le loro abilità allo stesso tempo, in un ciclo continuo di innovazione e miglioramento.

Far funzionare

Leadership, responsabilità chiaramente definite, una cultura senza colpe e il consenso di tutti gli stakeholder sono le chiavi di una strategia shift-left di successo che ottiene i benefici senza gli svantaggi dell'esaurimento degli sviluppatori e tutti i costi che ne derivano.

Questo richiede forti abilità organizzative, come essere in grado di progettare un processo che delinei specificamente le responsabilità di ciascun team, piuttosto che limitarsi a dire che gli sviluppatori devono fare più test QA e audit di sicurezza. E richiede molte abilità di leadership soft, come incoraggiare tutti gli stakeholder a partecipare a post-mortem senza colpe, insegnare a tutti a ricevere e dare critiche costruttive con grazia e gestire l'integrazione e la collaborazione di team che tradizionalmente hanno operato in silos separati.