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 för prompter. Innan detta hade han ledande roller på Aqua Security, där han tjänstgjorde som både 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 utvecklings- 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 teknik och storskaliga system.

Backslash Security är en ny 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 förskjuts mot AI-assisterade system är plattformen utformad för att säkerställa att säkerheten utvecklas parallellt snarare än att den blir en flaskhals, vilket placerar Backslash i 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 den kan hjälpa till att skriva kod snabbare, utan för att den har börjat omforma hela miljön runt programvaruskapandet.

Säkerheten 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ö expanderat till en vidsträckt, högt sammanlänkad 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 viss del av koden ä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äkerheten kan inte längre fokusera enbart på kodens utdata. Den måste ta hänsyn till hela miljön som gör att koden är möjlig.

Du beskriver “vibe coding” som att expandera angreppsytan bortom kod till prompter, 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 borde finnas främst i den genererade koden. Det är bara ett lager. I AI-baserad utveckling introduceras risk tidigare och på många fler ställen. Det kan vara i prompter, i den kontext som tillhandahålls till modellen, i de behörigheter som beviljas agenter, i de MCP-servrar de ansluter till eller i de 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 slutpunktsproblem som maskerar sig som ett AI-kodningsproblem. Till skillnad från kodsårbarheter kan detta inte bara utsätta dina applikationer för risk, utan även hela din organisation. 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äkerheten 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 tankeskiftning där säkerheten opererar bredvid 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 kontext 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äkerhetsgapen när team antar dessa verktyg utan en ordentlig styrningslager?

Det största gapet ä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.

Det andra största gapet ä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. Utan styrning på verktygs- och arbetsflödesnivå riskerar team att ge verktygen för stor behörighet som inte möter 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.

En tredje växande gap är att alla potentiellt kan bli utvecklare – det vi kallar “medborgarutvecklare”, som använder “vibe coding”-verktyg. När en person inom finans använder Claude Code för att automatisera processer och ansluta till interna system, skapar det potentiell risk och är en enorm blind fläck, även idag.

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

För att risken inte sitter någonstans i en enskild produkt i din stack. AI-baserad utveckling är i sig ett ekosystemproblem eftersom den opererar på så många olika ställen med så många olika verktyg. IDE, modell, agenter, MCP-servrar, externa plugins, identiteter och anslutna datakällor 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 bara en punkt i den kedjan, missar du fortfarande hur risken rör sig över systemet.

Promptning växer fram som ett nytt lager av programmerbarhet. Hur bör organisationer närma sig att skydda prompter och förhindra problem som promptinjektion, dataläckage eller manipulation?

Prompter formar alltmer logik och beteende. I många fall är de effektivt 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 infrastrukturbeskrivningar. I praktiken börjar det med att begränsa vad prompter kan komma åt och vilka nedströmsåtgärder de kan utlösa. Det betyder också att man definierar promptregler som överensstämmer med säkerhets- och kvalitetsförväntningar, förhindrar att känslig data exponeras genom kontextfönster och övervakar försök till manipulation, som promptinjektion eller indirekt instruktionskapning. Och det inkluderar att säkerställa att reglerna själva inte används som bakdörrar för promptinjektion. Den bredare punkten är att man inte säkrar promptning genom att instruera utvecklare och agenter att “vara försiktiga”. Man säkrar det genom att inbygga kontroller i miljön där promptning 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-baserad 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 åtkomst till kontext och system. Tillsammans formar de agentens faktiska beteende. Om dessa lager inte är tätt kontrollerade, förlorar organisationer synlighet i vad deras AI-verktyg kan göra och vad de faktiskt gör. Skiftet 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 kärnteman ä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 frånkopplad 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 bygga programvara med AI-verktyg. Hur förändrar uppkomsten av icke-utvecklar-“vibe coders” hotlandskapet?

Det utvidgar hotlandskapet på två sätt. Först, det ökar dramatiskt antalet människor 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ågfriktionsupplevelse.

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 “härden” som omger dessa verktyg. Om vi nu ser en ökning av volymen sårbarheter enbart på grund av ökad hastighet, kommer detta att korrigeras. Och det som inte korrigeras kommer att jagas av AI-aktiverad SAST och SCA (vissa av dessa kommer också att tillhandahållas av AI-plattformsleverantörerna, t.ex. Claude Code Security och projekt Glasswing).

Tack för den utmärkta intervjun. Läsare som vill lära sig mer kan besöka Backslash Security.