Shahar Man, Co-fondator și CEO al Backslash Security – Seria de interviuri

Shahar Man, Co-fondator și CEO al Backslash Security, este un lider tehnologic experimentat cu expertiză profundă în dezvoltarea cloud, securitatea cibernetică și software-ul pentru întreprinderi. El conduce în prezent Backslash Security, o companie axată pe securizarea mediilor de dezvoltare software native AI, protejând totul, de la IDE-uri și agenți AI la cod generat și fluxuri de lucru de promptare. Înainte de aceasta, el a ocupat funcții de conducere senior la Aqua Security, unde a servit atât ca Vicepreședinte al managementului de produs, cât și ca Vicepreședinte al departamentului de cercetare și dezvoltare, ajutând la construirea uneia dintre principalele platforme pentru securitatea containerelor pe tot parcursul ciclului de dezvoltare. La începutul carierei sale, Man a petrecut peste un deceniu la SAP, unde a condus inițiative de dezvoltare și produs, inclusiv SAP Web IDE, și a lucrat îndeaproape cu clienți globali de întreprinderi, contribuind în același timp la creșterea ecosistemului dezvoltatorilor. Cariera sa a început în roluri tehnice și de conducere în medii de startup și unități de tehnologie de apărare din Israel, dându-i o bază solidă în inginerie și sisteme de scară largă.

Backslash Security este o platformă emergentă de securitate cibernetică proiectată special pentru era dezvoltării software bazate pe inteligență artificială. Compania se concentrează pe securizarea întregului stiv de dezvoltare nativ AI, inclusiv agenți AI, conducte de generare de cod și fluxuri de lucru moderne ale dezvoltatorilor, o zonă pe care instrumentele de securitate tradiționale o omit adesea. Prin oferirea de vizibilitate, guvernanță și protecție în timp real fără a perturba viteza dezvoltatorilor, Backslash își propune să abordeze riscurile crescânde introduse de codificarea automată și medii de „vibe coding”. Pe măsură ce crearea de software se îndreaptă tot mai mult către sisteme asistate de IA, platforma este proiectată pentru a asigura că securitatea evoluează în paralel, și nu devine un punct de strangulare, poziționând Backslash la intersecția dintre DevSecOps și dezvoltarea de generație următoare bazată pe IA.

Ați ocupat funcții de conducere în produs și cercetare-dezvoltare la companii precum Aqua Security și SAP, înainte de a fonda Backslash. Care au fost semnalele timpurii care v-au convins că dezvoltarea nativă AI și „vibe coding” vor schimba fundamental crearea de software, și că securitatea trebuie reconstruită pentru a o susține?

Am trăit deja o schimbare majoră când software-ul s-a mutat în arhitecturi cloud-native. La SAP și, mai târziu, la Aqua, am văzut direct că atunci când dezvoltarea se schimbă atât de mult, securitatea de obicei rămâne în urmă. IA a dus această realitate la un nivel cu totul nou, nu doar pentru că poate ajuta la scrierea codului mai rapid, dar și pentru că a început să restructureze întregul mediu din jurul creării de software.

Securizarea codului nu mai este doar despre codul în sine, ci despre mediul din jurul lui. În mai puțin de un an, ceea ce era o configurație de dezvoltare relativ conținută și cu risc scăzut s-a extins într-o suprafață de atac vastă și puternic conectată, cu puțină supraveghere sau guvernanță. Odată ce s-a întâmplat acest lucru, întrebările de securitate legate de vulnerabilitățile codului s-au schimbat complet. Problema reală nu este dacă un anumit cod este vulnerabil, ci că, prin dezvoltarea condusă de IA, am introdus sisteme, agenți, integrări și căi de acces care se extind mult dincolo de codul în sine. Securitatea nu se mai poate concentra doar pe output-ul codului. Trebuie să țină cont de întregul mediu care face posibil acel cod.

Descrieți „vibe coding” ca o extindere a suprafeței de atac dincolo de cod, în prompte, agenți, servere MCP și straturi de instrumente. Care sunt riscurile cele mai puțin înțelese în acest nou stiv pe care dezvoltatorii și echipele de securitate le omit în prezent?

