Shahar Man, medgrunnlegger og administrerende direktør i Backslash Security – Intervju-serie

Sharar Man, medgrunnlegger og administrerende direktør i 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 container-sikkerhet 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, samt bidro til vekst i utvikler-økosystemet. Hans karriere begynte i tekniske og ledende roller i både startup-miljøer og Israels forsvarsteknologi-enheter, noe som ga ham en sterk grunnlag i både ingeniørvitenskap og stor-skala systemer.

Backslash Security er en fremvoksende cybersikkerhetsplattform som er bygget for årenes AI-drevne programvareutvikling. Selskapet fokuserer på å sikre hele AI-naturlige utviklingsstakken, inkludert AI-agenter, kodegenererings-pipelines og moderne utvikler-workflows, et område som tradisjonelle sikkerhetsteknologier ofte overseer. Ved å gi visibilitet, styring og sanntidsbeskyttelse uten å forstyrre utviklerhastigheten, har Backslash som mål å løse de økende risikoene som introduseres av automatisert kode og “vibe coding”-miljøer. Ettersom programvare-skaping stadig mer går over til AI-assisterte systemer, er plattformen designet for å sikre at sikkerheten utvikler seg parallelt, i stedet for å 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 forandre programvare-skaping fundamentalt, og at sikkerheten måtte bygges om for å støtte det?

Jeg hadde allerede vært med på en stor endring da programvaren flyttet over til 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 til å skrive kode raskere, men fordi det har begynt å endre hele miljøet rundt programvare-skaping.

Sikkerheten av kode er nå mindre om koden selv og mer om miljøet rundt den. På mindre enn ett år, har det som tidligere var et relativt innestengt og lav-risiko utviklingsoppsett, utvidet seg til et spredt, høyt-tilkoblet angrepsflate med liten oversikt eller styring. Når det skjer, endrer sikkerhets-spørsmålene rundt kode-sårbarheter seg fullstendig. Det virkelige problemet er ikke om en gitt kode er sårbar. Problemene er at ved å aktivere AI-drevet utvikling, har vi introdusert systemer, agenter, integrasjoner og tilgangsveier som strekker seg langt utenfor koden 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 prompter, agenter, MCP-servere og verktøy-lag. 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 ligger 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 prompter, i konteksten som leveres til modellen, i tillatelser gitt til agenter, i MCP-servere de kobler til, eller i eksterne verktøy og utvidelser som utvider deres rekkevidde. En enkelt brukers bærbare PC kan tas over og brukes som brohode for en bredere angrep. Det er et endpoint-problem som maskeerer seg som et AI-koding-problem. I motsetning til kode-sårbarheter, setter dette ikke bare applikasjonene dine i risiko – det kan sette hele organisasjonen i risiko. Hvis du bare ser på koden, så overseer du mesteparten av bildet.

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

Sikkerheten må flytte seg fra periodisk inspeksjon til kontinuerlig tilsyn. Begrepet “tillit” er fullstendig brutt — du kan ha tillitsfulle modeller og tillitsfulle MCP-servere, men på grunn av AI sin ikke-deterministiske natur, kan de likevel bli manipulert eller bare mislykkes og skape uventet risiko.

Dette betyr også at det må være en endring i tankesettet, hvor sikkerheten opererer side om side med utviklingsprosessen mens den skjer, og har mye dypere styring, retningslinjer og oppdaging- og respons-egenskaper innenfor det miljøet. Det betyr å tenke kritisk om hvilke verktøy som brukes, hva konteksten de forbruker er, hvilke retningslinjer som skal styre dem, og hvilke handlinger de tar i sanntid.

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

Det største hull er visibiliteten. I mange organisasjoner, spreder disse verktøyene seg raskt og uten en formell gjennomgang. Sikkerhetsteamene vet ofte ikke hvilke agenter som brukes, hvordan de er konfigurert, hvilke data de kan aksessere, eller hvilke eksterne systemer de er koblet til. Det skaper et skygge-AI-problem, som er lignende til skygge-IT i prinsipp, bare raskere og mer dynamisk.

Det andre største hull er mangelen på tvangsbare retningslinjer. 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øy- og workflow-laget, risikerer teamene å over-tilgjengeliggjøre verktøy som ikke møter bedrifts-standarder. Disse verktøyene er ikke i seg selv dårlige, men å adoptere dem uten styring betyr at du effektivt skalerer utviklerhastighet uten å skale kontroll.

Backslash fokuserer på å sikre hele AI-utviklings-økosystemet i stedet for enkelt-verktøy. Hvorfor er denne full-stakk-tilnærmingen nødvendig, og hva skjer hvis organisasjoner fortsetter å behandle disse risikoene i isolasjon?

Fordi risiko ikke sitter pent 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-serverne, eksterne verktøy og utvidelser, identitetene og koblete datakilder 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å overseer du hvordan risiko flytter seg over systemet.

Prompting er en ny lag av programmabilitet. Hvordan bør organisasjoner nærme seg å sikre prompter og forhindre problemer som prompt-injeksjon, data-lekkasje eller manipulering?

Prompting former logikk og atferd i stor grad. I mange tilfeller er de effektivt en ny kontrollflate for programvare-skaping. Det betyr at de trenger retningslinjer, overvåking og retningslinjer, akkurat som kode eller infrastruktur-definisjoner ville. Praktisk talt, begynner det med å begrense hva prompter kan aksessere og hva nedstrøms-handlinger de kan utløse. Det betyr også å definere prompt-regler som samsvare med sikkerhets- og kvalitetsforventninger, forhindre følsomme data fra å bli avdekket gjennom kontekst-vinduer, og å overvåke forsøk på manipulering, som prompt-injeksjon eller indirekte instruksjons-hijacking. Og det inkluderer også å sikre at reglene 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-servere og agent-ferdigheter introduserer dynamiske koblinger mellom systemer. Fra et sikkerhetsperspektiv, representerer de den største nye risiko-vektoren i AI-drevet utvikling?

MCP-servere og agent-ferdigheter representerer en stor ny 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 visibilitet 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 så kritisk område for sikkerhet, og de blir mer uforutsigbare når du kobler dem sammen.

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

Sikkerheten 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-drevet utvikling.

Vi ser en økning i antall ikke-tekniske brukere som bygger programvare med AI-verktøy. Hvordan endrer denne økningen i antall “vibe-codere” trussellandskapet?

Det utvider trussellandskapet på to måter. Først, øker det dramatisk antall personer som kan produsere programvare-lignende utdata uten å forstå sikkerhetsimplikasjonene. For det andre, skaper det en falsk følelse av trygghet, fordi verktøyene gjør utviklingen til å føles konversasjons- og lav-friksjons.

Ser vi fremover 12 til 24 måneder, hvilke typer angrep eller sårbarheter forventer du å se som en direkte følge av AI-naturlige utviklings-workflows?

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 selv, vil bli jaget av AI-aktivert SAST og SCA.

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