Zaid Al Hamani, CEO e Fondatore di Boost Security – Serie di Interviste

Zaid Al Hamani, CEO e Fondatore di Boost Security, è un leader nel settore della sicurezza informatica e del DevSecOps con oltre due decenni di esperienza nella costruzione e gestione di operazioni tecnologiche globali. Dal momento della fondazione di Boost Security nel 2020, si è concentrato sulla modernizzazione di come le organizzazioni proteggono lo sviluppo del software, attingendo a precedenti ruoli tra cui VP della Sicurezza delle Applicazioni in Trend Micro e Co-Fondatore/CEO di IMMUNIO. In precedenza, ha ricoperto posizioni di leadership senior in Canonical, guidando iniziative di prodotto, ingegneria e supporto globale, e in SITA, dove ha gestito operazioni IT su larga scala e critiche per la missione. La sua carriera riflette una solida esperienza nella costruzione di team, nell’ottimizzazione dei sistemi e nell’avanzamento delle pratiche di sicurezza moderne.

Boost Security è un’azienda di sicurezza informatica che si concentra sulla protezione della catena di approvvigionamento del software moderno attraverso una piattaforma DevSecOps orientata agli sviluppatori. La sua tecnologia si integra direttamente nei pipeline CI/CD per rilevare, priorizzare e risolvere automaticamente le vulnerabilità, riducendo il carico manuale e mantenendo la velocità di sviluppo. Unificando la sicurezza dell’applicazione e della catena di approvvigionamento in un unico sistema, la piattaforma fornisce una visibilità completa su codice, dipendenze e infrastruttura, aiutando le organizzazioni a rafforzare la resilienza in ambienti cloud nativi complessi.

Ha guidato in precedenza la sicurezza delle applicazioni in Trend Micro e ha co-fondato IMMUNIO. Cosa l’ha portato a fondare Boost Security e quale lacuna nel mercato era in grado di identificare precocemente?

IMMUN.IO era una delle prime aziende RASP a essere fondata – e la nostra esperienza fino a quel punto era che i WAF come tecnologia di sicurezza runtime erano impossibili da mantenere e non molto efficaci. Avevamo immaginato un modo in cui i WAF sarebbero stati sostituiti con una soluzione più precisa, più facile da mantenere – strumentando l’applicazione.

Era il 2012, DevOps era ancora agli inizi, la maggior parte dei team non era ancora Agile e Kubernetes non era ancora una cosa.

Trend Micro ha acquisito IMMUN.IO nel 2017. A quel punto, c’erano molte più pratiche DevOps: pipeline CI/CD, pratiche di sviluppo Agile, iterazioni e cicli di rilascio più veloci, cloud, ecc. I team di sviluppo del software erano migliori nel costruire software e nel consegnarlo più velocemente. La sicurezza, però, era ancora rotta:

• Le scansioni sono troppo lente o i risultati arrivano troppo tardi
• I risultati sono troppo complessi per gli sviluppatori da azionare
• C’è un tasso di falsi positivi generalmente inaccettabile
• Molti nuovi tipi di artifact non vengono scansionati: codice infrastrutturale, contenitori, API, ad esempio

Produrre software velocemente era più facile. Produrre software sicuro velocemente era ancora difficile.

Quello era il problema originale che abbiamo cercato di risolvere. Fare in modo che DevSecOps funzioni nel mondo reale; è possibile far sì che un team di sviluppo del software aggiunga facilmente la sicurezza nel ciclo di vita del software, alla velocità degli standard di velocità nuovi? È possibile rendere la copertura ampia – dove una piattaforma è tutto ciò di cui hai bisogno? È possibile far sì che gli sviluppatori non solo adottino la tecnologia, ma la amino e vedano i benefici? È possibile farla scalare in modo che non sia necessario avere eserciti di professionisti della sicurezza per tenere il passo con la quantità di codice scritto…

Abbiamo aiutato le aziende a iniettare la sicurezza nel ciclo di vita del software durante l’era DevOps. Quello stava andando da 1 a 10. Ora siamo nell’era della codifica agente – dove gli agenti scrivono una quantità enorme di codice – ma è fondamentalmente lo stesso problema – la velocità e il volume del codice sono solo passati da 10 a 100; e noi miriamo a continuare la stessa traiettoria.

