Shahar Man, Co-fondatore e Amministratore Delegato di Backslash Security – Serie di Interviste

Shahar Man, Co-fondatore e Amministratore Delegato di Backslash Security, è un leader tecnologico esperto con una profonda conoscenza nello sviluppo cloud, nella sicurezza informatica e nel software aziendale. Attualmente guida Backslash Security, un’azienda che si concentra sulla sicurezza degli ambienti di sviluppo software nativi AI, proteggendo tutto, dalle IDE agli agenti AI, al codice generato e ai flussi di lavoro di prompt. In precedenza, ha ricoperto ruoli di leadership senior in Aqua Security, dove ha lavorato come Vice Presidente della Gestione dei Prodotti e Vice Presidente della Ricerca e Sviluppo, aiutando a costruire una delle piattaforme leader per la sicurezza dei container in tutta la durata di vita dello sviluppo. All’inizio della sua carriera, Man ha trascorso oltre un decennio in SAP, dove ha guidato lo sviluppo e le iniziative di prodotto, tra cui SAP Web IDE, e ha lavorato a stretto contatto con clienti aziendali globali, contribuendo anche alla crescita dell’ecosistema degli sviluppatori. La sua carriera è iniziata con ruoli tecnici e di leadership in ambienti di startup e unità tecnologiche della difesa israeliana, dandogli una solida base sia in ingegneria che in sistemi su larga scala.

Backslash Security è una piattaforma di sicurezza informatica emergente progettata specificamente per l’era dello sviluppo software guidato da AI. L’azienda si concentra sulla sicurezza dell’intero stack di sviluppo nativo AI, compresi agenti AI, pipeline di generazione di codice e flussi di lavoro moderni per gli sviluppatori, un’area che gli strumenti di sicurezza tradizionali spesso trascurano. Fornendo visibilità, governance e protezione in tempo reale senza interrompere la velocità degli sviluppatori, Backslash mira a risolvere i rischi crescenti introdotti dalla codifica automatizzata e dagli ambienti di “vibe coding”. Poiché la creazione di software si sposta sempre più verso sistemi assistiti da AI, la piattaforma è progettata per garantire che la sicurezza si evolva parallelamente, anziché diventare un collo di bottiglia, posizionando Backslash all’intersezione di DevSecOps e sviluppo AI di prossima generazione.

Ha ricoperto ruoli di leadership nel prodotto e nella R&D in aziende come Aqua Security e SAP prima di fondare Backslash. Quali segnali precoci l’hanno convinto che lo sviluppo nativo AI e il “vibe coding” avrebbero radicalmente trasformato la creazione di software e che la sicurezza doveva essere ricostruita per supportarlo?

Avevo già vissuto un grande cambiamento quando il software si è spostato verso architetture cloud-native. In SAP e successivamente in Aqua, abbiamo visto da vicino che quando lo sviluppo cambia così tanto, la sicurezza di solito rimane indietro. L’AI ha portato quella verità a un nuovo livello, non solo perché può aiutare a scrivere codice più velocemente, ma perché ha iniziato a ridisegnare l’intero ambiente intorno alla creazione di software.

La sicurezza del codice non è più solo questione del codice stesso, ma dell’ambiente che lo circonda. In meno di un anno, ciò che un tempo era un ambiente di sviluppo relativamente contenuto e a basso rischio si è espanso in una vasta superficie di attacco altamente connessa e con poca supervisione o governance. Una volta che questo è successo, le domande di sicurezza relative alle vulnerabilità del codice sono cambiate completamente. Il vero problema non è se un determinato pezzo di codice è vulnerabile. Il problema è che, abilitando lo sviluppo guidato da AI, abbiamo introdotto sistemi, agenti, integrazioni e percorsi di accesso che si estendono ben oltre il codice stesso. La sicurezza non può più concentrarsi solo sull’output del codice. Deve tenere conto dell’intero ambiente che rende possibile quel codice.