Cea mai mare înțelegere greșită este că multe echipe încă cred că riscul trăiește în principal în codul generat. Acesta este doar un strat. În dezvoltarea nativă AI, riscul este introdus mai devreme și în multe locuri. Acesta poate fi în prompte, în contextul furnizat modelului, în permisiunile acordate agenților, în serverele MCP la care se conectează sau în instrumentele și plugin-urile externe care le extind domeniul de aplicare. Un singur laptop al unui utilizator poate fi preluat și folosit ca punct de intrare pentru un atac mai larg. Este un punct de vulnerabilitate la nivel de endpoint, deghizat într-o problemă de codificare AI. În contrast cu vulnerabilitățile codului, aceasta nu pune la risc doar aplicațiile dvs., ci poate pune la risc întreaga organizație. Dacă vă uitați doar la cod, pierdeți cea mai mare parte a tabloului.

Securitatea aplicațiilor tradiționale s-a concentrat puternic pe revizia codului. Cum trebuie să evolueze gândirea de securitate atunci când agenții AI generează, modifică și implementează cod în timp real?

Securitatea trebuie să treacă de la inspecția periodică la supraveghere continuă. Noțiunea de încredere este complet ruptă – puteți avea modele de încredere și servere MCP de încredere, dar din cauza naturii nedeterminate a IA, acestea pot fi totuși manipulate sau pur și simplu se pot comporta defectuos pentru a crea riscuri neașteptate.

Acest lucru înseamnă, de asemenea, că trebuie să existe o schimbare de mentalitate, în care securitatea funcționează alături de procesul de dezvoltare pe măsură ce are loc și are o guvernanță, garduri și capacități de detectare și răspuns mult mai profunde în cadrul acelui mediu. Acest lucru înseamnă a gândi critic despre care instrumente sunt utilizate, ce context consumă, ce politici ar trebui să le guverneze și ce acțiuni îndeiază în timp real.

În plus, nu putem ignora rolul IA și al modelelor IA în gestionarea vulnerabilităților. Dacă acum un an modelele IA produceau multe vulnerabilități din oficiu, lucrurile s-au îmbunătățit considerabil, iar alte modele sunt utilizate acum pentru a găsi vulnerabilități zero-day care nu au fost găsite anterior. Deci, ne îndreptăm către ieșiri mai bune – dar cine supraveghează magazinul în timp ce facem asta? Atacatorii caută în altă parte.

Unelte precum Cursor, Claude Code și GitHub Copilot devin standard în fluxurile de lucru ale dezvoltatorilor. Unde vedeți cele mai mari lacune de securitate atunci când echipele adoptă aceste unelte fără un strat de guvernanță corespunzător?

Cea mai mare lacună este vizibilitatea. În multe organizații, aceste unelte se răspândesc rapid și fără o revizuire formală. Echipele de securitate adesea nu știu care agenți sunt utilizați, cum sunt configurați, ce date pot accesa sau la ce sisteme externe se conectează. Acest lucru creează o problemă de „shadow AI”, similară cu shadow IT în principiu, doar că este mai rapidă și mai dinamică.

Al doilea lacună cel mai mare este lipsa unor politici impuse. Majoritatea organizațiilor pot avea linii directoare, dar linii directoare singure nu ajută mult atunci când un dezvoltator se mișcă rapid în interiorul IDE-ului. Fără guvernanță la nivelul instrumentului și fluxului de lucru, echipele riscă să aibă unelte suprapermisionate care nu îndeplinesc standardele întreprinderii. Aceste unelte nu sunt în mod inerent rele, dar adoptarea lor fără guvernanță înseamnă că, în esență, scalați viteza de dezvoltare fără a scala controlul.

O a treia lacună emergentă este că oricine poate deveni, în mod potențial, dezvoltator – ceea ce numim „dezvoltatori cetățeni”, care utilizează unelte de „vibe coding”. Când o persoană din departamentul financiar utilizează Claude Code pentru a automatiza procese și a se conecta la sisteme interne, acest lucru creează un risc potențial și este un punct orb și astăzi.

