Shahar Man, medgrunnlegger og CEO av Backslash Security – Intervju-serie

Shahar Man, medgrunnlegger og CEO av Backslash Security, er en erfaren teknologileder med dypt kunnskap innen skyutvikling, cybersikkerhet og bedriftsprogramvare. Han leder for tiden Backslash Security, et selskap som fokuserer på å sikre AI-naturlig programvareutvikling, beskytter alt fra IDE-er og AI-agenter til generert kode og prompt-workflows. Før dette, hadde han ledende roller i Aqua Security, der han var visepresident for produktledelse og visepresident for FoU, og hjalp til å bygge en av de ledende plattformene for containersistikkerhet gjennom utviklingslivssyklusen. Tidligere i sin karriere, tilbrakte Man over ett tiår i SAP, der han ledet utvikling og produktinitiativer, inkludert SAP Web IDE, og arbeidet tett med globale bedriftskunder, samtidig som han bidro til å vokse utviklerøkosystemet. Hans karriere begynte i tekniske og ledende roller i både startup-miljøer og Israels forsvarsteknologienheter, noe som ga ham en sterk grunnlag i både ingeniørvitenskap og storskala-systemer.

Backslash Security er en oppkomende cybersikkerhetsplattform som er tilpasset for årene med AI-dreven programvareutvikling. Selskapet fokuserer på å sikre hele AI-naturlige utviklingsstakken, inkludert AI-agenter, kodegenereringsrørledninger og moderne utviklerworkflows, et område som tradisjonelle sikkerhetsverktøy ofte overseer. Ved å gi synlighet, styring og sanntidsbeskyttelse uten å forstyrre utviklerhastigheten, sikter Backslash på å løse de økende risikoene som introduseres av automatisert kode og “vibe coding”-miljøer. Ettersom programvareutvikling stadig mer går mot AI-assisterte systemer, er plattformen designet for å sikre at sikkerheten utvikles parallelt, snarere enn å bli en flaskehals, og plasserer Backslash på skjæringspunktet mellom DevSecOps og neste generasjons AI-utvikling.

DU har hatt ledende roller i produkt og FoU i selskaper som Aqua Security og SAP før du grunnla Backslash. Hva var de tidlige signalene som overbeviste deg om at AI-naturlig utvikling og vibe coding ville fundamentalt endre programvareutvikling, og at sikkerheten måtte bygges om for å støtte det?

Jeg hadde allerede vært gjennom en stor endring da programvaren flyttet inn i sky-naturlige arkitekturer. Hos SAP og senere hos Aqua, så vi førstehånd at når utviklingen endrer seg så mye, så ligger sikkerheten vanligvis etter. AI har tatt denne sannheten til et helt nytt nivå, ikke bare fordi det kan hjelpe med å skrive kode raskere, men fordi det har begynt å endre hele miljøet rundt programvareutvikling.

Sikkerheten for kode er nå mindre om koden i seg selv og mer om miljøet rundt den. På mindre enn ett år, har det som tidligere var et relativt innestengt og lavrisikoutviklingsoppsett, utvidet seg til et spredt, høyt tilkoblet angrepsflate med liten tilsyn eller styring. Når det skjer, endrer sikkerhetsproblemene rundt kodevulnerabiliteter seg fullstendig. Det virkelige problemet er ikke om en gitt del kode er sårbær, men at ved å aktivere AI-dreven utvikling, har vi introdusert systemer, agenter, integrasjoner og tilgangsveier som strekker seg langt utenfor koden i seg selv. Sikkerheten kan ikke lenger fokusere bare på koden. Den må ta hensyn til hele miljøet som gjør at koden er mulig.

DU beskriver vibe coding som å utvide angrepsflaten utenfor kode til promter, agenter, MCP-serveere og verktøyslag. Hva er de mest misforståtte risikoene i denne nye stakken som utviklere og sikkerhetsteam nå overseer?

Det største misforståelsen er at mange team fortsatt tror at risikoen bor hovedsakelig i den genererte koden. Det er bare ett lag. I AI-naturlig utvikling, introduseres risiko tidligere og på mange flere steder. Dette kan være i promter, i konteksten som leveres til modellen, i tilgangene som gis til agenter, i MCP-serveere de kobler til, eller i eksterne verktøy og utvidelser som utvider deres rekkevidde. En enkelt brukers bærbare datamaskin kan tas over og brukes som brohode for en bredere angrep. Det er et endepunktsproblem som maskeerer seg som et AI-kodingproblem. I motsetning til kodevulnerabiliteter, setter dette ikke bare applikasjonene dine i risiko – det kan sette hele organisasjonen i risiko. Hvis du bare ser på koden, så må du over hele bildet.

