Abbracciare la prossima generazione di sviluppatori aziendali

I team di sicurezza si impegnano costantemente per la condivisione delle idee e l'allineamento all'interno dell'azienda. I leader esperti della sicurezza spesso descrivono come la sicurezza debba essere al servizio dell'azienda e come dipenda dal consenso dell'azienda sull'importanza della sicurezza per avere successo. Di conseguenza, i team di sicurezza investono molto nella sensibilizzazione sulla sicurezza, nell’educazione degli utenti aziendali e nella spiegazione del motivo per cui la sicurezza è fondamentale per l’azienda e non può avere successo senza gli utenti aziendali.

Senza il consenso dei leader aziendali, i team di sicurezza possono applicare misure di sicurezza solo attraverso cancelli formali, controlli applicati e politiche aziendali che, senza un’adeguata comunicazione, possono spesso causare frustrazione e finire per peggiorare il problema del consenso aziendale. Tuttavia, quando i team aziendali vedono la sicurezza come un fattore abilitante per il business, il discorso cambia completamente. Le persone si rivolgono alla sicurezza per ottenere input nelle prime fasi del processo e i team di sicurezza possono concentrarsi sull'aiutarli a valutare dove investire i propri sforzi di sicurezza.

Questa dinamica è così fondamentale per le organizzazioni che spesso i leader della sicurezza concentrano la maggior parte dei loro sforzi sulla costruzione di rapporti con i leader aziendali per ottenere il consenso dei dirigenti. Nel migliore dei casi, ciò si traduce anche nel riavvicinamento delle unità aziendali e dei team di sicurezza. Con questo obiettivo, possiamo vedere quanto sia importante e trasformativo DevSecOps. All'improvviso, i team di sviluppo collaborano più facilmente e talvolta addirittura guidano gli sforzi per migliorare la sicurezza. L'effetto indiretto di avere più persone, ovvero sviluppatori, non solo professionisti della sicurezza, che pensano con una mentalità di sicurezza può trasformare la capacità del team di sicurezza di fare grandi passi avanti.

Un'organizzazione in cui molti sviluppatori comprendono e spingono per la sicurezza nel loro lavoro quotidiano è molto più propensa ad accettare progetti di sicurezza di grandi dimensioni come l'implementazione di un nuovo sistema di identità o l'applicazione del principio Zero Trust, anche se questi potrebbero richiedere un po' di pazienza da parte di utenti durante l'implementazione. Questo effetto indiretto potrebbe finire per essere molto più importante del fatto che ora disponiamo di test di sicurezza automatizzati come parte del CI/CD, anche se anche questi sono importanti.

Avvicinare gli sviluppatori alla mentalità della sicurezza

Una possibile spiegazione del successo di DevSecOps è il valore dell’automazione. Che si tratti di individuare errori di sintassi, identificare una dipendenza non sicura o rilevare segreti codificati, i test di sicurezza automatizzati aiutano gli sviluppatori a ottenere di più in meno tempo. L’argomentazione secondo cui l’automazione è la ragione per cui gli sviluppatori stanno saltando sul carro della sicurezza sembra implicare che gli sviluppatori abbiano sempre visto l’importanza della sicurezza ma non avessero le risorse per agire di conseguenza.

Sebbene l'automazione sia estremamente utile, trovo che il cambiamento di mentalità per alcuni team di sviluppo sia molto più grande di un semplice cambiamento nella discussione sulle risorse. Sempre più sviluppatori vedono la sicurezza come parte della loro responsabilità, piuttosto che come responsabilità di qualcun altro.

In questo caso si tratta di un cambiamento più grande della semplice riduzione dei costi legati all’applicazione di buone pratiche di sicurezza. I team di sicurezza hanno iniziato a parlare agli sviluppatori nel linguaggio degli sviluppatori, piuttosto che nel linguaggio della sicurezza. Questo è un punto cruciale. Invece di dipingere un bellissimo quadro di come dovrebbe funzionare la sicurezza, DevSecOps sposta la conversazione su un argomento molto più pratico: come possiamo fare un passo avanti verso il punto in cui sono effettivamente i nostri sviluppatori?