Backslash se concentrează pe securizarea întregului ecosistem de dezvoltare AI, mai degrabă decât pe unelte individuale. De ce este necesară această abordare full-stack, și ce se întâmplă dacă organizațiile continuă să trateze aceste riscuri în mod izolat?

Pentru că riscul nu se află neapărat într-un singur produs din stivă. Dezvoltarea nativă AI este, în mod inerent, o problemă de ecosistem, deoarece funcționează în multe locuri diferite, utilizând multe unelte diferite. IDE-ul, modelul, agenții, serverele MCP, instrumentele și plugin-urile externe, identitățile și sursele de date conectate toate influențează ceea ce se construiește și cum. Organizațiile nu standardizează intenționat pe o singură unealtă, deoarece punctele lor forte relative se schimbă atât de repede. Dacă securizați doar un punct din lanț, încă mai ratați modul în care riscul se deplasează în sistem.

Tratarea acestor riscuri în mod izolat conduce la apărări fragmentate și la puncte oarbe periculoase. Puteți întări scannerul de cod, dar puteți ignora serverul MCP care a furnizat context riscant modelului. Acesta este motivul pentru care credem că abordarea corectă este vizibilitatea full-stack și protecția în timp real pe întregul ecosistem de dezvoltare AI. Altfel, organizațiile vor continua să rezolve simptomele, în timp ce suprafața de atac reală se extinde sub ele.

Promptarea este în curs de a deveni un nou strat de programare. Cum ar trebui organizațiile să abordeze securizarea promptelor și prevenirea problemelor precum injectarea promptelor, scurgerea de date sau manipularea?

Promptele formează din ce în ce mai mult logică și comportament. În multe cazuri, ele sunt, în esență, un nou plan de control pentru crearea de software. Acest lucru înseamnă că au nevoie de politici, monitorizare și garduri, la fel cum ar avea nevoie definițiile codului sau infrastructurii. În practică, acest lucru începe cu limitarea a ceea ce pot accesa promptele și a ceea ce acțiuni pot declanșa. Acest lucru înseamnă, de asemenea, definirea regulilor promptelor care se aliniază cu așteptările de securitate și calitate, prevenirea expunerii datelor sensibile prin ferestre de context și supravegherea încercărilor de manipulare, cum ar fi injectarea promptelor sau hijacking-ul indirect de instrucțiuni. Și include, de asemenea, asigurarea că regulile însele nu sunt utilizate ca backdoor-uri pentru injectarea promptelor. Punctul mai larg este că nu securizați promptele instruind dezvoltatorii și agenții să „aibă grijă”. Le securizați încorporând controlul în mediul în care are loc promptarea.

Serverele MCP și abilitățile agenților introduc conexiuni dinamice între sisteme. Din perspectiva securității, reprezintă acestea cel mai nou vector de risc semnificativ în dezvoltarea condusă de IA?

Serverele MCP și abilitățile agenților reprezintă un strat major de risc, deoarece definesc cum se conectează și interacționează sistemele IA cu lumea reală. Abilitățile definesc ce poate face un agent, în timp ce MCP extinde accesul său la context și sisteme. Împreună, ele formează comportamentul real al agentului. Dacă aceste straturi nu sunt controlate strict, organizațiile pierd vizibilitatea asupra a ceea ce pot face și ce fac, în realitate, uneltele lor IA. Trecerea de la generarea codului la luarea de acțiuni este ceea ce face această zonă atât de critică pentru securitate, și devine și mai imprevizibilă atunci când le înlănțuiți.

Una dintre temele dvs. principale este „a fi departamentul de Da” – permițând securitatea fără a încetini dezvoltatorii. Cum echilibrați protecția în timp real cu viteza dezvoltatorilor în medii în care viteza este critică?

