Zaid Al Hamani, CEO en Oprichter van Boost Security – Interview Serie

Zaid Al Hamani, CEO en Oprichter van Boost Security, is een cybersecurity- en DevSecOps-leider met meer dan twee decennia ervaring in het opbouwen en schalen van wereldwijde technologieoperaties. Sinds de oprichting van Boost Security in 2020, heeft hij zich gericht op het moderniseren van de manier waarop organisaties softwareontwikkeling beveiligen, met behulp van eerdere rollen, waaronder VP van Application Security bij Trend Micro en Co-Founder/CEO van IMMUNIO. Eerder bekleedde hij senior leiderschapsposities bij Canonical, waar hij product-, engineering- en wereldwijde ondersteuningsinitiatieven leidde, en bij SITA, waar hij grote, mission-critische IT-operaties beheerde. Zijn carrière weerspiegelt een sterk trackrecord van teamopbouw, systeemoptimalisatie en het bevorderen van moderne beveiligingspraktijken.

Boost Security is een cybersecuritybedrijf dat zich richt op het beveiligen van de moderne softwareleveranciersketen via een developer-first DevSecOps-platform. De technologie integreert rechtstreeks in CI/CD-pijplijnen om kwetsbaarheden automatisch te detecteren, prioriteren en verhelpen, waardoor handmatige overhead wordt verminderd en de ontwikkelingsnelheid behouden blijft. Door toepassings- en leveranciersbeveiliging te verenigen in één systeem, biedt het platform volledige zichtbaarheid over code, afhankelijkheden en infrastructuur, waardoor organisaties hun veerkracht in complexe, cloud-native omgevingen kunnen versterken.

U leidde eerder de applicatiebeveiliging bij Trend Micro en was mede-oprichter van IMMUNIO. Wat leidde u ertoe om Boost Security op te richten, en welke kloof in de markt kon u uniek identificeren?

IMMUN.IO was een van de eerste RASP-bedrijven die werd opgericht – en onze ervaring tot dat moment was dat WAF’s als runtime-beveiligingstechnologie onmogelijk waren om te onderhouden en niet erg effectief waren. We zagen een manier waarop WAF’s zouden worden vervangen door een nauwkeurigere, gemakkelijker te onderhouden oplossing – door de toepassing te instrumenteren.

Dat was in 2012, DevOps was nog in de kinderschoenen, de meeste teams waren niet Agile, en Kubernetes was nog niet een ding.

Trend Micro verwierf IMMUN.IO in 2017. Op dat moment waren er veel meer DevOps-praktijken: CI/CD-pijplijnen, Agile-ontwikkelingspraktijken, snellere iteraties en release-cycli, cloud, enz. Softwareontwikkelteams waren beter in het bouwen van software en sneller in het verzenden. Beveiliging was echter nog steeds kapot:

• Scans zijn te langzaam, of de resultaten komen te laat
• Resultaten zijn te complex voor ontwikkelaars om actie te ondernemen
• Er was een algemeen onaanvaardbaar aantal valse positieven
• Veel nieuwe soorten artefacten werden niet gescand: infrastructure as code, containers, API’s enz.

Software maken was gemakkelijker. Veilige software maken was nog steeds moeilijk.

Dat was het oorspronkelijke probleem dat we wilden oplossen. DevSecOps laten werken in de echte wereld; kun je een softwareontwikkelteam gemakkelijk beveiliging toevoegen aan de SDLC, met een snelheid die overeenkomt met de nieuwe velocity-standaarden? Kun je de dekking breed maken – waar één platform alles is wat je nodig hebt? Kun je het zo maken dat ontwikkelaars, niet alleen de technologie aannemen, maar ook de voordelen zien? Kun je het zo maken dat het schaalbaar is, zodat je geen legers van beveiligingsprofessionals nodig hebt om bij te houden met de hoeveelheid code die wordt geschreven…

We hielpen bedrijven om beveiliging in de SDLC te injecteren tijdens de DevOps-periode. Dat was van 1 naar 10 gaan. We zijn nu in de era van agentic coding – waar agenten een enorm aantal code schrijven – maar het is fundamenteel hetzelfde probleem – snelheid en volume van code zijn van 10 naar 100 gegaan; en we streven ernaar om dezelfde traject te blijven volgen.