Tradisjonell applikasjonssikkerhet har fokusert tungt på kodegjennomgang. Hvordan må sikkerhetstenkningen utvikle seg når AI-agenter genererer, modifierer og distribuerer kode i sanntid?

Sikkerheten må flytte seg fra periodisk inspeksjon til kontinuerlig tilsyn. Begrepet tillit er fullstendig ødelagt – du kan ha tillitsfulle modeller og tillitsfulle MCP-serveere, men på grunn av den ikke-deterministiske naturen til AI, kan de likevel bli manipulert eller bare mislykkes og skape uventet risiko.

Dette betyr også at det må være en holdningsendring i hvilken sikkerhet opererer side om side med utviklingsprosessen mens den skjer, og har mye dypere styring, guardrails og oppdaging og responsmuligheter innen det miljøet. Det betyr å tenke kritisk om hvilke verktøy som brukes, hva konteksten de forbruker er, hvilke politikker som skal styre dem, og hvilke handlinger de tar i sanntid.

Verktøy som Cursor, Claude Code og GitHub Copilot blir standard i utviklerworkflows. Hvor ser du de største sikkerhetshullene når team adopterer disse verktøyene uten en ordentlig styringslag?

Det største hull er synlighet. I mange organisasjoner, sprenger disse verktøyene seg raskt og uten en formell gjennomgang. Sikkerhetsteamene vet ofte ikke hvilke agenter som brukes, hvordan de er konfigurert, hva data de kan få tilgang til, eller hvilke eksterne systemer de er koblet til. Det skaper et skygge-AI-problem, som er likt skygge-IT i prinsippet, bare raskere og mer dynamisk.

Det nest største hull er mangelen på tvangsbare politikker. De fleste organisasjoner kan ha retningslinjer, men retningslinjer alene hjelper ikke mye når en utvikler flytter raskt innenfor IDE-en. Uten styring på verktøys- og workflow-laget, risikerer teamene over-tilgangsverktøy som ikke møter bedriftsstandarder. Disse verktøyene er ikke i seg selv dårlige, men å adoptere dem uten styring betyr at du effektivt skalerer utviklingshastighet uten å skalerer kontroll.

Et tredje fremvoksende hull er at alle potensielt kan bli utviklere – hva vi kaller borgerutviklere, som bruker vibe-coding-verktøy. Når finanspersonen bruker Claude Code for å automatisere prosesser og koble til interne systemer, skaper dette potensiell risiko og er et stort blindpunkt, selv i dag.

Backslash fokuserer på å sikre hele AI-utviklingsekosystemet, snarere enn enkeltverktøy. Hvorfor er denne fullstendige tilnærmingen nødvendig, og hva skjer hvis organisasjoner fortsetter å behandle disse risikoene i isolasjon?

Fordi risiko ikke bor nøyaktig innenfor ett enkelt produkt i din stakk. AI-naturlig utvikling er en økosystem-problem, fordi den opererer i så mange forskjellige steder, og bruker så mange forskjellige verktøy. IDE-en, modellen, agentene, MCP-serveerne, eksterne plugin-ene, identitetene og de tilkoblede datasource-ene alle påvirker hva som bygges og hvordan. Organisasjoner standardiserer ikke på ett enkelt verktøy, fordi deres relative styrker endrer seg så raskt. Hvis du sikrer bare ett punkt i den kjeden, så må du likevel overse hvordan risiko flytter seg over systemet.

Prompting oppstår som et nytt lag av programmerbarhet. Hvordan bør organisasjoner nærme seg å sikre promter og forhindre problemer som prompt-injeksjon, datalekkasje eller manipulering?

Promter former i økende grad logikk og atferd. I mange tilfeller, er de effektivt et nytt kontrollplan for programvareutvikling. Det betyr at de trenger politikk, overvåking og guardrails, like som kode eller infrastrukturdefinisjoner ville. Praktisk talt, begynner det med å begrense hva promter kan få tilgang til og hva nedstrøms handlinger de kan utløse. Det betyr også å definere prompt-regler som samsvare med sikkerhets- og kvalitetsforventninger, forhindre sensitive data fra å bli eksponert gjennom kontekstvinduer, og å overvåke for manipulasjonsforsøk som prompt-injeksjon eller indirekte instruksjons-hijacking. Og det inkluderer også å sikre at reglene i seg selv ikke brukes som bakdører for prompt-injeksjon. Det bredere poenget er at du ikke sikrer prompting ved å instruere utviklere og agenter til å “være forsiktige”. Du sikrer det ved å innbygge kontroller i miljøet der prompting faktisk skjer.