Descrive il “vibe coding” come l’ampliamento della superficie di attacco oltre il codice, fino a includere prompt, agenti, server MCP e strati di strumenti. Quali sono i rischi più fraintesi in questo nuovo stack che gli sviluppatori e i team di sicurezza stanno attualmente trascurando?

La più grande incomprensione è che molti team pensano ancora che il rischio si trovi principalmente nel codice generato. Quello è solo uno strato. Nello sviluppo nativo AI, il rischio è introdotto prima e in molti più posti. Ciò potrebbe essere nei prompt, nel contesto fornito al modello, nelle autorizzazioni concesse agli agenti, nei server MCP a cui si connettono o negli strumenti esterni e plugin che estendono la loro portata. Un singolo laptop di un utente può essere preso in controllo e utilizzato come testa di ponte di un attacco più ampio. È un punto dolente dell’endpoint che si maschera da problema di codifica AI. A differenza delle vulnerabilità del codice, questo non mette a rischio solo le applicazioni, ma può mettere a rischio l’intera organizzazione. Se si guarda solo al codice, si perde la maggior parte dell’immagine.

La sicurezza delle applicazioni tradizionali si è concentrata molto sulla revisione del codice. Come deve evolversi il pensiero sulla sicurezza quando gli agenti AI generano, modificano e distribuiscono codice in tempo reale?

La sicurezza deve passare da un’ispezione periodica a una supervisione continua. Il concetto di fiducia è completamente rotto: si possono avere modelli fidati e server MCP fidati, ma a causa della natura non deterministica dell’AI, possono comunque essere manipolati o semplicemente comportarsi in modo imprevisto per creare rischi inaspettati.

Ciò significa anche che deve esserci un cambiamento di mentalità in cui la sicurezza opera accanto al processo di sviluppo mentre si svolge e ha una governance, guardrail e capacità di rilevamento e risposta molto più profonde all’interno di quell’ambiente. Ciò significa pensare criticamente agli strumenti utilizzati, al contesto che consumano, alle politiche che dovrebbero governarli e alle azioni che intraprendono in tempo reale.

Inoltre, non possiamo ignorare il ruolo dell’AI e dei modelli AI nel gestire le vulnerabilità. Se un anno fa i modelli AI producevano molte vulnerabilità di default, le cose sono migliorate drasticamente e altri modelli sono ora utilizzati per trovare zero-day che non sono stati trovati prima. Quindi stiamo andando verso output migliori, ma chi controlla il negozio mentre facciamo questo? Gli aggressori stanno guardando altrove.

Strumenti come Cursor, Claude Code e GitHub Copilot stanno diventando standard nei flussi di lavoro degli sviluppatori. Dove vede le lacune di sicurezza più grandi quando i team adottano questi strumenti senza un adeguato strato di governance?

La lacuna più grande è la visibilità. In molte organizzazioni, questi strumenti si diffondono rapidamente e senza una revisione formale. I team di sicurezza spesso non sanno quali agenti vengono utilizzati, come sono configurati, quali dati possono accedere o a quali sistemi esterni sono connessi. Ciò crea un problema di “shadow AI”, simile al problema di “shadow IT” per principio, solo più veloce e dinamico.

La seconda lacuna più grande è la mancanza di politiche applicabili. La maggior parte delle organizzazioni potrebbe avere linee guida, ma le linee guida da sole non aiutano molto quando uno sviluppatore si muove rapidamente all’interno dell’IDE. Senza governance a livello di strumento e flusso di lavoro, i team rischiano di avere strumenti sovra-autorizzati che non soddisfano gli standard aziendali. Questi strumenti non sono intrinsecamente cattivi, ma adottarli senza governance significa che si scala la velocità di sviluppo senza scalare il controllo.

Una terza lacuna emergente è che chiunque può potenzialmente diventare uno sviluppatore, ciò che chiamiamo “citizen-developer”, utilizzando strumenti di “vibe coding”. Quando la persona delle finanze utilizza Claude Code per automatizzare i processi e connettersi a sistemi interni, ciò crea un potenziale rischio e rappresenta un punto cieco enorme anche oggi.

