Zaid Al Hamani, VD och grundare av Boost Security – Intervjuer

Zaid Al Hamani, VD och grundare av Boost Security, är en ledande expert inom cybersäkerhet och DevSecOps med över två decenniers erfarenhet av att bygga och skala globala tekniska operationer. Sedan han grundade Boost Security 2020 har han fokuserat på att modernisera hur organisationer säkrar programvaruutveckling, med erfarenhet från tidigare roller som VP för Application Security på Trend Micro och medgrundare/VD för IMMUNIO. Tidigare har han haft ledande befattningar på Canonical, där han ledde produkt-, teknik- och globala supportinitiativ, och på SITA, där han hanterade stora, kritiska IT-operationer. Hans karriär visar en stark historia av att bygga team, optimera system och främja moderna säkerhetspraktiker.

Boost Security är ett cybersäkerhetsföretag som fokuserar på att säkra den moderna programvaruleverantörskedjan genom en utvecklarcentrerad DevSecOps-plattform. Dess teknik integreras direkt i CI/CD-pipelines för att automatiskt upptäcka, prioritera och åtgärda sårbarheter, minska manuell belastning samtidigt som utvecklingshastigheten upprätthålls. Genom att förena programsäkerhet och leverantörskedjesäkerhet i ett system ger plattformen fullständig synlighet över kod, beroenden och infrastruktur, vilket hjälper organisationer att stärka motståndskraften i komplexa, molnbaserade miljöer.

Du ledde tidigare applikationssäkerhet på Trend Micro och var med och grundade IMMUNIO. Vad ledde dig till att grunda Boost Security, och vilken lucka på marknaden var du unikt positionerad att identifiera tidigt?

IMMUN.IO var ett av de första RASP-företagen som grundades – och vår erfarenhet fram till den punkten var att WAF som en runtime-säkerhetsteknik var omöjlig att underhålla och inte särskilt effektiv. Vi föreställde oss en situation där WAF skulle ersättas med en mer exakt, enklare att underhålla lösning – genom att instrumentera applikationen.

Det var 2012, DevOps var fortfarande i sin linda, och de flesta team var inte agila, och Kubernetes var inte en sak ännu.

Trend Micro förvärvade IMMUN.IO 2017. Vid den tidpunkten fanns det många fler DevOps-praktiker: CI/CD-pipelines, agila utvecklingspraktiker, snabbare iterationer och släppcykler, moln etc. Programvaruteam var bättre på att bygga programvara och skicka den snabbare. Säkerheten var fortfarande trasig dock:

• Sökningar är för långsamma, eller resultaten anländer för sent
• Resultaten är för komplexa för utvecklare att agera på
• Det fanns en allmänt oacceptabel falsk positiv frekvens
• Många nya typer av artefakter skannades inte: infrastruktur som kod, containrar, API:er till exempel

Att producera programvara snabbt var lättare. Att producera säker programvara snabbt var fortfarande svårt.

Det var det ursprungliga problemet vi satte oss att lösa. Gör DevSecOps till verklighet i den riktiga världen; kan du få ett programvaruteam att enkelt lägga till säkerhet i SDLC, i en hastighet som matchar de nya standarderna för hastighet? Kan du göra täckningen bred – där en plattform är allt du behöver? Kan du göra det så att utvecklare, inte bara antar tekniken, utan också omfamnar den och ser fördelarna? Kan du göra det så att det skalar så att du inte behöver arméer av säkerhetsexperter för att hålla jämna steg med mängden kod som skrivs…

Vi hjälpte företag att injicera säkerhet i SDLC under DevOps-eran. Det var att gå från 1 till 10. Vi är nu i eran av agenter som kodar – där agenter skriver en enorm mängd kod – men det är i grunden samma problem – hastighet och volym av kod gick från 10 till 100; och vi syftar till att fortsätta samma bana.

Du har hävdat att programvaruutvecklingslivscykeln (SDLC) har förändrats grundläggande uppströms. Vilket var ögonblicket då du insåg att traditionella DevSecOps-ansatser inte längre var tillräckliga?

Det var att se hur angripare faktiskt kom in. Vi såg hela tiden samma mönster: en utsatt GitHub Actions-arbetsflöde som ingen hade granskat sedan repo:n forkades, en token med produktionsmolntillgång inbäddad i en runner-konfiguration, en legitim CI-jobb kapad för att distribuera angriparns nyttolast. Dessa blev kända som “leva av pipelinen”-attacker, eftersom motståndaren använder din egen automatisering mot dig, med behörigheter som ditt säkerhetsteam redan godkänt.

DevSecOps-stapeln vi hade byggt upp under ett decennium hade inget svar på det. SAST skannar applikationskällkod. SCA skannar applikationsberoenden. Båda antar att pipelinen som kör dem är pålitlig. Samtidigt är pipelinen i sig en YAML-fil med shell-kommandon, nätverksåtkomst och känsliga behörigheter, och nästan ingen granskar den.