U hebt betoogd dat de softwareontwikkelingslevenscyclus (SDLC) fundamenteel stroomopwaarts is verschoven. Wat was het moment dat u realiseerde dat traditionele DevSecOps-benaderingen niet langer voldoende waren?

Het was zien hoe aanvallers daadwerkelijk binnenkwamen. We zagen steeds hetzelfde patroon: een blootgestelde GitHub Actions-workflow die niemand had beoordeeld sinds de repository was geforkt, een token met productiecloudtoegang ingebed in een runner-configuratie, een legitieme CI-taak die was gehijackt om aanvallerspayloads te deployen. Deze werden bekend als “living off the pipeline”-aanvallen, omdat de tegenstander uw eigen automatisering tegen u gebruikt, met referenties die uw beveiligingsteam al had goedgekeurd.

De DevSecOps-stack die we in een decennium hadden opgebouwd, had geen antwoord op dat. SAST-scans applicatiebron. SCA-scans applicatie-afhankelijkheden. Beide gaan ervan uit dat de pijplijn die ze uitvoert, betrouwbaar is. Ondertussen is de pijplijn zelf een YAML-bestand met shell-opdrachten, netwerktoegang en gevoelige referenties, en bijna niemand beoordeelt het.

Wanneer dat het pad van de minste weerstand wordt, kunt u perfect schone code verzenden en toch de cloud van de aanvaller overhandigen.

Hoe moeten ondernemingen de SDLC herschikken in een wereld waarin AI-agenten code continu genereren in plaats van dat ontwikkelaars het stap voor stap schrijven?

We moeten allemaal stoppen met denken over de SDLC als een reeks van checkpoints. AI-agenten hebben de tijd tussen “iemand schreef dit” en “dit is in productie” van weken naar minuten teruggebracht. Het oude model ging ervan uit dat er een menselijke cadans was tussen codebeoordeling, SAST, SCA en deploy, maar we zijn daar nu voorbij.

Beveiliging moet leven waar de agent opereert: op de machine van de ontwikkelaar, binnen de promptcontext, in de verbindingen van de agent met MCP-servers en externe modellen. Zodra de code de pijplijn bereikt, hebt u al de kans gemist om het te vormen. De agent heeft al de afhankelijkheid getrokken. Het model heeft al de referentie gezien. Verplaats de controles stroomopwaarts, naar waar het werk daadwerkelijk gebeurt.

Velen organisaties behandelen AI-codingtools nog steeds als eenvoudige productiviteitslagen. Waarom denkt u dat ze een geheel nieuw aanvalsoppervlak vertegenwoordigen in plaats van alleen een uitbreiding van bestaande workflows?

AI-codingtools als productiviteitslaag behandelen is als een juniorontwikkelaar met root-toegang als productiviteitslaag behandelen. De label is technisch correct, maar het geeft u geen bruikbaar kader voor het denken over wat er mis kan gaan.

Een codingagent leest uw bestandssysteem, schraapt omgevingsvariabelen voor context, haalt afhankelijkheden op van openbare registers, opent outgebonden verbindingen met externe modelproviders en MCP-servers, en voert shell-opdrachten uit. Elk van die acties vereiste eerder een mens in de lus. Nu gebeuren ze in milliseconden, met dezelfde privileges als de ontwikkelaar die de agent startte.

Die samensmelting van vertrouwensgrenzen die eerder afzonderlijk waren, creëert nieuwe kansen voor aanvallers en blinde vlekken die verdedigers niet eens kunnen zien, laat staan verdedigen.

Boost kaderen de ontwikkelaarslaptop als het nieuwe controlevlak. Welke risico’s bestaan er op het eindpunt dat beveiligingsteams momenteel negeren?

De grootste is inventaris. De meeste beveiligingsteams kunnen u niet vertellen welke AI-agenten op welke laptops draaien, welke MCP-servers die agenten zijn verbonden met, of welke IDE-extensies repository-inhoud op dit moment scannen. EDR heeft geen zichtbaarheid in de agentlaag; SIEM kan niet zien wat die agenten lokaal doen.

