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 diepe 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, waaronder alles van IDE’s en AI-agents tot gegenereerde code en prompting-workflows. Voordat hij deze functie bekleedde, bekleedde 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 enterprise-klanten, terwijl hij ook bijdroeg aan de groei van de ontwikkelaarsgemeenschap. Zijn carrière begon in technische en leiderschapsrollen in zowel start-up-omgevingen als Israël’s defensietechnologie-eenheden, waardoor hij een sterke basis had in zowel techniek als grootschalige systemen.

Backslash Security is een opkomend cybersecurity-platform dat speciaal is ontwikkeld voor de tijdperk van AI-gedreven software-ontwikkeling. Het bedrijf richt zich op het beveiligen van de hele AI-native ontwikkelingsstack, waaronder 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 bekleed 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 softwarecreatie fundamenteel zouden veranderen, en dat beveiliging opnieuw zou moeten worden opgebouwd om dit te ondersteunen?

Ik had al een grote verschuiving meegemaakt toen software naar cloud-native architectureën verhuisde. Bij SAP en later bij Aqua zagen we eerstehands 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 om code sneller te schrijven, maar omdat het de hele omgeving rond softwarecreatie heeft veranderd.

Code beveiligen 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 gaan 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?

Het 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 zijn laptop kan worden overgenomen en gebruikt als brughoofd voor een bredere aanval. Het is een eindpunt-pijnpunt dat zich voordoet als een AI-coding-probleem. In tegenstelling tot codekwetsbaarheden, kan dit niet alleen uw toepassingen in gevaar brengen – het kan uw hele organisatie in gevaar brengen. Als u alleen naar de code kijkt, mist u het grootste deel van het beeld.

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

Beveiliging moet van periodieke inspectie naar continue toezicht gaan. Het concept van vertrouwen is helemaal 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 dieper governance, guardrails 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. Bovendien mogen we de rol van AI en AI-modellen in het omgaan met kwetsbaarheden niet negeren. Als AI-modellen een jaar geleden veel kwetsbaarheden opleverden, zijn de dingen nu aanzienlijk verbeterd, en worden andere modellen nu gebruikt om zero-days te vinden die eerder nooit waren gevonden. We gaan dus naar betere uitgangspunten – maar wie let op de winkel terwijl we dat doen? De aanvallers zoeken elders.

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 adequate governance-laag?

Het grootste gat is zichtbaarheid. In veel organisaties verspreiden deze tools zich snel en zonder formeel onderzoek. 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 vergelijkbaar is met schaduw-IT in principe, 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 binnen de IDE beweegt. Zonder governance op tool- en workflow-niveau lopen teams het risico over-geautoriseerde tools te hebben die niet voldoen aan de standaarden van de onderneming. Deze tools zijn op zichzelf niet slecht, maar ze aannemen 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 citizen-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 enorme blinde vlek, zelfs vandaag de dag.

Backslash richt zich op het beveiligen van de hele AI-ontwikkelingsomgeving in plaats van individuele tools. Waarom is deze full-stack-aanpak 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 hebben allemaal invloed op wat wordt gebouwd en hoe. Organisaties standardiseren 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 zich door het systeem verplaatst.

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 de hele AI-ontwikkelingsomgeving. Anders zullen organisaties symptomen blijven oplossen terwijl het werkelijke aanvalsoppervlak onder hen blijft uitbreiden.

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

Prompting vormt steeds meer de logica en het gedrag. In veel gevallen zijn ze effectief een nieuwe controle-laag voor softwarecreatie. Dat betekent dat ze beleid, monitoring en guardrails nodig hebben, net als code- of infrastructuurdefinities zouden. In de praktijk begint dit met het beperken van wat prompts kunnen benaderen en welke downstream-acties ze kunnen triggeren. Het betekent ook het definiëren van promptregels die overeenkomen met beveiligings- en kwaliteitsverwachtingen, het voorkomen van gevoelige gegevens die via contextvensters worden blootgesteld en het in de gaten houden van manipulatiepogingen zoals prompt-injectie of indirecte instructie-hijacking. En het omvat ook het ervoor zorgen 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 controle in de omgeving te embedden waar prompting daadwerkelijk gebeurt.

MCP-servers en agent-Skills introduceren dynamische verbindingen tussen systemen. Vanuit een beveiligingsperspectief, vertegenwoordigen deze de meest significante 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 interageren met de echte wereld. Skills definiëren wat een agent gemachtigd is te doen, terwijl MCP de toegang tot context en systemen uitbreidt. Samen vormen ze het werkelijke 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 aan elkaar koppelt.

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 losgekoppeld is van hoe ontwikkelaars daadwerkelijk werken. Het wordt veel effectiever wanneer het direct in de workflow is ingebed en gericht is 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 dat de weinige kwesties die werkelijk risico vertegenwoordigen, naar voren worden gebracht, en niet dat ontwikkelaars worden overspoeld met alles wat theoretisch verdacht lijkt. Het betekent beleid afdwingen in de IDE en agent-workflow, en niet pas daarna. En het betekent het creëren van transparante, deterministische guardrails, 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 AI 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, maar als ze er een maakt, 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-achtig en laagdrempelig gevoel geven.

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 gegevensblootstelling 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 waarborgen 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 te zien ontstaan, specifiek als gevolg van 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 “harness” 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 opgejaagd door AI-geactiveerde SAST en SCA (een deel hiervan zal ook worden geleverd door de AI-platformleveranciers, zoals Claude Code Security en project Glasswing).

Hoewel ik verwacht dat de uitkomsten veel erger zullen zijn wanneer het gaat om blootstellingen als gevolg van het gebruik van ongecontroleerde en onbeheerde AI-tools in applicatie-ontwikkeling – zoals open-source agents (OpenClaw is een goed voorbeeld), die zeer slechte beveiligingsstandaarden hebben, gecombineerd 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 de ontwikkelingsomgeving zelf in plaats van alleen productiesystemen. Aangezien AI onderdeel wordt van hoe software wordt gemaakt, zullen aanvallers zich richten op het manipuleren van de tools en verbindingen die dit proces vormen, en effectief software compromitteren voordat deze ooit wordt geïmplementeerd.

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