In che modo DevSecOps dà potere agli sviluppatori cittadini

Entro il 2025, totale creazione di dati globali raggiungerà i 181 zettabyte. Per le aziende, questi dati rappresentano una risorsa che consente loro di sfruttare una varietà di piattaforme tecnologiche per creare esperienze cliente altamente personalizzate che generano fidelizzazione e attraggono nuovi affari. Tuttavia, queste esperienze dipendono dalle infrastrutture cloud che utilizzano modalità di sicurezza condivise. È qui che sta il rischio, ed è in aumento man mano che la tecnologia cresce fino a incorporare un nuovo esercito di sviluppatori cittadini che utilizzano piattaforme low-code e no-code.

Comprendere e superare la mentalità dell'ereditarietà 

Gartner stima che entro il 2025, il 70% delle applicazioni aziendali sarà realizzato da piattaforme low-code e no-code come Salesforce e ServiceNow. Rispondere con una mentalità basata sull’ereditarietà è un modo sicuro per predisporre più di due terzi delle app aziendali al fallimento.   

La “mentalità ereditaria” è un descrittore appropriato per i problemi che affliggono le infrastrutture. Ricorda i bambini ricchi e viziati che dipendono interamente dal lavoro svolto e dalle persone che li hanno preceduti. Questo non è un buon modo per costruire un'eredità, ed è un modo altrettanto pessimo per costruire un sistema.

Quando hai una mentalità legacy, presumi che l'infrastruttura sia impostata. La piattaforma è sicura e la sicurezza è integrata. La fiducia viene data per scontata semplicemente perché la tecnologia esisteva già prima dell'amministratore.

Questa mentalità ereditaria affligge le piattaforme low-code e no-code. Gli utenti fanno affidamento sulla sicurezza di una piattaforma che li trasporti attraverso un'intera infrastruttura aziendale. Invece, la sicurezza di quella piattaforma dovrebbe applicarsi solo a quella piattaforma.

Supponiamo che gli sviluppatori Salesforce creino un programma di assegnazione automatizzato per nuovi lead. Lo usano all'interno di Salesforce per incarichi interni e va bene. Possono fare affidamento sulla sicurezza della piattaforma. Decidono di espanderlo per migliorare l'automazione. Collegano quel programma a un CRM rivolto all'esterno come ServiceNow, SAP o Oracle. La mentalità ereditaria prende il sopravvento: Salesforce è sicuro. ServiceNow, SAP o terze parti sono al sicuro.

Quindi, Salesforce + terze parti = sicuro.

Ma c'è molta incognita in quel segno più. Come collegare in modo sicuro e conforme il programma interno creato in Salesforce al programma esterno creato nella piattaforma di terze parti? C'è molto spazio per errori in quel singolo carattere.  

E questa è solo una connessione. Molti programmi creati in Salesforce ne toccano centinaia di altri. Si tratta di centinaia di incognite trattate come il segno più descritto sopra da persone che hanno poca o nessuna esperienza di sviluppo.  

L’unica soluzione è riportare questo sviluppo con i piedi per terra con un ritorno ai principi DevSecOps.

Stabilire il quadro DevSecOps 

DevSecOps i framework sono stati scritti, riscritti e riscritti da quando il concetto è stato creato. Non è necessario reinventare la ruota quando si stabiliscono, soprattutto quando SAFECode e la Cloud Security Alliance ha costruito sei pilastri:

1. Responsabilità collettiva: La sicurezza è responsabilità di ogni persona all'interno dell'azienda, ma le persone non possono soddisfare standard che non conoscono. I leader dovrebbero essere incaricati di guidare la politica di sicurezza informatica e garantire che sia diffusa in tutta l’azienda.  
2. Collaborazione e integrazione: La conoscenza deve essere condivisa e trasferita. Metà del motivo per cui le imprese cadono nella mentalità legacy è che tutti coloro che conoscevano il vecchio sistema se ne sono andati. La condivisione continua delle conoscenze aiuta a eliminare questo problema.
3. Implementazione pragmatica: L'implementazione pragmatica si lega all'esperienza dello sviluppatore. I processi difficili, banali e ingombranti non vengono seguiti a lungo. La sicurezza dovrebbe essere integrata nelle pratiche di sviluppo, ovvero ogni riga di codice richiede una riga di test. Un'impresa ad alte prestazioni potrebbe spingersi oltre utilizzando uno strumento per automatizzare ogni riga di codice di test.
4. Conformità e sviluppo: I requisiti di conformità dovrebbero guidare il processo di sviluppo in modo da non consentire agli sviluppatori di discostarsi da essi. Uno sviluppatore per un istituto finanziario, ad esempio, lavorerebbe su una piattaforma progettata per essere conforme al Gramm-Leach-Bliley Act. Lo sviluppatore non deve conoscere i singoli dettagli dell'atto per essere conforme perché sono integrati nella piattaforma.  
5. Automazione: Le attività prevedibili, ripetibili e ad alto volume dovrebbero essere automatizzate quando possibile per rimuovere l'onere dagli sviluppatori e ridurre il rischio di errore umano.
6. Controllo: Le moderne infrastrutture cloud cambiano e crescono. È fondamentale tenerne traccia, idealmente attraverso una qualche forma di orchestrazione che consenta una visione immediata di tutte le varie interconnessioni.

In un codice basso o assente ambientale, questi pilastri non sono così semplici come ci si aspetterebbe. Le persone che utilizzano questi strumenti sono spesso esperti aziendali con poca familiarità con i fondamenti di DevSecOps.

Unire persone, processi e tecnologia

L’uso di piattaforme low-code e no-code può effettivamente aiutare a colmare questo divario di competenze. I dipendenti vogliono apprendere nuove competenze. Le aziende possono supportare tutto ciò stabilendo un framework DevSecOps incentrato su persone, processi e tecnologia. 

• Processi: In un ambiente zero-trust, gli sviluppatori low-code e no-code non devono preoccuparsi di creare connessioni che mettono in pericolo l'integrità del sistema perché non sono in grado di farlo. Non hanno autorità di base al di fuori del loro sistema isolato.  
• Persone: Una cultura della responsabilità è diversa da una cultura della colpa. Responsabilità significa che le persone si sentono a proprio agio nel denunciare un problema o un errore perché l’attenzione è rivolta al problema, non alla persona.
• Tecnologia: La tecnologia rappresenta il principale ostacolo alla corretta implementazione dei principi DevSecOps perché è fuori dal controllo degli sviluppatori. Devono utilizzare ciò che l'organizzazione dà loro. Se questa tecnologia non funziona, gli sviluppatori troveranno soluzioni alternative che non sono né sicure né protette. In sostanza, la tecnologia diventa un grande generatore IT ombra.

Viviamo in un momento entusiasmante per lo sviluppo. Sempre più persone hanno l'opportunità di creare software, testare strategie e migliorare il valore aziendale. Ma da ciò deriva il rischio. Le imprese che cercano modi per scaricare tale rischio sulla tecnologia manterranno il loro sviluppo con i piedi per terra, lasciando spazio all’esplorazione.