Leader di pensiero

Superare le principali sfide di sicurezza dello sviluppo low-code/no-code guidato da AI

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

Le piattaforme di sviluppo low-code hanno cambiato il modo in cui le persone creano soluzioni personalizzate per aziende, tra cui app, flussi di lavoro e copiloti. Questi strumenti consentono ai citizen developer di lavorare in un ambiente più agile per lo sviluppo di app. L’aggiunta di AI a questo mix ha ulteriormente migliorato questa capacità. Il fatto che non ci siano abbastanza persone all’interno di un’organizzazione che abbiano le competenze (e il tempo) per costruire il numero di app, automazioni e così via necessarie per spingere l’innovazione in avanti ha dato origine al paradigma low-code/no-code. Ora, senza la necessità di una formazione tecnica formale, i citizen developer possono sfruttare piattaforme user-friendly e AI generativa per creare, innovare e distribuire soluzioni guidate da AI.

Ma quanto è sicura questa pratica? La realtà è che sta introducendo una serie di nuovi rischi. Ecco la buona notizia: non è necessario scegliere tra sicurezza e l’efficienza che l’innovazione aziendale fornisce.

Un passo oltre l’ambito tradizionale

I team IT e di sicurezza sono abituati a concentrare i loro sforzi sulla scansione e la ricerca di vulnerabilità scritte nel codice. Si sono concentrati sul garantire che gli sviluppatori costruissero software sicuri, assicurandosi che il software fosse sicuro e poi – una volta in produzione – monitorandolo per deviazioni o per qualcosa di sospetto dopo i fatti.

Con la nascita del low code e no code, più persone che mai stanno costruendo applicazioni e utilizzando l’automazione per creare applicazioni – al di fuori del processo di sviluppo tradizionale. Queste sono spesso persone con poca o nessuna esperienza di sviluppo software, e queste app vengono create al di fuori della visibilità della sicurezza.

Ciò crea una situazione in cui l’IT non sta più costruendo tutto per l’organizzazione, e il team di sicurezza manca di visibilità. In un’organizzazione grande, potresti ottenere alcune centinaia di app costruite in un anno attraverso lo sviluppo professionale; con il low/no code, potresti ottenere molto più di quello. Sono molte potenziali app che potrebbero passare inosservate o non monitorate dai team di sicurezza.

Una ricchezza di nuovi rischi

 Alcune delle potenziali preoccupazioni di sicurezza associate allo sviluppo low-code/no-code includono:

  1. Non nell’ambito dell’IT – come appena menzionato, i citizen developer lavorano al di fuori dei confini degli IT professionali, creando una mancanza di visibilità e sviluppo di app ombra. Inoltre, questi strumenti consentono a un numero infinito di persone di creare app e automazioni in pochi clic. Ciò significa che c’è un numero sconosciuto di app che vengono create a ritmo serrato da un numero sconosciuto di persone, tutto senza che l’IT abbia una visione completa.
  2. Nessun ciclo di vita di sviluppo software (SDLC) – Sviluppare software in questo modo significa che non c’è un SDLC in atto, il che può portare a incoerenza, confusione e mancanza di responsabilità, oltre ai rischi.
  3. Sviluppatori principianti – Queste app sono spesso costruite da persone con meno competenze tecniche e esperienza, aprendo la porta a errori e minacce di sicurezza. Non pensano necessariamente alle implicazioni di sicurezza o di sviluppo nel modo in cui un professionista o qualcuno con più esperienza tecnica farebbe. E se viene trovata una vulnerabilità in un componente specifico che è incorporato in un gran numero di app, ha il potenziale di essere sfruttata in più istanze
  4. Pratiche di identità scorrette – La gestione delle identità può anche essere un problema. Se si vuole autorizzare un utente aziendale a costruire un’applicazione, la cosa numero uno che potrebbe fermarlo è la mancanza di autorizzazioni. Spesso, ciò può essere aggirato, e ciò che accade è che un utente potrebbe utilizzare l’identità di qualcun altro. In questo caso, non c’è modo di capire se hanno fatto qualcosa di sbagliato. Se si accede a qualcosa che non si è autorizzati o si tenta di fare qualcosa di malevolo, la sicurezza verrà a cercare l’identità presa in prestito perché non c’è modo di distinguere tra i due.
  5. Nessun codice da scansionare – Ciò causa una mancanza di trasparenza che può ostacolare la risoluzione dei problemi, il debug e l’analisi della sicurezza, nonché possibili problemi di conformità e normative.

