Shahar Man, medgrundare och VD för Backslash Security – Intervjuserie

Shahar Man, medgrundare och VD för Backslash Security, är en erfaren teknisk ledare med djup kunskap inom molntjänster, cybersäkerhet och företagsprogramvara. Han leder för närvarande Backslash Security, ett företag som fokuserar på att skydda AI-baserad programvaruutveckling, skydda allt från IDE:er och AI-agenter till genererad kod och arbetsflöden. Tidigare har han haft seniora ledningsroller på Aqua Security, där han var vice VD för produktledning och vice VD för FoU, och hjälpte till att bygga en av de ledande plattformarna för containertjänster över hela utvecklingslivscykeln. Tidigare i sin karriär tillbringade Man över ett decennium på SAP, där han ledde utveckling och produktinitiativ, inklusive SAP Web IDE, och arbetade nära med globala företagskunder, samtidigt som han bidrog till tillväxten av utvecklarekosystemet. Hans karriär började i tekniska och ledande roller i både startup-miljöer och Israels försvarstekniska enheter, vilket gav honom en stark grund i både ingenjörskap och storskaliga system.

Backslash Security är en framväxande cybersäkerhetsplattform som är specialbyggd för eran av AI-baserad programvaruutveckling. Företaget fokuserar på att skydda hela AI-baserade utvecklingsstacken, inklusive AI-agenter, kodgenereringspipelines och moderna utvecklararbetsflöden, ett område som traditionella säkerhetsverktyg ofta förbiser. Genom att tillhandahålla synlighet, styrning och realtidskydd utan att störa utvecklarnas hastighet, syftar Backslash till att hantera de växande riskerna som introduceras av automatiserad kodning och “vibe coding”-miljöer. Eftersom programvaruskapandet alltmer skiftar mot AI-assisterade system är plattformen utformad för att säkerställa att säkerheten utvecklas parallellt snarare än att bli en flaskhals, vilket placerar Backslash vid skärningspunkten mellan DevSecOps och nästa generations AI-utveckling.

Du har haft ledande roller inom produkt och FoU på företag som Aqua Security och SAP innan du grundade Backslash. Vilka tidiga signaler övertygade dig om att AI-baserad utveckling och “vibe coding” skulle förändra programvaruskapandet i grunden, och att säkerheten behövde byggas om för att stödja det?

Jag hade redan upplevt en stor förändring när programvaran flyttade till molnbaserade arkitekturer. På SAP och senare på Aqua såg vi förstahands att när utvecklingen förändras så mycket, ligger säkerheten vanligtvis efter. AI har tagit den sanningen till en helt ny nivå, inte bara för att det kan hjälpa till att skriva kod snabbare, utan för att det har börjat omforma hela miljön runt programvaruskapandet.

Säkerhet för kod är nu mindre om koden i sig och mer om miljön runt den. På mindre än ett år har det som tidigare var en relativt innesluten och lågriskig utvecklingsmiljö utvidgats till en väldigt sammanlänkad och osäker angreppsyta med liten tillsyn eller styrning. När det händer, förändras säkerhetsfrågorna runt kodsårbarheter helt. Det verkliga problemet är inte om en given kod är sårbar. Problemet är att vi, genom att möjliggöra AI-baserad utveckling, har introducerat system, agenter, integrationer och åtkomstvägar som sträcker sig långt bortom koden i sig. Säkerhet kan inte längre fokusera enbart på kodens utdata. Den måste ta hänsyn till hela miljön som gör att koden blir möjlig.

Du beskriver “vibe coding” som att utvidga angreppsytan bortom kod till prompt, agenter, MCP-servrar och verktygslager. Vilka är de mest missförstådda riskerna i denna nya stack som utvecklare och säkerhetsteam för närvarande förbiser?