Ha sostenuto che il ciclo di vita dello sviluppo del software (SDLC) ha fondamentalmente spostato l’attenzione a monte. Qual è stato il momento in cui ha realizzato che gli approcci tradizionali di DevSecOps non erano più sufficienti?

È stato guardare come gli attaccanti stavano effettivamente entrando. Continuavamo a vedere lo stesso modello: un flusso di lavoro GitHub Actions esposto che nessuno aveva revisionato dal momento in cui il repository era stato forkato, un token con accesso cloud di produzione incorporato in una configurazione del runner, un lavoro CI legittimo sequestrato per distribuire payload di attaccanti. Questi sono diventati noti come attacchi “living off the pipeline” perché l’avversario utilizza la propria automazione contro di te, con credenziali che il tuo team di sicurezza aveva già approvato.

Lo stack DevSecOps che avevamo costruito nel corso di un decennio non aveva risposta per quello. SAST scansiona il codice sorgente dell’applicazione. SCA scansiona le dipendenze dell’applicazione. Entrambi presuppongono che la pipeline in esecuzione sia attendibile. Nel frattempo, la pipeline stessa è un file YAML con comandi shell, accesso alla rete e credenziali sensibili, e quasi nessuno la revisiona.

Quando diventa il percorso più facile, puoi spedire codice perfettamente pulito e comunque consegnare agli attaccanti il tuo cloud.

Come le aziende dovrebbero ripensare il ciclo di vita del software in un mondo in cui gli agenti di codifica AI generano codice continuamente invece di farlo gli sviluppatori passo dopo passo?

Dobbiamo tutti smettere di pensare al ciclo di vita del software come a una sequenza di punti di controllo. Gli agenti AI hanno compresso il tempo tra “qualcuno ha scritto questo” e “questo è in produzione” da settimane a minuti. Il modello vecchio presumeva un ritmo umano tra revisione del codice, SAST, SCA e deploy, ma siamo oltre questo ora.

La sicurezza deve vivere dove opera l’agente: sulla macchina dello sviluppatore, all’interno del contesto della richiesta, nelle connessioni dell’agente ai server MCP e ai modelli esterni. Una volta che il codice raggiunge la pipeline, hai già perso la possibilità di plasmarlo. L’agente ha già estratto la dipendenza. Il modello ha già visto la credenziale. Sposta i controlli a monte, dove effettivamente si svolge il lavoro.

Molte organizzazioni trattano ancora gli strumenti di codifica AI come semplici strati di produttività. Perché ritiene che rappresentino una nuova superficie di attacco piuttosto che solo un’estensione dei flussi di lavoro esistenti?

Trattare uno strumento di codifica AI come uno strato di produttività è come trattare un junior developer con accesso root come uno strato di produttività. L’etichetta è tecnicamente accurata, ma non fornisce alcun quadro utile per pensare a cosa potrebbe andare storto.

Uno strumento di codifica legge il tuo file system, raschia le variabili d’ambiente per il contesto, recupera dipendenze da registri pubblici, apre connessioni in uscita a provider di modelli remoti e server MCP ed esegue comandi shell. Ognuna di queste azioni richiedeva in precedenza un intervento umano. Ora accadono in millisecondi, con gli stessi privilegi dello sviluppatore che ha avviato l’agente.

Quella compressione fonde i confini di fiducia che un tempo erano separati: l’autorità dello sviluppatore, ciò che uno strumento esterno può recuperare e ciò che il codice non attendibile può eseguire. Ciò crea nuove opportunità per gli attaccanti e punti ciechi che i difensori non possono nemmeno vedere, tanto meno difendere.

Boost definisce il laptop dello sviluppatore come il nuovo piano di controllo. Quali rischi esistono nel punto di terminazione che i team di sicurezza stanno attualmente trascurando?