När det blir den lägsta motståndsvägen kan du skicka perfekt ren kod och fortfarande ge angriparna din molntjänst.

Hur bör företag omdefiniera SDLC i en värld där AI-agenter genererar kod kontinuerligt snarare än att utvecklare skriver den steg för steg?

Vi måste alla sluta tänka på SDLC som en sekvens av kontrollpunkter. AI-agenter har kollapsat tiden mellan “någon skrev detta” och “detta är i produktion” från veckor till minuter. Den gamla modellen antog en mänsklig takt mellan kodgranskning, SAST, SCA och distribution, men vi är bortom det nu.

Säkerheten måste finnas där agenten opererar: på utvecklarens maskin, inuti prompt-sammanhanget, i agentens anslutningar till MCP-servrar och externa modeller. När koden når pipelinen har du redan förlorat chansen att forma den. Agenten har redan dragit beroendet. Modellen har redan sett behörigheten. Flytta kontrollerna uppströms, till där arbetet faktiskt sker.

Många organisationer behandlar fortfarande AI-kodningsverktyg som enkla produktivitetslager. Varför tror du att de representerar en helt ny angreppsyta snarare än bara en utvidgning av befintliga arbetsflöden?

Att behandla ett AI-kodningsverktyg som ett produktivitetslager är som att behandla en juniorutvecklare med root-åtkomst som ett produktivitetslager. Etiketten är tekniskt korrekt, men den ger dig ingen användbar ram för att tänka på vad som kan gå fel.

Ett kodningsagent läser din filsystem, skrapar miljövariabler för sammanhang, hämtar beroenden från offentliga register, öppnar utgående anslutningar till fjärrmodellleverantörer och MCP-servrar, och kör shell-kommandon. Var och en av dessa åtgärder krävde tidigare en mänsklig faktor. Nu sker de på millisekunder, med samma behörigheter som utvecklaren som startade agenten.

Den kollapsen smälter samman förtroendegränser som tidigare var separata: utvecklarens auktoritet, vad en extern verktyg kan hämta, och vad obehörig kod kan köra. Det skapar nya möjligheter för angripare och blinda fläckar som försvarare inte ens kan se, än mindre försvara.

Boost ramverket utvecklarens laptop som den nya kontrollplanet. Vilka risker finns det på slutpunkten som säkerhetsteam för närvarande försummar?

Den största risken är inventering. De flesta säkerhetsteam kan inte säga vilka AI-agenter som körs på vilka laptops, vilka MCP-servrar dessa agenter är anslutna till, eller vilka IDE-tillägg som skrapar repository-innehåll just nu. EDR har ingen insyn i agentlagret; SIEM kan inte heller se vad dessa agenter gör lokalt.

Under det ligger behörighetsröran. Vi byggde ett öppen källkodsverktyg som heter Bagel delvis för att göra detta konkret. En typisk utvecklarens laptop innehåller GitHub-token med skrivrättigheter till produktionsrepo, molnbehörigheter som kan starta infrastruktur, npm- eller PyPI-token som kan publicera till miljontals användare, och AI-tjänstnycklar som angripare säljer. Inget av detta är härdade på samma sätt som en CI-körare är härdad. Samma maskin som innehåller dessa behörigheter surfar också på webben och installerar slumpmässiga VS Code-tillägg.

Para ihop de två och du har den faktiska angreppsytan. Ett obehörigt tillägg som körs med utvecklarbehörigheter i en miljö full av molnnycklar är det största målet i det moderna företaget. De flesta team har inte ens börjat titta på det.

Du har betonat “kontextfällan”, där AI-agenter kan komma åt lokala filer, miljövariabler och konfigurationer. Hur utbredd är risken för att känsliga data läcker genom prompt, och varför är det så svårt att upptäcka?

Tillräckligt utbredd för att vi behandlar det som standardtillståndet för alla ohanterade utvecklarmiljöer. Varje kodningsagent vi har inspekterat drar lokalt sammanhang aggressivt. De läser dotfiles, miljövariabler, nyligen använda filer, ibland hela katalogträd, och skickar det sammanhanget till en fjärrmodell. Verktygen är utformade för att fungera på det här sättet; aggressivt sammanhangsdragning är vad som gör dem användbara.

Detektionsproblemet börjar eftersom trafiken från en läcka ser identisk ut med normalt produktanvändning. Det är TLS till api.openai.com eller api.anthropic.com. Det kommer från en godkänd affärsapplikation. Standard DLP ser en utvecklare som använder AI-verktyget som företaget just köpte en licens för. Det ser inte att en av strängarna i den prompten är en AWS-hemlig nyckel som agenten drog från en halvt bortglömd .env-fil i en syskonkatalog.

Du fångar det bara genom att inspektera prompt innan de lämnar laptoppen, vilket är exakt där nästan ingen säkerhetsstack för närvarande är positionerad.