Det största missförståndet är att många team fortfarande tror att risken främst bor i den genererade koden. Det är bara ett lager. I AI-baserad utveckling introduceras risk tidigare och på många fler platser. Det kan vara i prompt, i sammanhanget som tillhandahålls till modellen, i behörigheter som beviljats agenter, i MCP-servrar som de ansluter till, eller i externa verktyg och tillägg som utökar deras räckvidd. En enskild användares laptop kan tas över och användas som en brohuvud för en bredare attack. Det är en ändpunktsproblem som maskerar sig som ett AI-kodningsproblem. Till skillnad från kodsårbarheter kan detta inte bara sätta dina applikationer i fara – det kan sätta hela organisationen i fara. Om du bara tittar på koden, missar du större delen av bilden.

Traditionell programvarusäkerhet har fokuserat kraftigt på kodgranskning. Hur måste säkerhetstänkandet utvecklas när AI-agenter genererar, modifierar och distribuerar kod i realtid?

Säkerhet måste flytta från periodisk inspektion till kontinuerlig tillsyn. Begreppet “förtroende” är helt brutet – du kan ha betrodda modeller och betrodda MCP-servrar, men på grund av AI:s icke-deterministiska natur kan de fortfarande manipuleras eller bara bete sig på ett oväntat sätt för att skapa oväntad risk.

Detta innebär också att det måste ske en förändring i synsätt, där säkerhet fungerar sida vid sida med utvecklingsprocessen allteftersom den sker och har mycket djupare styrning, skydd och upptäckt- och responsförmåga inom den miljön. Det betyder att man kritiskt måste tänka på vilka verktyg som används, vilken sammanhang de konsumerar, vilka policys som bör styra dem och vilka åtgärder de vidtar i realtid.

Verktyg som Cursor, Claude Code och GitHub Copilot blir allt vanligare i utvecklarmiljöer. Var ser du de största säkerhetsluckorna när team antar dessa verktyg utan en ordentlig styrningslager?

Den största luckan är synlighet. I många organisationer sprids dessa verktyg snabbt utan en formell granskning. Säkerhetsteam är ofta omedvetna om vilka agenter som används, hur de är konfigurerade, vilken data de kan komma åt eller vilka externa system de är anslutna till. Det skapar ett “skugg-AI”-problem, som liknar “skugg-IT” i princip, fast snabbare och mer dynamiskt.

Den andra största luckan är bristen på genomförbara policys. De flesta organisationer kan ha riktlinjer, men riktlinjer ensamma hjälper inte mycket när en utvecklare rör sig snabbt inom IDE:t. Utan styrning på verktygs- och arbetsflödesnivå riskerar team att ge verktygen för stor behörighet som inte uppfyller företagsstandarder. Dessa verktyg är inte i sig dåliga, men att anta dem utan styrning innebär att man i praktiken skalar upp utvecklingshastigheten utan att skala upp kontrollen.

Backslash fokuserar på att skydda hela AI-utvecklingsekosystemet snarare än enskilda verktyg. Varför är detta fullständiga tillvägagångssätt nödvändigt, och vad händer om organisationer fortsätter att behandla dessa risker i isolering?

För att risken inte sitter inom någon enskild produkt i din stack. AI-baserad utveckling är i sig ett ekosystemproblem eftersom den opererar på så många olika platser, med så många olika verktyg. IDE:t, modellen, agenterna, MCP-servrarna, de externa tilläggen och de anslutna datasystemen alla påverkar vad som byggs och hur. Organisationer standardiserar inte medvetet på ett enda verktyg eftersom deras relativa styrkor förändras så snabbt. Om du säkrar endast en punkt i den kedjan, missar du fortfarande hur risken rör sig över systemet.

Prompting utvecklas som ett nytt lager av programmerbarhet. Hur bör organisationer närma sig att skydda prompt och förhindra problem som promptinjektion, dataläckage eller manipulation?