Backslash si concentra sulla sicurezza dell’intero ecosistema di sviluppo AI piuttosto che su singoli strumenti. Perché questo approccio full-stack è necessario e cosa accade se le organizzazioni continuano a trattare questi rischi in isolamento?

Perché il rischio non si trova in un solo prodotto nel proprio stack. Lo sviluppo nativo AI è intrinsecamente un problema di ecosistema perché opera in molti posti diversi, utilizzando molti strumenti diversi. L’IDE, il modello, gli agenti, i server MCP, gli strumenti esterni e i plugin che estendono la loro portata, le identità e le fonti di dati connessi influenzano tutti ciò che viene costruito e come. Le organizzazioni non standardizzano intenzionalmente su un singolo strumento perché le loro forze relative stanno cambiando così rapidamente. Se si garantisce la sicurezza solo in un punto di quella catena, si perde comunque come il rischio si muove attraverso il sistema.

Trattare questi rischi in isolamento porta a difese frammentate e a punti ciechi pericolosi. Si potrebbe irrobustire lo scanner di codice, ma trascurare il server MCP che ha fornito un contesto rischioso al modello. Questo è il motivo per cui crediamo che l’approccio giusto sia la visibilità full-stack e la protezione in tempo reale in tutto l’ecosistema di sviluppo AI. Altrimenti, le organizzazioni continueranno a risolvere i sintomi mentre la reale superficie di attacco continua a espandersi sotto di loro.

Il prompting sta emergendo come un nuovo livello di programmabilità. Come dovrebbero approcciare le organizzazioni la sicurezza dei prompt e la prevenzione di problemi come l’iniezione di prompt, la perdita di dati o la manipolazione?

I prompt plasmano sempre più la logica e il comportamento. In molti casi, sono effettivamente un nuovo piano di controllo per la creazione di software. Ciò significa che richiedono politiche, monitoraggio e guardrail proprio come le definizioni di codice o infrastruttura richiederebbero. Nella pratica, ciò inizia con il limitare cosa i prompt possano accedere e quali azioni a valle possono innescare. Significa anche definire regole di prompt che si allineino con le aspettative di sicurezza e qualità, prevenendo l’esposizione di dati sensibili attraverso finestre di contesto e vigilando per tentativi di manipolazione come l’iniezione di prompt o il dirottamento di istruzioni indirette. E include anche assicurarsi che le regole stesse non vengano utilizzate come retroporta per l’iniezione di prompt. Il punto più ampio è che non si garantisce la sicurezza dei prompt istruendo gli sviluppatori e gli agenti a “fare attenzione”. La si garantisce incorporando controlli nell’ambiente in cui effettivamente si verificano i prompt.

I server MCP e le Skills degli agenti introducono connessioni dinamiche tra sistemi. Dal punto di vista della sicurezza, rappresentano il nuovo vettore di rischio più significativo nello sviluppo guidato da AI?

I server MCP e le Skills degli agenti rappresentano un nuovo livello di rischio importante perché definiscono come i sistemi AI si connettono e interagiscono con il mondo reale. Le Skills definiscono cosa un agente è autorizzato a fare, mentre il server MCP estende il suo accesso al contesto e ai sistemi. Insieme, plasmano il comportamento effettivo dell’agente. Se questi livelli non sono strettamente controllati, le organizzazioni perdono la visibilità su cosa siano in grado di fare gli strumenti AI e cosa stiano effettivamente facendo. Il passaggio dalla generazione di codice all’azione è ciò che rende quest’area così critica per la sicurezza, e diventano ancora più imprevedibili quando li si collega insieme.

Una delle sue tematiche principali è “essere il dipartimento del Sì” – abilitare la sicurezza senza rallentare gli sviluppatori. Come bilancia la protezione in tempo reale con la velocità degli sviluppatori in ambienti in cui la velocità è critica?

