Shahar Man, mede-oprichter en CEO van Backslash Security – Interviewreeks

Shahar Man, mede-oprichter en CEO van Backslash Security, is een ervaren technologie-leider met diepgaande expertise in cloud-ontwikkeling, cybersecurity en enterprise-software. Hij leidt momenteel Backslash Security, een bedrijf dat zich richt op het beveiligen van AI-native software-ontwikkelomgevingen, waarbij alles wordt beschermd, van IDE’s en AI-agents tot gegenereerde code en prompting-workflows. Voordat hij deze functie bekleedde, had hij senior-leiderschapsrollen bij Aqua Security, waar hij zowel vice-president van Product Management als vice-president van R&D was en hielp bij het opbouwen van een van de toonaangevende platforms voor containerbeveiliging gedurende de ontwikkelingscyclus. Eerder in zijn carrière werkte Man meer dan een decennium bij SAP, waar hij ontwikkelings- en productinitiatieven leidde, waaronder SAP Web IDE, en nauw samenwerkte met wereldwijde ondernemingsklanten, evenals bijdroeg aan de groei van de ontwikkelaarsgemeenschap. Zijn carrière begon in technische en leiderschapsrollen in zowel start-ups als defensietechnologie-eenheden in Israël, waardoor hij een sterke basis had in zowel techniek als grote systeemintegratie.

Backslash Security is een opkomend cybersecurity-platform dat speciaal is ontwikkeld voor de era van AI-gedreven software-ontwikkeling. Het bedrijf richt zich op het beveiligen van de volledige AI-native ontwikkelstack, inclusief AI-agents, codegeneratiepijplijnen en moderne ontwikkelaarsworkflows, een gebied dat traditionele beveiligingstools vaak over het hoofd zien. Door zichtbaarheid, governance en real-time beveiliging te bieden zonder de ontwikkelsnelheid te verstoren, streeft Backslash ernaar de groeiende risico’s die worden geïntroduceerd door geautomatiseerde coding en “vibe coding”-omgevingen aan te pakken. Aangezien softwarecreatie steeds meer verschuift naar AI-gestuurde systemen, is het platform ontworpen om ervoor te zorgen dat beveiliging parallel evolueert in plaats van een bottleneck te worden, waardoor Backslash zich bevindt op het snijvlak van DevSecOps en next-generation AI-ontwikkeling.

U hebt leiderschapsrollen gehad in product en R&D bij bedrijven als Aqua Security en SAP voordat u Backslash oprichtte. Wat waren de vroege signalen die u ervan overtuigden dat AI-native ontwikkeling en vibe coding de softwarecreatie fundamenteel zouden veranderen, en dat beveiliging opnieuw moest worden opgebouwd om het te ondersteunen?

Ik had al een grote verschuiving meegemaakt toen software naar cloud-native architectuur verhuisde. Bij SAP en later bij Aqua zagen we firsthand dat wanneer ontwikkeling zo veel verandert, beveiliging meestal achterblijft. AI heeft die waarheid naar een geheel nieuw niveau getild, niet alleen omdat het kan helpen bij het schrijven van code sneller, maar omdat het de hele omgeving rond softwarecreatie heeft veranderd.

Beveiligen van code is nu minder over de code zelf en meer over de omgeving eromheen. In minder dan een jaar is wat eerst een relatief beperkte en laag-risico ontwikkelomgeving was, uitgebreid tot een uitgebreid, sterk verbonden aanvalsoppervlak met weinig toezicht of governance. Zodra dat gebeurde, veranderden de beveiligingsvragen rond codekwetsbaarheden helemaal. Het echte probleem is niet of een bepaald stuk code kwetsbaar is. Het probleem is dat we, door AI-gedreven ontwikkeling mogelijk te maken, systemen, agents, integraties en toegangspaden hebben geïntroduceerd die verder reiken dan de code zelf. Beveiliging kan zich niet langer alleen richten op de output van code. Het moet rekening houden met de hele omgeving die die code mogelijk maakt.