Prompting formar alltmer logik och beteende. I många fall är de i praktiken ett nytt kontrollplan för programvaruskapande. Det betyder att de behöver policy, övervakning och skyddsräcken liknande de som skulle finnas för kod eller infrastrukturdefinitioner. I praktiken börjar det med att begränsa vad prompt kan komma åt och vilka nedströmsåtgärder de kan utlösa. Det betyder också att definiera promptregler som stämmer överens med säkerhets- och kvalitetsförväntningar, förhindra att känslig data exponeras genom sammanhangsfönster och övervaka försök till manipulation, som promptinjektion eller indirekt instruktionskapning. Och det inkluderar att säkerställa att reglerna i sig inte används som bakdörrar för promptinjektion. Den bredare punkten är att du inte säkrar prompting genom att instruera utvecklare och agenter att “vara försiktiga”. Du säkrar det genom att inbygga kontroller i miljön där prompting faktiskt sker.

MCP-servrar och agentfärdigheter introducerar dynamiska anslutningar mellan system. Ur ett säkerhetsperspektiv, representerar de den största nya riskvektorn i AI-driven utveckling?

MCP-servrar och agentfärdigheter representerar ett stort nytt lager av risk eftersom de definierar hur AI-system ansluter till och interagerar med den verkliga världen. Färdigheter definierar vad en agent är bemyndigad att göra, medan MCP utökar dess tillgång till sammanhang och system. Tillsammans formar de agentens faktiska beteende. Om dessa lager inte är strängt kontrollerade, förlorar organisationer synlighet i vad deras AI-verktyg kan göra och vad de faktiskt gör. Övergången från att generera kod till att vidta åtgärder är vad som gör detta till ett så kritiskt område för säkerhet, och de blir mer oförutsägbara när du kedjar dem samman.

En av dina centrala teman är “att vara avdelningen för Ja” – att möjliggöra säkerhet utan att sakta ner utvecklare. Hur balanserar du realtidskydd med utvecklarhastighet i miljöer där hastighet är kritisk?

Säkerhet skapar friktion när den sker sent eller är kopplad från hur utvecklare faktiskt arbetar. Den blir mycket mer effektiv när den är inbäddad direkt i arbetsflödet och fokuserar på vad som verkligen betyder något. Det har varit en del av vår tanke sedan Backslash började, och det betyder ännu mer nu i AI-baserad utveckling.

Vi ser allt fler icke-tekniska användare som bygger programvara med AI-verktyg. Hur förändrar uppkomsten av icke-utvecklar-“vibe coders” hotlandskapet?

Det utvidgar hotlandskapet på två sätt. Först ökar det dramatiskt antalet personer som kan producera programvaru-liknande utdata utan att förstå säkerhetsimplikationerna. För det andra skapar det en falsk känsla av säkerhet eftersom verktygen gör utveckling till en konversations- och lågfriktionsprocess.

Om 12 till 24 månader, vilka typer av attacker eller sårbarheter förväntar du dig kommer att uppstå specifikt på grund av AI-baserade utvecklingsflöden?

Vi förväntar oss att många av de vanliga kodsårbarheterna kommer att undvikas från början genom förbättringar i LLM:erna själva, eller genom bättre inbäddade promptregler i “harnessen” som omger dessa verktyg. Om vi nu ser en ökning av volymen av sårbarheter enbart på grund av ökad hastighet, kommer detta att korrigeras. Och vad som inte korrigeras kommer att jagas av AI-aktiverad SAST och SCA (några av dessa kommer också att tillhandahållas av AI-plattformsleverantörerna, t.ex. Claude Code Security och projekt Glasswing).

Men jag förväntar mig mycket värre konsekvenser när det gäller exponering på grund av användning av otestade och osuperverade AI-verktyg i programvaruutveckling – som open-source-agenter (OpenClaw är ett bra exempel), som har mycket dåliga säkerhetsstandarder i kombination med en användarbas vars kunskap om säkerhet vida överträffas av deras entusiasm för “vibe coding”.

Som en följd tror jag att vi kommer att se en skiftning mot attacker som riktar sig mot utvecklingsekosystemet i sig, snarare än bara produktionsystem. När AI blir en del av hur programvara skapas, kommer angripare att fokusera på att manipulera verktygen och anslutningarna som formar den processen, och därmed kompromettera programvara innan den ens distribueras.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Backslash Security.