Zaid Al Hamani, CEO en oprichter van Boost Security – Interviewreeks

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 technologiebedrijven. 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 mede-oprichter/CEO van IMMUNIO. Eerder bekleedde hij senior leiderschapsfuncties bij Canonical, waar hij product-, engineering- en wereldwijde ondersteuningsinitiatieven leidde, en bij SITA, waar hij grote, mission-critische IT-operaties beheerde. Zijn carrière vertoont een sterk trackrecord van het opbouwen van teams, het optimaliseren van systemen 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 ontwikkelingsnelheid wordt gehandhaafd. Door applicatie- 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 marktgleuf identificeerde u vroeg?

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 applicatie 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
• De 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: infrastructuur als code, containers, API’s, enz.

Het produceren van software snel was gemakkelijker. Het produceren van beveiligde software snel was nog steeds moeilijk.

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

We hebben bedrijven geholpen 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 zijn van plan om dezelfde traject te blijven volgen.

U hebt betoogd dat de softwareontwikkelingslevenscyclus (SDLC) fundamenteel stroomopwaarts is verschoven. Wat was het moment dat u besefte 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 repo was geforkt, een token met productiecloudtoegang ingebed in een runner-config, een legitieme CI-taak die was gehijackt om aanvallerspayloads te deployen. Dit werden “living off the pipeline”-aanvallen genoemd, 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 aanvallers uw cloud geven.

Hoe moeten bedrijven de SDLC opnieuw overwegen in een wereld waarin AI-agenten code continu genereren in plaats van dat ontwikkelaars deze stap voor stap schrijven?

We moeten allemaal stoppen met denken over de SDLC als een reeks 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 codereview, SAST, SCA en deploy, maar we zijn daar nu voorbij.

Beveiliging moet leven waar de agent werkt: 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 verloren om deze 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.

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

Het behandelen van een AI-codingtool als een productiviteitslaag is als het behandelen van een junior-ontwikkelaar met root-toegang als een productiviteitslaag. De label is technisch gezien correct, maar het geeft u geen bruikbaar kader voor het denken over wat er mis kan gaan.

Een coding-agent leest uw bestandssysteem, schraapt omgevingsvariabelen voor context, haalt afhankelijkheden op van openbare registers, opent outgebonden verbindingen met remote 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 inkrimping smelt vertrouwensgrenzen die eerder afzonderlijk waren: de autoriteit van de ontwikkelaar, wat een externe tool kan ophalen, en wat onbetrouwbare code kan uitvoeren. Dat creëert nieuwe kansen voor aanvallers en blinde vlekken die verdedigers niet kunnen zien, laat staan verdedigen.

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

Het grootste risico is inventaris. De meeste beveiligingsteams kunnen u niet vertellen welke AI-agenten op welke laptops draaien, welke MCP-servers en modellen ze mogen benaderen, of welke IDE-extensies momenteel repositoryinhoud schrapen. EDR heeft geen zichtbaarheid in de agentlaag; SIEM kan niet zien wat die agenten lokaal doen. Het is een schaduw-IT-probleem met code-uitvoeringsrechten.

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

Koppel de twee en u hebt het daadwerkelijke aanvalsvlak. Een onbetrouwbare extensie die met ontwikkelaarsrechten draait in een omgeving vol met cloud-sleutels, is het hoogste-leverage-doelwit in het moderne bedrijf. De meeste teams zijn hier nog niet mee begonnen.

U hebt de “context-val” benadrukt, waarin 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 standaardstatus van elke onbeheerde ontwikkelaarsomgeving. Elke coding-agent die we hebben geïnspecteerd, haalt lokale context agressief op. Ze lezen dotfiles, omgevingsvariabelen, recente bestanden, soms hele directorybomen, en verzenden die context naar een remote model. De tools zijn ontworpen om zo te werken; agressief context-ophalen 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 goedgekeurd 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 broerdirectory.

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

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

Hier is er een die 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 verzendt. De agent voert npm install uit zonder te controleren, omdat agenten geen reputatie controleren. De referentie is weg 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 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 zitten op het een passieve leveranciersaanval met nul inspanning.

De praktische verdedigingen zien er anders uit dan wat de meeste teams momenteel hebben. Begin bij inname. Blokkeer getypte 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 “beveiligde prompts” te schrijven, is geen strategie. Als u strategisch bent, betekent dit dat beveiliging de grens stelt, de agent erft het. En begin met het volgen van een AI-Bill of Materials. De meeste teams kunnen u niet vertellen welke agenten, modellen en pakketten welke repositories aanraken. U kunt niet verdedigen wat u niet kunt inventariseren.

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

Als beveiliging bij CI/CD begint, hebt u de hele pre-commit-fase aan een omgeving overgedragen die u niet controleert. De agent heeft al context opgehaald, 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 benaderen, sanitiseren wat de machine verlaat, en blokkeren van kwaadaardige pakketten voordat ze installeren. Van daaruit volgt het beleid het werk in 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: bevestigen dat de upstream-controles werden gehandhaafd.

De pijplijn zelf verdwijnt niet. Zijn rol wordt verificatie: bevestigen dat de upstream-controles werden gehandhaafd.

Als organisaties AI-codingagenten blijven adopteren, wat zijn de meest kritieke veranderingen die ze vandaag moeten maken om ervoor te zorgen dat hun ontwikkelomgevingen de komende jaren beveiligd blijven?

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

Daarbij verbonden: stop met het behandelen van coding-agenten als productiviteitssoftware. Ze zijn non-menselijke gebruikers met shell-toegang, repository-schrijftoegang en outgebonden netwerkverbindingen. Beheer ze zoals u elk ander bevoorrecht identiteit beheert, met een inventaris, goedgekeurde capaciteiten en auditlogs.

De laatste verschuiving is moeilijker cultureel. De meeste huidige “AI-beveiligingstools” presenteren bevindingen en routeren ze naar mensen. Mensen kunnen niet triageren met de snelheid van agenten. Alles wat u adopteert, moet problemen automatisch binnen 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.