La sicurezza crea attrito quando si verifica tardi o è disconnessa da come gli sviluppatori lavorano effettivamente. Diventa molto più efficace quando è incorporata direttamente nel flusso di lavoro e si concentra su ciò che realmente conta. Ciò è stato parte del nostro pensiero fin dall’inizio di Backslash e conta ancora di più ora nello sviluppo guidato da AI.

Nella pratica, ciò significa evidenziare i pochi problemi che rappresentano un rischio reale, non inondare gli sviluppatori con tutto ciò che sembra teoricamente sospetto. Significa applicare le politiche all’interno del flusso di lavoro dell’IDE e dell’agente, non dopo il fatto. E significa creare guardrail trasparenti e deterministici in modo che i team possano muoversi rapidamente mentre sanno ancora quali strumenti sono in uso, quali autorizzazioni hanno e quando qualcosa di anormale sta accadendo. L’obiettivo non è rallentare l’adozione di AI, ma aiutare le organizzazioni ad adottarla con fiducia senza perdere il controllo. In termini reali, ciò significa che uno sviluppatore avrebbe meno spazio per commettere errori per la prima volta, ma se lo fa, verrà catturato e gestito rapidamente.

Stiamo vedendo utenti non tecnici costruire software utilizzando strumenti AI. Come la crescita di sviluppatori non tecnici di “vibe coding” cambia il panorama delle minacce?

Amplia il panorama delle minacce in due modi. In primo luogo, aumenta drasticamente il numero di persone che possono produrre output simili a software senza capire le implicazioni di sicurezza. In secondo luogo, crea un falso senso di sicurezza perché gli strumenti rendono lo sviluppo conversazionale e a basso attrito.

Ciò significa che le organizzazioni vedranno più applicazioni, automazioni e integrazioni create da persone che non sono addestrate a considerare i confini di fiducia, la validazione delle input, l’igiene delle dipendenze, il controllo di accesso o l’esposizione dei dati. In altre parole, la superficie di attacco si espande non solo perché l’AI scrive più codice, ma perché più persone possono ora generare flussi di lavoro e sistemi che si comportano come software senza applicare la disciplina ingegneristica di base. Ciò rende la visibilità e le salvaguardie incorporate ancora più importanti, perché non si può più supporre la conoscenza della sicurezza nel punto di creazione.

Guardando avanti 12-24 mesi, quali tipi di attacchi o vulnerabilità si aspetta di emergere specificamente a causa dei flussi di lavoro di sviluppo nativo AI?

Ci aspettiamo che molte delle comuni vulnerabilità del codice saranno evitate in anticipo grazie ai miglioramenti nei LLM stessi, o attraverso regole di prompt incorporate migliori nella “sella” che circonda quegli strumenti. Se ora stiamo vedendo un aumento del volume di vulnerabilità semplicemente a causa della velocità aumentata, questo si correggerà. E ciò che non viene corretto verrà inseguito dall’AI abilitata SAST e SCA (alcune delle quali saranno fornite anche dai vendor di piattaforme AI, ad esempio Claude Code Security e progetto Glasswing).

Tuttavia, mi aspetto esiti molto peggiori quando si tratta di esposizioni dovute all’uso di strumenti AI non verificati e non supervisionati nello sviluppo di applicazioni, come ad esempio agenti open-source (OpenClaw è un buon esempio), che hanno pessime impostazioni di sicurezza predefinite associate a un utente la cui conoscenza della sicurezza è molto superata dal suo entusiasmo per il “vibe coding”.

Come conseguenza, credo che vedremo un passaggio verso attacchi che prendono di mira l’ecosistema di sviluppo stesso piuttosto che solo i sistemi di produzione. Man mano che l’AI diventa parte di come viene creato il software, gli aggressori si concentreranno sulla manipolazione degli strumenti e delle connessioni che plasmano quel processo, compromettendo efficacemente il software prima che venga distribuito.

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