Il più grande è l’inventario. La maggior parte dei team di sicurezza non può dirti quali agenti AI stanno girando su quali laptop, a quali server MCP quegli agenti sono connessi o quali estensioni IDE stanno raschiando il contenuto del repository proprio ora. EDR non ha visibilità nel livello dell’agente; SIEM non può vedere cosa fanno quegli agenti a livello locale.

Sotto ciò si trova il pasticcio delle credenziali. Abbiamo costruito uno strumento open-source chiamato Bagel in parte per rendere questo concreto. Un laptop tipico dello sviluppatore contiene token GitHub con accesso in scrittura ai repository di produzione, credenziali cloud che possono avviare infrastrutture, token npm o PyPI che possono pubblicare per milioni di utenti e chiavi del servizio AI che gli attaccanti rivendono. Nessuna di queste è protetta nel modo in cui un runner CI è protetto. La stessa macchina che contiene queste credenziali naviga anche nel web e installa estensioni VS Code casuali.

Accoppiare le due cose e si ha la vera superficie di attacco. Un’estensione non attendibile in esecuzione con privilegi di sviluppatore in un ambiente pieno di chiavi cloud è il bersaglio con il più alto guadagno nell’azienda moderna. La maggior parte dei team non ha ancora iniziato a guardare.

Ha evidenziato la “trappola del contesto”, dove gli agenti AI possono accedere a file locali, variabili d’ambiente e configurazioni. Quanto è diffuso il rischio di perdita di dati sensibili attraverso le richieste e perché è così difficile da rilevare?

Sufficientemente diffuso che lo trattiamo come lo stato predefinito di qualsiasi ambiente di sviluppatore non gestito. Ogni agente di codifica che abbiamo ispezionato estrae il contesto locale in modo aggressivo. Leggono file, variabili d’ambiente, file recenti, a volte interi alberi di directory e spediscono quel contesto a un modello remoto. Gli strumenti sono progettati per funzionare in questo modo; l’estrazione del contesto aggressiva è ciò che li rende utili.

Il problema di rilevamento inizia perché il traffico da una perdita appare identico all’uso normale del prodotto. È TLS per api.openai.com o api.anthropic.com. Proviene da un’applicazione aziendale approvata. Il DLP standard vede uno sviluppatore che utilizza lo strumento AI che l’azienda ha appena acquistato. Non vede che una delle stringhe nella richiesta è una chiave segreta AWS che l’agente ha recuperato da un file .env dimenticato in una directory fratello.

Lo si coglie solo ispezionando le richieste prima che lascino il laptop, che è esattamente dove quasi nessuno stack di sicurezza è attualmente posizionato.

Ha menzionato attacchi alla catena di approvvigionamento alla velocità della macchina. Può guidarci attraverso uno scenario realistico in cui un agente AI introduce una vulnerabilità più velocemente di quanto gli strumenti di sicurezza tradizionali possano identificarla?

Ecco uno che abbiamo visto variazioni ripetute. Uno sviluppatore chiede a un agente di aggiungere una funzionalità che richiede una libreria di ritardo HTTP. L’agente suggerisce un nome di pacchetto. Il pacchetto è plausibile, ma non esiste effettivamente su npm. Entro un’ora, un attaccante registra il pacchetto, lo popola con logica di ritardo funzionante più uno script di post-installazione che legge ~/.aws/credentials e pubblica il contenuto su un webhook. L’agente esegue npm install senza controllare, perché gli agenti non controllano la reputazione. La credenziale è già persa prima che lo sviluppatore esegua anche il codice.

L’attacco stesso non è tecnicamente sofisticato, ma la sicurezza della catena di approvvigionamento tradizionale è costruita intorno a vulnerabilità note in pacchetti noti: CVE, SBOM, scansioni di licenze. Quel framework non ha nulla da dire su un pacchetto che non esisteva quando l’ultima scansione è stata eseguita, creato specificamente per corrispondere a un’allucinazione AI e ingerito prima che qualsiasi feed di minacce venga aggiornato.

La finestra da pubblicazione a compromissione è ora misurata in minuti. Qualsiasi controllo eseguito dopo i fatti è troppo lento.

Stanno diventando le dipendenze allucinate una delle più grandi minacce nello sviluppo guidato da AI e quali passi pratici possono intraprendere le organizzazioni per difendersi?

