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 o profundă expertiză în dezvoltarea de cloud, securitate cibernetică și software pentru întreprinderi. El conduce în prezent Backslash Security, o companie care se axează 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 cercetării și dezvoltării, ajutând la construirea uneia dintre principalele platforme de securitate a containerelor pe tot parcursul ciclului de dezvoltare. Mai devreme în cariera sa, 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 cu 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ă creată special pentru era dezvoltării software bazate pe inteligență artificială. Compania se concentrează pe securizarea întregului stivuit 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 codarea automată și medii de „vibe coding”. Pe măsură ce crearea de software se îndreaptă tot mai mult către sisteme asistate de inteligență artificială, platforma este proiectată pentru a asigura faptul că securitatea evoluează în paralel, și nu devine un punct de strangulare, poziționând Backslash la intersecția dintre DevSecOps și dezvoltarea de inteligență artificială de generație următoare.

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 primele semne care v-au convins că dezvoltarea nativă AI și „vibe coding” vor schimba fundamental crearea de software, și că securitatea trebuie reconstruită pentru a susține acest lucru?

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ă. Inteligența artificială a dus această realitate la un nivel cu totul nou, nu doar pentru că poate ajuta la scrierea de cod mai rapid, dar și pentru că a început să reshapeze întregul mediu din jurul creării de software.

Securizarea codului nu mai este doar despre codul în sine, ci și 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 foarte 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 cu totul. Problema reală nu este dacă un anumit fragment de cod este vulnerabil. Problema este că, prin dezvoltarea bazată pe inteligență artificială, 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 stivuit pe care dezvoltatorii și echipele de securitate le omit în prezent?

Cea mai mare neînțelegere 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 mult mai 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 codare AI. În contrast cu vulnerabilitățile codului, aceasta nu pune doar aplicațiile în pericol, ci poate pune întreaga organizație în pericol. Dacă vă uitați doar la cod, pierdeți cea mai mare parte a imaginii de ansamblu.

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

Securitatea trebuie să treacă de la inspecția periodică la supraveghere continuă. Noțiunea de încredere este complet spulberată – puteți avea modele și servere MCP de încredere, dar din cauza naturii nedeterminate a inteligenței artificiale, 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 acesta 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 ce instrumente sunt utilizate, ce context consumă, ce politici ar trebui să le guverneze și ce acțiuni îndeplinesc în timp real.

În plus, nu putem ignora rolul inteligenței artificiale și al modelelor de inteligență artificială în gestionarea vulnerabilităților. Dacă acum un an modelele de inteligență artificială produceau multe vulnerabilități din oficiu, lucrurile s-au îmbunătățit considerabil, iar alte modele sunt acum utilizate pentru a găsi vulnerabilități zero-day care nu au fost găsite înainte. Deci, ne îndreptăm spre 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 adecvat de guvernanță?

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 sunt conectate. Acest lucru creează o problemă de „umbra AI”, similară cu „umbra IT” în principiu, doar că mai rapidă și mai dinamică.

Cea de-a doua lacună ca mărime este lipsa unor politici impuse. Majoritatea organizațiilor pot avea linii directoare, dar acestea nu ajută prea mult atunci când un dezvoltator se mișcă rapid în interiorul IDE-ului. Fără guvernanță la nivel de instrument și flux de lucru, echipele riscă să aibă unelte supra-permise care nu corespund standardelor î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ă în curs de apariție este că oricine poate deveni, în mod potențial, un dezvoltator – ceea ce numim „dezvoltatori cetățeni”, care folosesc unelte de „vibe coding”. Când o persoană din departamentul financiar folosește 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ă abordarea full-stack, și ce se întâmplă dacă organizațiile continuă să trateze aceste riscuri în mod izolat?

Pentru că riscul nu se află în mod neapărat în interiorul unui 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, plugin-urile externe ș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 acea lanț, încă mai ratați modul în care riscul se deplasează prin sistem.

Tratarea acestor riscuri în mod izolat conduce la apărări fragmentate și puncte oarbe periculoase. Puteți întări scannerul de cod, dar puteți ignora serverul MCP care a alimentat contextul riscant în model. 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 programabilitate. Cum ar trebui organizațiile să abordeze securizarea promptelor și prevenirea problemelor precum injecția de prompte, scurgerea de date sau manipularea?

Promptele formează din ce în ce mai mult logica și comportamentul. În multe cazuri, acestea 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 acțiunilor pe care le pot declanșa. Acest lucru înseamnă, de asemenea, definirea regulilor de prompt care se aliniază cu așteptările de securitate și calitate, prevenirea expunerii datelor sensibile prin ferestrele de context și monitorizarea încercărilor de manipulare, cum ar fi injecția de prompte sau hijacking-ul indirect de instrucțiuni. Și, de asemenea, asigurarea că regulile însele nu sunt utilizate ca o poartă de intrare pentru injecția de prompte. Punctul mai larg este că nu securizați promptele instruind dezvoltatorii și agenții să „aibă grijă”. Le securizați încorporând controale î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 vectorul de risc cel mai semnificativ în dezvoltarea condusă de inteligență artificială?

Serverele MCP și abilitățile agenților reprezintă un strat major de risc nou, deoarece definesc cum interacționează sistemele de inteligență artificială cu lumea reală. Abilitățile definesc ce poate face un agent, în timp ce MCP extinde accesul său la context și sisteme. Împreună, acestea 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 AI. Trecerea de la generarea de cod 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 deconectată 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 inteligență artificială.

În practică, acest lucru înseamnă prezentarea problemelor care reprezintă, cu adevărat, riscuri, și nu inundați dezvoltatorii cu tot ceea ce pare suspect, teoretic. Acest lucru înseamnă impunerea politicii în IDE și fluxul de lucru al agentului, și nu după aceea. Și înseamnă crearea unor garduri transparente și deterministice, astfel încât echipele să poată mișca rapid, în timp ce știu, totuși, care sunt uneltele utilizate, ce permisiuni au și când se întâmplă ceva anormal. Scopul nu este să încetineze adoptarea inteligenței artificiale, 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, din start, 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-dezvoltatori 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ă inteligența artificială 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 mai poate presupune cunoașterea securității la punctul de creație.

Privind înainte, în următorii 12 până la 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 modelelor de inteligență artificială sau prin reguli de prompt încorporate mai bune în „harnașamentul” care înconjoară aceste unelte. Dacă acum un an modelele de inteligență artificială produceau multe vulnerabilități din oficiu, lucrurile s-au îmbunătățit considerabil, iar alte modele sunt acum utilizate pentru a găsi vulnerabilități zero-day care nu au fost găsite înainte. Deci, ne îndreptăm spre ieșiri mai bune – dar ce nu este corectat va fi urmărit de instrumentele SAST și SCA activate de inteligență artificială (unele dintre acestea vor fi, de asemenea, oferite de furnizorii de platforme AI, de exemplu, Claude Code Security și proiectul Glasswing).

Însă, aștept rezultate mult mai grave atunci când vine vorba de expuneri datorate utilizării uneltelor de inteligență artificială 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 foarte slabe, asociate cu o bază de utilizatori a căror cunoașterea securității este mult depășită de entuziasmul lor 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 inteligența artificială devine parte a modului în care se creează software, atacatorii se vor concentra pe manipularea uneltelor și conexiunilor care formează acel proces, compromițând, în esență, software-ul înainte de a fi deployat.

Mulțumim pentru acest interviu minunat; cititorii care doresc să afle mai multe despre acest subiect ar trebui să viziteze Backslash Security.