U beschrijft vibe coding als het uitbreiden van het aanvalsoppervlak buiten code naar prompts, agents, MCP-servers en toolinglagen. Wat zijn de meest misverstane risico’s in deze nieuwe stack die ontwikkelaars en beveiligingsteams op dit moment over het hoofd zien?

De grootste misverstand is dat veel teams nog steeds denken dat het risico voornamelijk in de gegenereerde code zit. Dat is maar één laag. In AI-native ontwikkeling wordt risico eerder en op veel meer plaatsen geïntroduceerd. Dit kan zijn in prompts, in de context die aan het model wordt geleverd, in de machtigingen die aan agents worden verleend, in de MCP-servers waarmee ze verbonden zijn, of in de externe tools en plugins die hun bereik uitbreiden. Een enkele gebruiker laptop kan worden overgenomen en gebruikt als bruggehoofd voor een bredere aanval. Het is een eindpunt-pijnplek die zich voordoet als een AI-codingprobleem. In tegenstelling tot codekwetsbaarheden, brengt dit niet alleen uw toepassingen in gevaar, maar kan het uw hele organisatie in gevaar brengen. Als u alleen naar de code kijkt, mist u het grootste deel van het beeld.

Traditionele applicatiebeveiliging heeft zich sterk gericht op codebeoordeling. Hoe moet beveiligingsdenken evolueren wanneer AI-agents code genereren, wijzigen en implementeren in real-time?

Beveiliging moet verschuiven van periodieke inspectie naar continue toezicht. Het concept van vertrouwen is volledig verbroken – u kunt vertrouwde modellen en vertrouwde MCP-servers hebben, maar vanwege de niet-deterministische aard van AI, kunnen ze nog steeds worden gemanipuleerd of gewoon misgedragen om onverwacht risico te creëren.

Dit betekent ook dat er een mentaliteitsverandering moet komen waarin beveiliging naast het ontwikkelproces werkt en veel diepere governance, beveiligingshekken en detectie- en responsmogelijkheden binnen die omgeving heeft. Dat betekent kritisch nadenken over welke tools worden gebruikt, welke context ze consumeren, welke beleidsregels ze moeten volgen en welke acties ze in real-time uitvoeren.

Tools zoals Cursor, Claude Code en GitHub Copilot worden standaard in ontwikkelaarsworkflows. Waar ziet u de grootste beveiligingsgaten wanneer teams deze tools aannemen zonder een juiste governance-laag?

Het grootste gat is zichtbaarheid. In veel organisaties verspreiden deze tools zich snel zonder formele beoordeling. Beveiligingsteams weten vaak niet welke agents worden gebruikt, hoe ze zijn geconfigureerd, welke gegevens ze kunnen benaderen of welke externe systemen ze zijn verbonden met. Dat creëert een schaduw-AI-probleem, dat in principe vergelijkbaar is met schaduw-IT, maar sneller en dynamischer.

Het tweede grootste gat is het ontbreken van afdwingbare beleidsregels. De meeste organisaties hebben richtlijnen, maar richtlijnen alleen helpen niet veel wanneer een ontwikkelaar snel werkt binnen de IDE. Zonder governance op tool- en workflow-niveau riskeren teams over-geautoriseerde tools die niet voldoen aan ondernemingsstandaarden. Deze tools zijn op zichzelf niet slecht, maar het aannemen ervan zonder governance betekent dat u effectief ontwikkelsnelheid schaalt zonder controle te schalen.

Een derde opkomend gat is dat iedereen potentieel een ontwikkelaar kan worden – wat we noemen burger-ontwikkelaars, die vibe-coding-tools gebruiken. Wanneer de financiële persoon Claude Code gebruikt om processen te automatiseren en te verbinden met interne systemen, creëert dit potentieel risico en is het een grote blinde vlek, zelfs vandaag de dag.

Backslash richt zich op het beveiligen van het hele AI-ontwikkelings-ecosysteem in plaats van individuele tools. Waarom is deze full-stack-benadering noodzakelijk, en wat gebeurt er als organisaties deze risico’s blijven behandelen in isolatie?