Lo sono già. Gli attaccanti monitorano attivamente gli strumenti AI popolari per allucinazioni e registrano i nomi di pacchetti suggeriti entro pochi minuti. Ricercatori un paio di anni fa, quando è iniziato, lo hanno chiamato slopsquatting e il nome è rimasto. Una volta che un nome di dipendenza viene allucinato frequentemente a sufficienza, stare seduti su di esso è un attacco alla catena di approvvigionamento passivo con sforzo quasi zero.

Le difese pratiche appaiono diverse da quelle che la maggior parte dei team ha attualmente. Inizia con l’ingestione. Blocca pacchetti typosquatted e registrati di recente al momento dell’esecuzione di npm install o pip install, sulla macchina dello sviluppatore, prima che qualcosa colpisca il disco. La rilevazione post-mortem in CI non aiuta quando uno script di post-installazione ha già esfiltrato una credenziale. Quindi fornisce all’agente delle barriere operative all’interno. Inietta l’elenco delle dipendenze approvate direttamente nel contesto dell’agente, in modo che il modello veda cosa è consentito prima di generare una suggestione. Chiedere agli sviluppatori di scrivere “prompt sicuri” non è una strategia. Se stai diventando strategico, significa che la sicurezza stabilisce il confine, l’agente lo eredita. E inizia a tracciare un Bill of Materials AI. La maggior parte dei team non può dirti quali agenti, modelli e pacchetti stanno toccando quali repository. Non puoi difendere ciò che non puoi inventariare.

Ha detto che la sicurezza non può più iniziare al CI/CD. Cosa assomiglia una pipeline di sicurezza moderna quando la protezione deve iniziare prima nel processo di sviluppo?

Se la sicurezza inizia al CI/CD, hai ceduto l’intera fase pre-commit a un ambiente che non controlli. L’agente ha già ingerito il contesto, la tua credenziale potrebbe già essere nei log di qualcun altro. Stai scansionando un cadavere.

Una pipeline moderna inizia sul laptop. Ciò significa inventariare gli agenti ed estensioni in esecuzione lì, convalidare a quali server MCP e modelli sono autorizzati a parlare, sanificare ciò che lascia la macchina e bloccare pacchetti dannosi prima che si installino. Da lì, la politica segue il lavoro all’interno dell’IDE. Iniettiamo gli standard di sicurezza direttamente nella finestra di contesto dell’agente in modo che il codice generato rimanga all’interno delle barriere operative fin dal primo token. La pipeline stessa non scompare. Il suo ruolo diventa verifica: confermare che i controlli upstream sono stati applicati.

La pipeline stessa non scompare. Il suo ruolo diventa verifica: confermare che i controlli upstream sono stati applicati.

Mentre le organizzazioni continuano ad adottare agenti di codifica AI, quali sono i cambiamenti più critici che devono apportare oggi per assicurarsi che i loro ambienti di sviluppo rimangano sicuri nei prossimi anni?

L’errore più grande è proteggere solo ciò che viene commitato. Il rischio interessante vive ora nelle otto ore prima che si verifichi un commit. Dramma non visto può svolgersi sul laptop, nella richiesta o nell’installazione del pacchetto. Se i tuoi strumenti iniziano al PR, stai proteggendo la metà sbagliata del flusso di lavoro.

Strettamente correlato: smettila di trattare gli strumenti di codifica AI come software di produttività. Sono utenti non umani con accesso shell, privilegi di scrittura del repository e connessioni di rete in uscita. Governali nel modo in cui governi qualsiasi altra identità privilegiata, con un inventario, capacità approvate e log di audit.

L’ultimo spostamento è più difficile culturalmente. La maggior parte degli attuali “strumenti di sicurezza AI” presentano i risultati e li instradano agli esseri umani. Gli esseri umani non possono triare alla velocità con cui gli agenti generano. Qualsiasi cosa adotti deve risolvere i problemi automaticamente all’interno del flusso di lavoro, con ragionamento tracciabile, o diventa un’altra dashboard che nessuno legge.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Boost Security.