Tieni presente che l'obiettivo rimane lo stesso: guidare i team di sviluppatori verso una bella immagine di come dovrebbe funzionare la sicurezza. Tuttavia, è fondamentale partire dal lato pratico della discussione e contribuire a guidare ogni fase del viaggio piuttosto che descrivere un futuro che sembra lontano o addirittura impraticabile.

Spostando il dibattito sulla sicurezza nel linguaggio degli sviluppatori e incontrandoli dove si trovano, i team di sicurezza e gli sviluppatori ora condividono una mentalità di sicurezza, che aiuta sia nelle operazioni quotidiane che nei grandi passi avanti in materia di sicurezza che richiedono il consenso degli sviluppatori.

Sebbene il successo con gli sviluppatori sia importante, la sicurezza fatica ancora a ottenere la condivisione della mente per una porzione molto più ampia di dipendenti aziendali, vale a dire gli utenti aziendali. Possiamo applicare le lezioni apprese da DevSecOps per avvicinare gli utenti aziendali alla sicurezza?

I tempi stanno cambiando

Negli ultimi anni, le business unit hanno vissuto un cambiamento epocale portato avanti dalle piattaforme low-code/no-code. Acquisendo le competenze necessarie per facilitare i processi aziendali o creare autonomamente applicazioni personalizzate, le business unit hanno ridotto drasticamente la loro dipendenza dall'IT e continuano ad accelerare la trasformazione digitale. Principali società di analisi predire che la maggior parte delle applicazioni aziendali sarà sviluppata utilizzando low-code/no-code entro il 2025 e rivelano i sondaggi che gli utenti aziendali sono già gran parte (e in alcuni casi, la maggioranza) di costruttori low-code/no-code.

La tendenza degli utenti aziendali a diventare costruttori può rappresentare sia una sfida che un'opportunità per i team di sicurezza. Se lasciato fuori dall'ambito di responsabilità percepito della sicurezza, ciò porterà a una crescita significativa dello shadow IT. Tuttavia, rappresenta anche un’opportunità senza precedenti per coltivare una mentalità di sicurezza tra gli utenti aziendali. Se DevSecOps rendesse gli sviluppatori più attenti alla sicurezza, un equivalente low-code/no-code potrebbe fare lo stesso per gli utenti aziendali. Come nel caso degli sviluppatori, il cambiamento fondamentale che consiste nell’avvicinare gli utenti aziendali alla mentalità della sicurezza significherebbe aumentare drasticamente la condivisione della mentalità sulla sicurezza all’interno dell’organizzazione. Low-code/no-code presenta un'esperienza unica opportunità di sensibilizzazione sulla sicurezza.

Quando cerchiamo di cogliere l'opportunità di sensibilizzazione sulla sicurezza offerta dal low-code/no-code, dovremmo applicare le lezioni apprese da DevSecOps incontrando gli utenti aziendali ovunque si trovino. IL processo di sviluppo low-code/no-code differisce significativamente da DevOps pro-code. Molti utenti aziendali oggigiorno creano le proprie applicazioni e automatizzano i propri processi con low-code/no-code. I team di sicurezza dovrebbero familiarizzare con tali piattaforme e i relativi processi di sviluppo e imparare come parlare di sicurezza per tali applicazioni appositamente realizzate nella lingua madre dello sviluppo aziendale.

Il low-code/no-code è così diffuso tra gli utenti aziendali che viene già utilizzato per applicazioni business-critical all'interno di molte organizzazioni anche se i loro team di sicurezza non ne sono a conoscenza. Con gli analisti previsione considerando che il 70% delle nuove applicazioni aziendali sarà realizzato con low-code/no-code entro tre anni, è evidente che abbiamo una finestra di opportunità unica per influenzare il modo in cui queste applicazioni verranno realizzate. Ma, cosa ancora più importante, questa è un’opportunità per influenzare la prossima generazione di sviluppatori – vale a dire gli utenti aziendali – e il modo in cui penseranno alla sicurezza e al loro ruolo al suo interno.