Omdat risico niet netjes binnen één product in uw stack zit. AI-native ontwikkeling is inherent een ecosysteemprobleem omdat het op zoveel verschillende plaatsen werkt, met zoveel verschillende tools. De IDE, het model, de agents, de MCP-servers, de externe plugins, de identiteiten en de verbonden gegevensbronnen beïnvloeden allemaal wat wordt gebouwd en hoe. Organisaties standaardiseren niet op één tool omdat hun relatieve sterke punten zo snel veranderen. Als u alleen één punt in die keten beveiligt, mist u nog steeds hoe risico door het systeem beweegt.

Het behandelen van deze risico’s in isolatie leidt tot gefragmenteerde verdediging en gevaarlijke blinde vlekken. U kunt de code-scanner verharden, maar de MCP-server die risicovolle context aan het model voedt, over het hoofd zien. Dat is waarom wij geloven dat de juiste aanpak full-stack-zichtbaarheid en real-time-beveiliging is over het hele AI-ontwikkelings-ecosysteem. Anders zullen organisaties symptomen blijven oplossen terwijl het daadwerkelijke aanvalsoppervlak onder hen blijft uitbreiden.

Prompting komt op als een nieuwe laag van programmeerbaarheid. Hoe moeten organisaties prompting beveiligen en problemen zoals prompt-injectie, gegeksleuteling of manipulatie voorkomen?

Prompting vormt steeds meer de logica en het gedrag. In veel gevallen is het effectief een nieuwe controle-laag voor softwarecreatie. Dat betekent dat het beleid, monitoring en beveiligingshekken nodig heeft, net zoals code- of infrastructuurdefinities zouden hebben. In de praktijk begint dit met het beperken van wat prompts kunnen benaderen en welke downstream-acties ze kunnen uitvoeren. Het betekent ook het definiëren van promptregels die overeenkomen met beveiligings- en kwaliteitsverwachtingen, het voorkomen dat gevoelige gegevens worden blootgesteld via contextvensters en het in de gaten houden van manipulatiepogingen zoals prompt-injectie of indirecte instructie-kaapen. En het omvat ook het waarborgen dat de regels zelf niet worden gebruikt als achterdeuren voor prompt-injectie. Het bredere punt is dat u prompting niet beveiligt door ontwikkelaars en agents te instrueren om “voorzichtig te zijn”. U beveiligt het door controles in te bouwen in de omgeving waar prompting daadwerkelijk gebeurt.

MCP-servers en agent-Skills introduceren dynamische verbindingen tussen systemen. Vanuit een beveiligingsperspectief, vertegenwoordigen ze het belangrijkste nieuwe risicovector in AI-gedreven ontwikkeling?

MCP-servers en agent-Skills vertegenwoordigen een belangrijke nieuwe laag van risico omdat ze definiëren hoe AI-systemen verbonden zijn met en interactie hebben met de werkelijke wereld. Skills definiëren wat een agent gemachtigd is te doen, terwijl MCP de toegang tot context en systemen uitbreidt. Samen vormen ze het daadwerkelijke gedrag van de agent. Als deze lagen niet strikt worden gecontroleerd, verliezen organisaties zicht op wat hun AI-tools kunnen en wat ze daadwerkelijk doen. De verschuiving van codegeneratie naar actie nemen is wat dit zo’n kritisch gebied voor beveiliging maakt, en het wordt nog onvoorspelbaarder wanneer u ze in keten zet.

Een van uw kernthema’s is “het departement van Ja” zijn – beveiliging mogelijk maken zonder ontwikkelaars te vertragen. Hoe balanceert u real-time-beveiliging met ontwikkelsnelheid in omgevingen waar snelheid kritiek is?

Beveiliging creëert wrijving wanneer het laat gebeurt of los staat van hoe ontwikkelaars daadwerkelijk werken. Het wordt veel effectiever wanneer het direct in de workflow is ingebed en gefocust op wat er echt toe doet. Dat is onderdeel van onze denkwijze sinds Backslash begon, en het is nog belangrijker nu in AI-gedreven ontwikkeling.