Questi rischi possono tutti contribuire a potenziali perdite di dati. Indipendentemente da come un’applicazione venga costruita – che venga costruita con drag-and-drop, un prompt basato su testo o con codice – ha un’identità, ha accesso ai dati, può eseguire operazioni e deve comunicare con gli utenti. I dati vengono spostati, spesso tra diversi luoghi all’interno dell’organizzazione; ciò può facilmente rompere i confini o le barriere dei dati.

La privacy e la conformità dei dati sono anche in gioco. I dati sensibili vivono all’interno di queste applicazioni, ma vengono gestiti da utenti aziendali che non sanno (né pensano a) come memorizzarli correttamente. Ciò può portare a una serie di problemi aggiuntivi, tra cui violazioni della conformità.

Riconquistare la visibilità

Come menzionato, una delle grandi sfide con il low/no code è che non è sotto la visibilità dell’IT/sicurezza, il che significa che i dati stanno attraversando le app. Non c’è sempre una chiara comprensione di chi sta realmente creando queste app, e c’è una generale mancanza di visibilità su ciò che sta realmente accadendo. E non tutte le organizzazioni sono nemmeno pienamente consapevoli di ciò che sta accadendo. O pensano che lo sviluppo dei cittadini non stia accadendo nella loro organizzazione, ma è quasi certamente così.

Quindi, come possono i leader della sicurezza riconquistare il controllo e mitigare il rischio? Il primo passo è esaminare le iniziative di sviluppo dei cittadini all’interno della propria organizzazione, scoprire chi (se qualcuno) sta guidando questi sforzi e connettersi con loro. Non si vuole che questi team si sentano penalizzati o ostacolati; come leader della sicurezza, l’obiettivo dovrebbe essere quello di supportare i loro sforzi, ma fornire anche istruzione e orientamento su come rendere il processo più sicuro.

La sicurezza deve iniziare con la visibilità. La chiave di ciò è creare un inventario di applicazioni e sviluppare una comprensione di chi sta costruendo cosa. Avere queste informazioni aiuterà a garantire che, se si verifica una violazione, si sarà in grado di tracciare i passaggi e capire cosa è successo.

Stabilire un framework per ciò che rappresenta uno sviluppo sicuro. Ciò include le politiche e i controlli tecnici necessari che garantiranno agli utenti di fare le scelte giuste. Anche gli sviluppatori professionisti commettono errori quando si tratta di dati sensibili; è ancora più difficile controllare ciò con gli utenti aziendali. Ma con i controlli giusti in atto, è possibile rendere difficile commettere un errore.

Verso un low-code/no-code più sicuro

Il processo tradizionale di codifica manuale ha ostacolato l’innovazione, specialmente in scenari di tempo di mercato competitivo. Con le piattaforme low-code e no code di oggi, anche le persone senza esperienza di sviluppo possono creare soluzioni guidate da AI. Mentre questo ha semplificato lo sviluppo di app, può anche mettere in pericolo la sicurezza e la sicurezza delle organizzazioni. Non è necessario scegliere tra lo sviluppo dei cittadini e la sicurezza, tuttavia; i leader della sicurezza possono collaborare con gli utenti aziendali per trovare un equilibrio per entrambi.

Michael è il co-fondatore e CTO di Zenity. È un esperto del settore della sicurezza informatica interessato a cloud, SaaS e AppSec. Prima di Zenity, Michael era un architetto senior presso l'ufficio CTO della sicurezza cloud di Microsoft, dove ha fondato e diretto gli sforzi di prodotti di sicurezza per IoT, API, IaC e calcolo confidenziale. Michael guida lo sforzo della comunità OWASP sulla sicurezza low-code/no-code.