Onder dat zit de referentie-rommel. We bouwden een open-source-tool genaamd Bagel deels om dit concreet te maken. Een typische ontwikkelaarslaptop bevat GitHub-tokens met schrijftoegang tot productierepositories, cloud-referenties die infrastructuur kunnen opstarten, npm- of PyPI-tokens die naar miljoenen gebruikers kunnen publiceren, en AI-service-sleutels die aanvallers doorverkopen. Niets daarvan is gehard zoals een CI-runner is gehard. Dezelfde machine die die referenties bevat, bladert ook het web en installeert willekeurige VS Code-extensies.

Combineer de twee en u hebt het werkelijke aanvalsoppervlak. Een onbetrouwbare extensie die met ontwikkelaarsprivileges in een omgeving vol met cloud-sleutels draait, is het meest rendabele doelwit in het moderne bedrijf. De meeste teams zijn nog niet begonnen met het onderzoeken ervan.

U hebt de “contextval” benadrukt, waarbij AI-agenten lokale bestanden, omgevingsvariabelen en configuraties kunnen benaderen. Hoe wijdverspreid is het risico van gevoelige gegevens die lekken via prompts, en waarom is het zo moeilijk om te detecteren?

Wijdverspreid genoeg dat we het behandelen als de standaardtoestand van elke onbeheerde ontwikkelaarsomgeving. Elke codingagent die we hebben geïnspecteerd, trekt lokale context agressief. Ze lezen dotfiles, omgevingsvariabelen, recente bestanden, soms hele directorybomen, en verzenden die context naar een extern model. De tools zijn ontworpen om zo te werken; agressieve context-ophaling is wat ze nuttig maakt.

Het detectieprobleem begint omdat het verkeer van een lek eruitziet als normaal productgebruik. Het is TLS naar api.openai.com of api.anthropic.com. Het komt van een goedgekeurde bedrijfsapplicatie. Standaard DLP ziet een ontwikkelaar die de AI-tool gebruikt die het bedrijf net een licentie voor heeft gekocht. Het ziet niet dat een van de strings in die prompt een AWS-geheime sleutel is die de agent heeft opgehaald uit een half-vergeten .env-bestand in een zusterdirectory.

U vangt het alleen door prompts te inspecteren voordat ze de laptop verlaten, wat precies is waar bijna geen beveiligingsstack momenteel is gepositioneerd.

U noemt machine-snelheid-leveranciersaanvallen. Kunt u een realistisch scenario doorlopen waarin een AI-agent een kwetsbaarheid introduceert sneller dan traditionele beveiligingstools deze kunnen identificeren?

Hier is een scenario dat we herhaaldelijk hebben gezien. Ontwikkelaar vraagt een agent om een functie toe te voegen die een HTTP-retry-bibliotheek nodig heeft. Agent suggereert een pakketnaam. Het pakket klinkt plausibel, maar bestaat niet echt op npm. Binnen een uur registreert een aanvaller het, vult het met werkende retry-logica plus een kleine post-install-script dat ~/.aws/credentials leest en de inhoud naar een webhook post. De agent voert npm install uit zonder te controleren, omdat agenten geen reputatie controleren. De referentie is verdwenen voordat de ontwikkelaar de code zelfs maar uitvoert.

De aanval zelf is niet technisch gesofisticeerd, maar traditionele leveranciersbeveiliging is gebouwd rondom bekende kwetsbaarheden in bekende pakketten: CVE’s, SBOM’s, licentie-scanning. Dat kader heeft niets te zeggen over een pakket dat niet bestond toen de scan voor het laatst werd uitgevoerd, speciaal werd gemaakt om een AI-hallucinatie te matchen, en wordt ingevoerd voordat enige dreigingsfeed wordt bijgewerkt.

Het venster van publicatie tot compromis wordt nu gemeten in minuten. Alles wat na het feit controleert, controleert te laat.

Zijn gehallucineerde afhankelijkheden al een van de grootste risico’s in AI-gedreven ontwikkeling, en welke praktische stappen kunnen organisaties nemen om zich te verdedigen tegen hen?

