Mi ha incuriosito un articolo letto l'altro giorno su CSO Online, intitolato "4 problemi di sicurezza per lo sviluppo low-code e no-code". La premessa dell'articolo era, essenzialmente, che le aziende devono stare attente alle soluzioni low-code, perché possono causare problemi di sicurezza.
Nell'articolo, l'autore Chris Hughes afferma: "Consentendo a più persone in un'azienda di sviluppare applicazioni, lo sviluppo low-code crea nuove vulnerabilità e può nascondere i problemi alla sicurezza".
Sono fondamentalmente in disaccordo con questa premessa. In particolare, non c'è nulla di intrinsecamente sicuro o insicuro nelle soluzioni low-code o no-code. La chiave di tutti i framework, i sistemi, i processi e le politiche di sviluppo delle applicazioni, manuali o automatizzati, è che sono sicuri nella misura in cui l'azienda investe per renderli tali.
È vero che riducendo il numero di persone nell'organizzazione in grado di creare applicazioni si riduce la probabilità che un'applicazione presenti una vulnerabilità di sicurezza. Tuttavia, secondo questa logica, il modo migliore per rendere sicure le applicazioni è ridurre le dimensioni del team di ingegneri in modo che produca meno applicazioni. Meno sono le applicazioni, meno sono i problemi di sicurezza che ne derivano. Pur essendo un'affermazione vera, non è affatto utile.
Questo argomento fornisce una visione limitata dello sviluppo delle applicazioni. Un buon CSO incoraggia la crescita dell'organizzazione piuttosto che soffocarla. Certo, un'organizzazione più grande e in rapida crescita deve affrontare problemi di sicurezza più difficili. Migliorare la sicurezza delle applicazioni concentrandosi sulla limitazione di ciò che un'organizzazione può costruire non è il modo in cui un CSO efficace può contribuire al successo di un'azienda. I migliori CSO trovano il modo di risolvere i problemi di sicurezza inerenti alle opportunità di crescita.
Lo stesso vale per il low-code. Consentendo ai cosiddetti citizen developer di creare ed espandere applicazioni utili per l'azienda, la vostra azienda ne favorisce la crescita. Il CSO e il resto del team di leadership IT dovrebbero concentrarsi sul rendere più facile questo processo, fornendo piattaforme di sviluppo low-code di alta qualità, affidabili e sicure da utilizzare per gli citizen developer. Questo è il modo migliore per evitare le vulnerabilità della sicurezza.
Come fare? Invece di opporsi all'uso di strumenti di sviluppo low-code, lavorate per portare nella vostra azienda strumenti di sviluppo low-code di livello aziendale, consentendo agli utenti di imparare come funzionano e incoraggiandone l'uso. Poi, allo stesso tempo, lavorate per assicurarvi che l'ambiente fornito da questi strumenti sia sicuro e protetto.
Invece di relegare lo sviluppo low-code nel torbido mondo dello shadow IT, questa strategia mette il low-code in primo piano e ne incoraggia l'uso, sotto la supervisione del CSO, del dipartimento di sicurezza e del resto dell'organizzazione IT aziendale, consentendo alla vostra azienda di crescere. Questa crescita sfrutta il valore di una forza lavoro di citizen developer che rafforza, migliora e moltiplica il valore del resto dell'organizzazione di sviluppo.
Il Low-Code è solo un altro strumento
Pensate agli inizi dell'informatica, quando gli sviluppatori scrivevano i loro programmi in linguaggio assembly o in linguaggio macchina. Lo sviluppo in questi linguaggi di basso livello era difficile e richiedeva sviluppatori molto esperti per realizzare i compiti più semplici. Oggi, la maggior parte del software viene sviluppata utilizzando linguaggi di programmazione di alto livello, come Java, Ruby, JavaScript, Python e C++. Perché? Perché questi linguaggi di alto livello consentono agli sviluppatori di scrivere più facilmente codice più potente e di concentrarsi su problemi più grandi senza doversi preoccupare delle complessità di basso livello della programmazione in linguaggio macchina.
L'arrivo dei linguaggi di programmazione di alto livello, come illustrato nella Figura 1, ha migliorato la programmazione in linguaggio macchina e in linguaggio assembly e in generale ha permesso con meno codice, ottenere di più. Questo è stato visto come un enorme miglioramento nella capacità di realizzare più velocemente applicazioni più grandi e migliori. Lo sviluppo del software era ancora un'attività altamente specializzata, che richiedeva competenze e tecniche altamente specializzate. Ma sempre più persone potevano imparare questi linguaggi e le fila degli sviluppatori di software aumentavano. Era nata l'era dello sviluppatore di software produttivo.
Alla fine gli sviluppatori hanno iniziato a scrivere applicazioni più grandi e complesse. Hanno iniziato a creare piattaforme di programmazione, framework e strumenti per migliorare le loro capacità di sviluppo. Framework come ASP.NET, Ruby on Rails, jQuery, Spring e React.js hanno permesso agli sviluppatori di creare più facilmente applicazioni di livello superiore. Poi, i servizi SaaS e cloud hanno aggiunto altre funzionalità all'arsenale degli sviluppatori.
Tutti questi strumenti e servizi di livello superiore, come illustrato nella Figura 2, hanno migliorato l'esperienza di sviluppo e hanno proseguito la tendenza a ridurre il codice per ottenere di più. Si è trattato di un enorme miglioramento nella capacità di realizzare più rapidamente applicazioni ancora più complesse. Non solo era più facile creare applicazioni di alto valore, ma richiedeva anche meno formazione per diventare uno sviluppatore esperto. Meno formazione significava che c'erano più sviluppatori di software disponibili. È nata l'era del SaaS e delle applicazioni basate sul cloud.
Il tempo passa e gli sviluppatori hanno iniziato a scrivere applicazioni più grandi e complesse. L'intelligenza artificiale e le capacità di apprendimento automatico iniziano a diffondersi e gli strumenti low-code e no-code aumentano la capacità dello sviluppatore di creare applicazioni più complesse. Questi strumenti, come illustrato nella Figura 3, potenziano le capacità di altri strumenti di sviluppo, continuando la tendenza a consentire l'utilizzo di meno codice per ottenere di più. Inoltre, aprono lo sviluppo a sviluppatori meno esperti. Ora anche chi non ha una formazione diretta e mirata come sviluppatore può creare applicazioni che svolgono compiti avanzati. È nata l'era del citizen developer.
Non c'è nulla di nuovo o di innovativo nella figura del citizen developer. È solo l'ultima iterazione dell'evoluzione del ruolo dello sviluppatore di software. Non c'è nulla in questa progressione dello sviluppo del software che renda il low-code o il no-code più o meno pericoloso, più o meno sicuro, più o meno utile di qualsiasi altro miglioramento dello sviluppo che lo ha preceduto.
Dire che gli strumenti low-code e no-code sono fondamentalmente meno sicuri o meno utili o meno sicuri degli strumenti precedenti è ipocrita. Si tratta di un insieme di strumenti in evoluzione di cui tutte le aziende hanno bisogno e da cui dipenderanno man mano che andremo avanti.
La supererà anche il Low-Code
Se il low-code non differisce da altri miglioramenti dell'ambiente di sviluppo, allora perché c'è tanto scalpore contro il low-code?
Non è una cosa insolita o inaspettata. A suo tempo, ognuno di questi nuovi livelli ha affrontato le stesse resistenze. Non è passato molto tempo da quando "non osavamo" prendere in considerazione il cloud per l'uso dell'IT aziendale, o considerare l'uso di React per un'applicazione aziendale seria. Ricordo anche i giorni in cui Java era l'unico linguaggio considerato abbastanza sicuro per lo sviluppo IT aziendale.
E che dire della preoccupazione che il low-code consenta lo shadow IT? Beh, non è passato molto tempo da quando il cloud computing era considerato shadow IT, o quando una "piattaforma nuova e inedita" come Ruby on Rails o React poteva essere utilizzata solo per applicazioni non ufficiali.
Gli strumenti di sviluppo low-code, no-code e AI sono qui per restare e continueranno a crescere di importanza. I reparti IT e i reparti di sicurezza delle aziende rimarranno indietro se non si impegneranno per contribuire alla crescita di queste piattaforme, anziché trascinarle e sperare che spariscano.
Se gestito in modo appropriato, il low-code non comporta alcun rischio di sicurezza aggiuntivo rispetto a qualsiasi altra piattaforma, sistema o ambiente di sviluppo. Non comporta ulteriori rischi operativi o costi non gestiti. Il segreto è gestirlo in modo appropriato. Se si permette che il low-code diventi un contenitore per lo shadow IT, allora può essere altrettanto insicuro di qualsiasi altro progetto di shadow IT. Se si permette al low-code di diventare non monitorato e non controllato, allora può essere altrettanto insicuro di qualsiasi altro processo non monitorato e non controllato.
Gli strumenti e le piattaforme di sviluppo low-code sono maturati al punto da poter essere affidabili. Ciò è particolarmente vero quando si utilizzano sistemi low-code di alta qualità e di livello aziendale di fornitori affermati.
Di Lee Atchison