Securitatea creează fricțiune atunci când are loc târziu sau este decuplată de modul în care dezvoltatorii lucrează, în realitate. Devine mult mai eficientă atunci când este încorporată direct în fluxul de lucru și se concentrează pe ceea ce contează cu adevărat. Acesta a fost parte a gândirii noastre de la începutul Backslash, și contează și mai mult acum, în dezvoltarea condusă de IA.

În practică, acest lucru înseamnă prezentarea problemelor care reprezintă un risc real, nu inundați dezvoltatorii cu tot ceea ce pare teoretic suspect. Înseamnă impunerea politicii în IDE și fluxul de lucru al agentului, nu după fapt. Și înseamnă crearea unor garduri transparente și deterministice, astfel încât echipele să poată lucra rapid, știind, în același timp, care unelte sunt utilizate, ce permisiuni au și când se întâmplă ceva anormal. Scopul nu este să încetineze adoptarea IA, ci să ajute organizațiile să o adopte cu încredere, fără a pierde controlul. În termeni reali, acest lucru înseamnă că un dezvoltator va avea mai puțin spațiu pentru a face greșeli, dar, dacă face una, va fi prinsă și gestionată rapid.

Asistăm la o creștere a numărului de utilizatori non-tehnici care construiesc software utilizând unelte AI. Cum schimbă apariția dezvoltatorilor non-tehnici de „vibe coding” peisajul amenințărilor?

Extinde peisajul amenințărilor în două moduri. În primul rând, crește dramatic numărul de persoane care pot produce ieșiri similare software-ului fără a înțelege implicațiile de securitate. În al doilea rând, creează o falsă senzație de siguranță, deoarece uneltele fac dezvoltarea să pară conversațională și cu fricțiune redusă.

Acest lucru înseamnă că organizațiile vor vedea mai multe aplicații, automatizări și integrări create de persoane care nu sunt instruite să ia în considerare limitele de încredere, validarea intrărilor, igiena dependențelor, controlul accesului sau expunerea datelor. Cu alte cuvinte, suprafața de atac se extinde nu doar pentru că IA scrie mai mult cod, ci și pentru că mai multe persoane pot genera fluxuri de lucru și sisteme care se comportă ca software fără a aplica disciplinele de inginerie de bază. Acest lucru face vizibilitatea și gardurile încorporate și mai importante, deoarece nu se poate presupune cunoașterea securității în punctul de creație.

Privind înainte, în următorii 12-24 de luni, ce tipuri de atacuri sau vulnerabilități așteptați să apară, în mod specific, din cauza fluxurilor de dezvoltare native AI?

Ne așteptăm ca multe dintre vulnerabilitățile de cod comun să fie evitate din start prin îmbunătățiri ale LLM-urilor însele sau prin reguli de prompt încorporate mai bune în „harness” care înconjoară aceste unelte. Dacă acum vedem o creștere a volumului de vulnerabilități doar din cauza vitezei crescute, acest lucru se va corecta de la sine. Și ceea ce nu se corectează va fi urmărit de instrumentele SAST și SCA activate de IA (unele dintre acestea vor fi, de asemenea, furnizate de furnizorii de platforme IA, de exemplu, Claude Code Security și proiectul Glasswing).

Însă, aștept rezultate mult mai grave atunci când vine vorba de expuneri din cauza utilizării uneltelor de IA neverificate și nesupravegheate în dezvoltarea de aplicații – cum ar fi agenții open-source (OpenClaw este un exemplu bun), care au setări de securitate slabă, combinată cu o bază de utilizatori a căror cunoașterea securității este mult depășită de entuziasmul pentru „vibe coding”.

Ca urmare, cred că vom asista la o schimbare către atacuri care vizează ecosistemul de dezvoltare în sine, mai degrabă decât doar sistemele de producție. Pe măsură ce IA devine parte a modului în care se creează software, atacatorii se vor concentra pe manipularea uneltelor și conexiunilor care formează acest proces, compromițând, în esență, software-ul înainte de a fi implementat vreodată.

Mulțumim pentru acest interviu minunat; cititorii care doresc să afle mai multe despre Backslash Security pot vizita Backslash Security.