Ze zijn al een van de grootste. Aanvallers monitoren actief populaire AI-tools voor hallucinaties en registreren de voorgestelde pakketnamen binnen enkele minuten. Onderzoekers een paar jaar geleden, toen het voor het eerst gebeurde, noemden het slopsquatting en de naam bleef hangen. Zodra een afhankelijkheidsnaam vaak genoeg wordt gehallucineerd, is het zitten op het een passieve leveranciersaanval met bijna nul inspanning.

De praktische verdedigingen zien er anders uit dan wat de meeste teams momenteel hebben. Begin bij het opnemen. Blokkeer typosquatted en onlangs geregistreerde pakketten op het moment dat npm install of pip install wordt uitgevoerd, op de machine van de ontwikkelaar, voordat iets op schijf komt. Postmortem-detectie in CI helpt niet als een post-install-script al een referentie heeft geëxtraheerd. Geef de agent dan guardrails om binnen te opereren. Injecteer uw goedgekeurde-afhankelijkheidslijst rechtstreeks in de context van de agent, zodat het model ziet wat is toegestaan voordat het een suggestie genereert. Vragen aan ontwikkelaars om “veilige prompts” te schrijven, is geen strategie. Als u strategisch bent, betekent dit dat beveiliging de grens stelt, de agent erft het. En start met het volgen van een AI-Bill of Materials. De meeste teams kunnen niet vertellen welke agenten, modellen en pakketten welke repositories aanraken. U kunt niet verdedigen wat u niet kunt inventariseren.

U zei dat beveiliging niet langer bij CI/CD kan beginnen. Wat ziet een moderne beveiligingspijplijn eruit wanneer bescherming eerder in het ontwikkelproces moet beginnen?

Als beveiliging bij CI/CD begint, hebt u de hele pre-commit-fase aan een omgeving overgelaten die u niet controleert. De agent heeft al context opgenomen, uw referentie kan al in iemands logboek staan. U scant een lijk.

Een moderne pijplijn begint op de laptop. Dat betekent inventariseren van de agenten en extensies die daar draaien, valideren welke MCP-servers en modellen ze mogen praten, sanitiseren wat de machine verlaat, en blokkeren van kwaadaardige pakketten voordat ze installeren. Vanaf daar volgt het beleid het werk naar de IDE. We injecteren beveiligingsnormen rechtstreeks in de contextvenster van de agent, zodat gegenereerde code binnen de guardrails blijft vanaf het eerste token. De pijplijn zelf verdwijnt niet. Zijn rol wordt verificatie: bevestiging dat de upstream-controles hebben standgehouden.

De pijplijn zelf verdwijnt niet. Zijn rol wordt verificatie: bevestiging dat de upstream-controles hebben standgehouden.

Terwijl organisaties AI-codingagenten blijven adopteren, welke zijn de meest kritische veranderingen die ze vandaag moeten maken om ervoor te zorgen dat hun ontwikkelomgevingen de komende jaren blijven beveiligen?

De grootste fout is het alleen beveiligen van wat wordt ingecheckt. Het interessante risico leeft nu in de acht uur voordat een commit gebeurt. Onzichtbare drama kan zich op de laptop, in de prompt of in de pakketinstallatie ontvouwen. Als uw tools bij de PR beginnen, beschermt u de verkeerde helft van de workflow.

Daarbij verwant: stop met het behandelen van codingagenten als productiviteitssoftware. Ze zijn niet-menselijke gebruikers met shell-toegang, repository-schrijftoegang en outgebonden netwerkverbindingen. Reguleer ze zoals u elke andere bevoorrechte identiteit reguleert, met een inventaris, goedgekeurde capaciteiten en auditlogs.

De laatste verschuiving is moeilijker cultureel. De meeste huidige “AI-beveiligingstools” brengen bevindingen naar boven en routeren ze naar mensen. Mensen kunnen niet triageren met de snelheid die agenten genereren. Wat u ook adopteert, moet problemen automatisch in de workflow oplossen, met traceerbare redenering, of het wordt een ander dashboard dat niemand leest.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Boost Security bezoeken.