In de praktijk betekent dit het naar voren brengen van de weinige kwesties die daadwerkelijk risico vertegenwoordigen, niet het overweldigen van ontwikkelaars met alles wat theorieën lijkt. Het betekent het afdwingen van beleid in de IDE en agent-workflow, niet achteraf. En het betekent het creëren van transparante, deterministische beveiligingshekken zodat teams snel kunnen bewegen terwijl ze nog steeds weten welke tools in gebruik zijn, welke machtigingen ze hebben en wanneer er iets abnormaals gebeurt. Het doel is niet om AI-aanname te vertragen, maar om organisaties te helpen het met vertrouwen aan te nemen zonder de controle te verliezen. In werkelijke zin betekent dit dat een ontwikkelaar minder ruimte heeft om fouten te maken in de eerste plaats, maar als ze er een maken, wordt het snel opgevangen en afgehandeld.

We zien steeds meer niet-technische gebruikers die software bouwen met AI-tools. Hoe verandert de opkomst van niet-ontwikkelaar vibe-coders het dreigingslandschap?

Het breidt het dreigingslandschap uit op twee manieren. Ten eerste vergroot het aanzienlijk het aantal mensen dat software-achtige output kan produceren zonder de beveiligingsimplicaties te begrijpen. Ten tweede creëert het een vals gevoel van veiligheid omdat de tools ontwikkeling een conversatie- en laagdrempelige ervaring laten lijken.

Dat betekent dat organisaties meer toepassingen, automatiseringen en integraties zullen zien die zijn gemaakt door mensen die niet zijn opgeleid om vertrouwensgrenzen, invoervalidatie, afhankelijkheidsnetheid, toegangscontrole of gegeksblootstelling te overwegen. Met andere woorden, het aanvalsoppervlak breidt zich uit, niet alleen omdat AI meer code schrijft, maar omdat meer mensen nu workflows en systemen kunnen genereren die zich als software gedragen zonder basis, hygiënische ingenieursdiscipline toe te passen. Dat maakt zichtbaarheid en ingebouwde veiligheidsmaatregelen nog belangrijker, omdat u niet langer kunt aannemen dat beveiligingskennis aanwezig is op het punt van creatie.

Kijkend naar de toekomst, 12 tot 24 maanden, welke soorten aanvallen of kwetsbaarheden verwacht u specifiek vanwege AI-native ontwikkelingsworkflows?

We verwachten dat veel van de gebruikelijke codekwetsbaarheden zullen worden vermeden vanaf het begin door verbeteringen in de LLM’s zelf, of door betere ingebouwde promptregels in de “harnas” die deze tools omgeeft. Als we nu een toename zien in het volume van kwetsbaarheden vanwege de toegenomen snelheid, zal dit zichzelf corrigeren. En wat niet wordt gecorrigeerd, zal worden achtervolgd door AI-geactiveerde SAST en SCA (een deel hiervan zal ook worden geleverd door de AI-platformleveranciers, bijv. Claude Code Security en project Glasswing).

Ik verwacht echter veel slechtere resultaten wanneer het gaat om blootstellingen als gevolg van het gebruik van ongeteste en onbeheerde AI-tools in applicatieontwikkeling – zoals open-source-agents (OpenClaw is een goed voorbeeld), die zeer slechte beveiligingsstandaarden hebben in combinatie met een gebruikersbasis waarvan de kennis van beveiliging ver overtroffen wordt door hun enthousiasme voor vibe-coding.

Als gevolg hiervan denk ik dat we een verschuiving zullen zien naar aanvallen die zich richten op het ontwikkelings-ecosysteem zelf in plaats van alleen productiesystemen. Naarmate AI onderdeel wordt van hoe software wordt gemaakt, zullen aanvallers zich richten op het manipuleren van de tools en verbindingen die dat proces vormen, waardoor software effectief wordt gecompromitteerd voordat het ooit wordt geïmplementeerd.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen bezoek Backslash Security.