Du nämnde maskinhastighetsförsörjningskedjeattacker. Kan du gå igenom ett realistiskt scenario där en AI-agent introducerar en sårbarhet snabbare än traditionella säkerhetsverktyg kan identifiera den?

Här är ett som vi har sett variationer av upprepade gånger. Utvecklare ber en agent att lägga till en funktion som behöver en HTTP-återuppringningsbibliotek. Agenten föreslår ett paketnamn. Paketet är ett plausibelt ljudande namn men existerar inte på npm. Inom en timme registrerar en angripare det, fyller det med fungerande återuppringningslogik plus ett litet post-installations-skript som läser ~/.aws/credentials och postar innehållet till en webhook. Agenten kör npm install utan att kontrollera, eftersom agenter inte kontrollerar rykte. Behörigheten är borta innan utvecklaren ens kör koden.

Attacken i sig är inte tekniskt sofistikerad, men traditionell försörjningskedjesäkerhet är byggd kring kända sårbarheter i kända paket: CVE:er, SBOM:er, licensskanning. Den ramen har ingenting att säga om ett paket som inte existerade när skanningen senast kördes, skapades specifikt för att matcha en AI-hallucination, och inges innan någon hotfeed uppdateras.

Fönstret från publicering till kompromiss mäts nu i minuter. Allt som kontrollerar efter faktum är för sent.

Blir hallucinerade beroenden en av de största riskerna i AI-driven utveckling, och vilka praktiska steg kan organisationer ta för att försvara sig mot dem?

De är redan en av de största. Angripare övervakar aktivt populära AI-verktyg för hallucinationer och registrerar de föreslagna paketnamnen inom minuter. Forskare för ett par år sedan, när det först började hända, kallade det slopsquatting och namnet fastnade. När ett beroendenamn hallucineras tillräckligt ofta, sitta på det är en passiv försörjningskedjeattack med nästan noll ansträngning.

De praktiska försvarsverken ser annorlunda ut än vad de flesta team för närvarande har. Börja med inköp. Blockera förväxlingsbara och nyligen registrerade paket i samma ögonblick npm install eller pip install körs, på utvecklarens maskin, innan något träffar skivan. Postmortem-detektion i CI hjälper inte när ett post-installations-skript redan har exfiltrerat en behörighet. Ge sedan agenten räcken att operera inom. Injicera din godkända beroendelista direkt in i agentens sammanhang, så modellen ser vad som är tillåtet innan den genererar ett förslag. Att be utvecklare att skriva “säkra prompt” är inte en strategi. Om du blir strategisk, innebär det att säkerhet sätter gränsen, agenten ärver den. Och börja spåra en AI-materielista. De flesta team kan inte säga vilka agenter, modeller och paket som berör vilka repository.

Du har sagt att säkerhet inte längre kan börja vid CI/CD. Vad ser en modern säkerhetspipeline ut som när skydd behöver börja tidigare i utvecklingsprocessen?

Om säkerhet börjar vid CI/CD, har du gett upp hela pre-commit-fasen till en miljö som du inte kontrollerar. Agenten har redan dragit sammanhang, din behörighet kan redan vara i någon annans loggar. Du skannar en kadaver.

En modern pipeline börjar på laptoppen. Det innebär att inventera agenter och tillägg som körs där, validera vilka MCP-servrar och modeller de är tillåtna att prata med, sanera vad som lämnar maskinen och blockera skadliga paket innan de installeras. Därifrån följer principen arbetet in i IDE. Vi injicerar säkerhetsstandarder direkt in i agentens sammanhangsfönster så att genererad kod stannar inom räckena från första token. Pipelinen körs fortfarande, gör slutlig verifiering av kontroller som redan påtvingades uppströms.

Pipelinen försvinner inte. Dess roll blir verifiering: att bekräfta att de uppströms kontrollerna hölls.

När organisationer fortsätter att anta AI-kodningsagenter, vad är de viktigaste förändringarna de måste göra idag för att säkerställa att deras utvecklingsmiljöer förblir säkra under de kommande åren?

Det största misstaget är att säkra bara det som checkas in. Den intressanta risken lever nu i de åtta timmarna innan en check-in sker. Osett drama kan utspela sig på laptoppen, i prompten eller i paketinstallationen. Om dina verktyg börjar vid PR är du skyddar fel halva arbetsflödet.

Nära relaterat: sluta behandla kodningsagenter som produktivitetsprogram. De är icke-mänskliga användare med shell-åtkomst, repository-skrivbehörigheter och utgående nätverksanslutningar. Styra dem på samma sätt som du styra varje annan privilegerad identitet, med en inventering, godkända funktioner och granskningsloggar.

Den sista skiftet är svårare kulturellt. De flesta nuvarande “AI-säkerhetsverktyg” presenterar resultat och skickar dem till människor. Människor kan inte triage i den hastighet som agenter genererar. Vad du än antar måste lösa problem automatiskt inom arbetsflödet, med spårbar logik, eller så blir det en till instrumentpanel som ingen läser.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Boost Security.