MCP-serveere og agent-ferdigheter introduserer dynamiske forbindelser mellom systemer. Fra et sikkerhetsperspektiv, representerer disse den største nye risikovektoren i AI-dreven utvikling?

MCP-serveere og agent-ferdigheter representerer et større nytt lag av risiko, fordi de definerer hvordan AI-systemer kobler til og interagerer med den virkelige verden. Ferdigheter definerer hva en agent er berettiget til å gjøre, mens MCP utvider dens tilgang til kontekst og systemer. Sammen, former de agentens faktiske atferd. Hvis disse lagene ikke er tett kontrollert, mister organisasjoner synlighet i hva deres AI-verktøy er i stand til å gjøre og hva de faktisk gjør. Skiftet fra å generere kode til å utføre handlinger er det som gjør dette til et kritisk område for sikkerhet, og de blir mer uforutsigbare når du kjeder dem sammen.

En av dine kjernetemaer er “å være avdelingen for ja” – å aktivere sikkerhet uten å bremse utviklere ned. Hvordan balanserer du sanntidsbeskyttelse med utviklerhastighet i miljøer der hastighet er kritisk?

Sikkerhet skaper friksjon når den skjer sent eller er frakoblet fra hvordan utviklere faktisk arbeider. Den blir mye mer effektiv når den er innbygd direkte i workflowen og fokusert på hva som virkelig betyr noe. Det har vært en del av vår tenkning siden Backslash begynte, og det betyr enda mer nå i AI-dreven utvikling.

VI ser en økning i antall ikke-tekniske brukere som bygger programvare med AI-verktøy. Hvordan endrer denne økningen trussel-landskapet?

Det utvider trussel-landskapet på to måter. Først, øker det dramatisk antall personer som kan produsere programvare-lignende utdata uten å forstå sikkerhetsimplikasjonene. Andre, skaper det en falsk følelse av sikkerhet, fordi verktøyene gjør utvikling til å føles konversasjonelt og lav-friction.

Det betyr at organisasjoner vil se flere applikasjoner, automatiseringer og integrasjoner som er skapt av personer som ikke er trent til å vurdere tillitsgrenser, inndata-validering, avhengighygiene, tilgangskontroll eller dataeksponering. Med andre ord, utvider angrepsflaten ikke bare fordi AI skriver mer kode, men fordi flere mennesker nå kan generere workflows og systemer som oppfører seg som programvare uten å anvende grunnleggende, hygienisk ingeniørdisiplin. Det gjør synlighet og innbygde sikkerhetsskranke enda viktigere, fordi du ikke lenger kan anta sikkerhetskunnskap på skapingspunktet.

SEENDE fremover 12 til 24 måneder, hva slags angrep eller sårbarheter forventer du å se spesifikt på grunn av AI-naturlige utviklingsworkflows?

VI forventer at mange av de vanlige kode-sårbarhetene vil unngås på forhånd gjennom forbedringer i LLM-ene selv, eller gjennom bedre innbygde prompt-regler i “harness”-en som omgir disse verktøyene. Hvis vi nå ser en økning i volumet av sårbarheter bare på grunn av økt hastighet, vil dette korrigere seg selv. Og hva som ikke korrigere seg, vil bli jaget ned av AI-aktivert SAST og SCA (noen av disse vil også bli levert av AI-plattformleverandørene, f.eks. Claude Code Security og prosjekt Glasswing).

Imidlertid forventer jeg mye verre resultater når det gjelder eksponeringer på grunn av bruk av uverifiserte og usuperviserte AI-verktøy i programvareutvikling – som åpne kilde-agenter (OpenClaw er et godt eksempel), som har svært dårlige sikkerhetsstandarder kombinert med en brukerbase hvis kunnskap om sikkerhet langt overgås av deres entusiasme for vibe-coding.

Som en konsekvens, tror jeg vi vil se en skifte mot angrep som tar sikte på utviklingsekosystemet selv, snarere enn bare produksjonssystemer. Ettersom AI blir en del av hvordan programvare skapes, vil angripere fokusere på å manipulere verktøyene og forbindelsene som former prosessen, og effektivt kompromittere programvare før den noen gang deployes.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Backslash Security.