Zaid Al Hamani, CEO og grundlægger af Boost Security – Interview-serie

Zaid Al Hamani, CEO og grundlægger af Boost Security, er en cybersecurity- og DevSecOps-leder med mere end to årtiers erfaring i opbygning og skaleringsglobal teknologioperationer. Siden grundlæggelsen af Boost Security i 2020 har han fokuseret på at modernisere, hvordan organisationer sikrer softwareudvikling, med udgangspunkt i tidligere roller, herunder VP of Application Security i Trend Micro og Co-Founder/CEO of IMMUNIO. Tidligere havde han ledende stillinger i Canonical, hvor han ledte produkt-, ingeniør- og globale supportinitiativer, og i SITA, hvor han ledede store, mission-kritiske IT-operationer. Hans karriere afspejler en stærk track record for opbygning af hold, optimering af systemer og fremme af moderne sikkerhedspraksis.

Boost Security er et cybersecurity-selskab, der fokuserer på at sikre den moderne softwareforsyningskæde gennem en developer-foresky DevSecOps-platform. Dens teknologi integrerer direkte i CI/CD-pipelines for at automatisk detektere, prioritere og afhjælpe sårbarheder, reducere manuel overbelastning samtidig med at udviklingshastigheden opretholdes. Ved at samle applicationsikkerhed og forsyningskædesikkerhed i ét system giver platformen fuld oversigt over kode, afhængigheder og infrastruktur, hvilket hjælper organisationer med at styrke resilience i komplekse, cloud-native miljøer.

Du har tidligere ledet application security i Trend Micro og co-grundlagt IMMUNIO. Hvad førte til, at du grundlagde Boost Security, og hvilken åbning på markedet var du unikt positioneret til at identificere tidligt?

IMMUN.IO var et af de første RASP-selskaber, der blev grundlagt – og vores erfaring indtil da var, at WAF’er som en runtime-sikkerhedsteknologi var umulige at vedligeholde og ikke meget effektive. Vi forestillede os en måde, hvor WAF’er ville blive erstattet af en mere præcis, lettere at vedligeholde løsning – ved at instrumentere applikationen.

Det var i 2012, DevOps var stadig tidligt, og de fleste hold var ikke Agile, og Kubernetes var ikke noget endnu.

Trend Micro erhvervede IMMUN.IO i 2017. På det tidspunkt var der mange flere DevOps-praksisser: CI/CD-pipelines, Agile-udviklingspraksisser, hurtigere iterationer og udgivelsescykler, cloud osv. Softwareudviklingsteams var bedre til at bygge software og skibe hurtigere. Sikkerheden var stadig brudt, selvom…

• Scans er for langsomme eller resultater ankommer for sent
• Resultater er for komplekse for udviklere at agere på
• Der er en generelt uacceptabel falsk positiv rate
• Mange nye typer af artefakter blev ikke scannet: infrastructure as code, containere, API’er for eksempel

At producere software hurtigt var lettere. At producere sikker software hurtigt var stadig svært.

Det var det oprindelige problem, vi satte os for at løse. Gør DevSecOps til at fungere i den virkelige verden; kan du få et softwareudviklingsteam til let at tilføje sikkerhed til SDLC’en, i en hastighed der matcher de nye standarder for hastighed? Kan du gøre dækningen bred – hvor én platform er alt, du behøver? Kan du gøre det sådan, at udviklere ikke kun adopterer teknologien, men også omfavner den og ser fordelene? Kan du gøre det sådan, at det kan skaleres, så du ikke behøver hære af sikkerhedsprofessionelle for at følge med mængden af kode, der skrives…

Vi hjalp virksomheder med at injicere sikkerhed i SDLC’en under DevOps-æraen. Det var gået fra 1 til 10. Vi er nu i æraen for agentic coding – hvor agenter skriver en enorm mængde kode – men det er grundlæggende det samme problem – hastighed og mængde af kode er gået fra 10 til 100; og vi sigter på at fortsætte den samme trajektorie.

Du har argumenteret for, at softwareudviklingslivscyklusen (SDLC) fundamentalt har ændret sig upstream. Hvad var det øjeblik, du indså, at traditionelle DevSecOps-tilgange ikke længere var tilstrækkelige?

Det var at se, hvordan angribere faktisk fik adgang. Vi så hele tiden den samme mønster: en eksponeret GitHub Actions-workflow, som ingen havde gennemgået, siden repo’en blev forket, en token med produktionsskyadgang indlejret i en runner-konfiguration, en legitim CI-job hijacket til at deployere angriberpayloader. Disse blev kendt som “living off the pipeline”-angreb, fordi modstanderen bruger din egen automation imod dig, med de legitimationsoplysninger, dit sikkerhedsteam allerede havde godkendt.

DevSecOps-stakken, vi havde bygget op over en årrække, havde ingen svar på det. SAST-scans application source. SCA-scans application-afhængigheder. Begge antager, at pipelinen, der kører dem, er troværdig. Imens er pipelinen selv en YAML-fil med shell-kommandoer, netværksadgang og følsomme legitimationsoplysninger, og næsten ingen gennemgår den.

Når det bliver den letteste vej, kan du skibe ren kode og alligevel give angriberne din cloud.

Hvordan skal virksomheder omstrukturere SDLC’en i en verden, hvor AI-agenter genererer kode kontinuerligt i stedet for, at udviklere skriver den skridt for skridt?

Vi skal alle stoppe med at tænke på SDLC’en som en række checkpoints. AI-agenter har reduceret tiden mellem “nogen skrev dette” og “dette er i produktion” fra uger til minutter. Den gamle model antog en menneskelig kadence mellem kodereview, SAST, SCA og deploy, men vi er langt udover det nu.

Sikkerheden skal være, hvor agenten opererer: på udviklerens maskine, inden for prompt-konteksten, i agentens forbindelser til MCP-servere og eksterne modeller. Inden koden når pipelinen, har du allerede mistet chancen for at forme den. Agenten har allerede trukket afhængigheden. Modellen har allerede set legitimationsoplysningerne. Flyt kontrollerne upstream, til hvor arbejdet faktisk sker.

Mange organisationer behandler stadig AI-kodningsværktøjer som simple produktivitetslag. Hvorfor mener du, at de repræsenterer en helt ny angrebsflade i stedet for bare en udvidelse af eksisterende arbejdsgange?

At behandle et AI-kodningsværktøj som et produktivitetslag er som at behandle en junior-udvikler med root-adgang som et produktivitetslag. Mærkatet er teknisk set korrekt, men det giver dig ingen nyttig ramme for at tænke over, hvad der kan gå galt.

Et kodningsagent læser din filsystem, scraper miljøvariabler for kontekst, henter afhængigheder fra offentlige registre, åbner udgående forbindelser til fjernmodeller og MCP-servere og udfører shell-kommandoer. Hver af disse handlinger krævede tidligere en menneskelig indgriben. Nu sker de på få millisekunder, med de samme privilegier som udvikleren, der startede agenten.

Denne sammenlægning fusionerer tillidsgrænser, der tidligere var adskilt: udviklerens autoritet, hvad en ekstern værktøj kan hente, og hvad uautoriseret kode kan udføre. Dette skaber nye muligheder for angribere og blinde pletter, som forsvarere ikke kan se, endsige forsvare.

Boost fremhæver udviklerlaptoppen som den nye kontrolplane. Hvilke risici findes der på endpointet, som sikkerhedsteams i øjeblikket overser?

Den største risiko er inventory. De fleste sikkerhedsteams kan ikke fortælle dig, hvilke AI-agenter, der kører på hvilke laptops, hvilke MCP-servere disse agenter er forbundet til, eller hvilke IDE-udvidelser, der i øjeblikket scraper repository-indhold. EDR har ingen indsigt i agent-laget; SIEM kan ikke se, hvad disse agenter gør lokalt.

Under dette ligger rod- og legitimationsproblemet. Vi byggede et open-source-værktøj kaldet Bagel delvist for at gøre dette konkrekt. En typisk udviklerlaptop indeholder GitHub-tokens med skriveadgang til produktionsrepo’er, cloud-legitimationsoplysninger, der kan spinde op infrastruktur, npm- eller PyPI-tokens, der kan publicere til millioner af brugere, og AI-service-nøgler, som angribere genbruger. Ingen af disse er hårdet, som en CI-runner er hårdet. Den samme maskine, der indeholder disse legitimationsoplysninger, surfer også på internettet og installerer tilfældige VS Code-udvidelser.

Par disse to, og du har den faktiske angrebsflade. En upålidelig udvidelse, der kører med udvikler-privilegier i en miljø fuld af cloud-nøgler, er det højeste-momentum-mål i den moderne virksomhed. De fleste teams har endnu ikke begyndt at se på det.

Du har fremhævet “kontekst-fælden”, hvor AI-agenter kan få adgang til lokale filer, miljøvariabler og konfigurationer. Hvor udbredt er risikoen for, at følsomme data læker gennem prompts, og hvorfor er det så svært at opdage?

Udbredt nok til, at vi behandler det som standardtilstanden for enhver uredigeret udviklermiljø. Hver eneste kodningsagent, vi har inspicereet, trækker lokalt kontekst aggressivt. De læser dotfiler, miljøvariabler, nylige filer, undertiden hele directory-træer og sender denne kontekst til en fjernmodel. Værktøjerne er designede til at fungere på denne måde; aggressiv kontekst-indsamling er, hvad der gør dem nyttige.

Detektionsproblemet starter, fordi trafikken fra en lækkage ser identisk ud som normalt produktbrug. Det er TLS til api.openai.com eller api.anthropic.com. Det kommer fra en godkendt forretningsapplikation. Standard DLP ser en udvikler, der bruger AI-værktøjet, som virksomheden lige har købt en licens til. Det ser ikke, at en af strengene i denne prompt er en AWS-hemmelig nøgle, som agenten har hentet fra en halvt-forgotten .env-fil i en søsterdirectory.

Du fanger det kun ved at inspicere prompts, før de forlader laptoppen, hvilket er præcis det sted, hvor næsten ingen sikkerhedsstak er positioneret i øjeblikket.

Du nævner maskin-hastighedsforsyningskædeangreb. Kan du gå igennem et realistisk scenario, hvor en AI-agent introducerer en sårbarhed hurtigere, end traditionelle sikkerhedsværktøjer kan identificere det?

Her er et, vi har set variationer af gentagne gange. Udvikler beder en agent om at tilføje en funktion, der kræver en HTTP-genstartsbibliotek. Agenten foreslår et pakkenavn. Pakken er plausibelt-lydende, men eksisterer ikke på npm. Inden for en time registrerer en angriber det, udfylder det med fungerende genstartelogik plus en lille post-install-script, der læser ~/.aws/credentials og poster indholdet til en webhook. Agenten kører npm install uden at kontrollere, fordi agenter ikke kontrollerer rygte. Legitimationsoplysningen er væk, før udvikleren overhovedet kører koden.

Angrebet i sig selv er ikke teknisk sofistikeret, men traditionel forsyningskædesikkerhed er bygget op omkring kendte sårbarheder i kendte pakker: CVE’er, SBOM’er, licensscanning. Denne ramme har intet at sige om en pakke, der ikke eksisterede, da scanningen sidst blev kørt, blev oprettet specifikt for at matche en AI-hallucination og indtages, før nogen trusselsfeed opdateres.

Vinduet fra publicering til kompromis er nu målt i minutter. Alt, der kontrollerer efterfølgende, kontrollerer for sent.

Bliver hallucinerede afhængigheder en af de største risici i AI-dreven udvikling, og hvad praktiske skridt kan organisationer tage for at forsvare sig imod dem?

De er allerede en af de største. Angribere overvåger aktivt populære AI-værktøjer efter hallucinationer og registrerer de foreslåede pakkenavne inden for minutter. Forskere for et par år siden, da det først begyndte at ske, kaldte det slopsquatting, og navnet har holdt. Når et afhængighedsnavn hallucineres tilstrækkeligt ofte, er det at sidde på det en passiv forsyningskædeangreb med næsten nul indsats.

De praktiske forsvar ser anderledes ud end det, de fleste hold har i øjeblikket. Start med indtagelse. Bloker typosquat og nyligt registrerede pakker i øjeblikket npm install eller pip install kører, på udviklerens maskine, før noget rammer disken. Postmortem-detektion i CI hjælper ikke, når et post-install-script allerede har eksfiltreret en legitimationsoplysning. Så give agenten guardrails til at operere inden for. Indsæt din godkendte-afhængighedsliste direkte i agentens kontekst, så modellen ser, hvad der er tilladt, før den genererer en forespørgsel. At bede udviklere om at skrive “sikre prompts” er ikke en strategi. Hvis du er strategisk, betyder det, at sikkerheden sætter grænsen, og agenten arver den. Og start med at spore en AI-Bill of Materials. De fleste hold kan ikke fortælle dig, hvilke agenter, modeller og pakker, der berører hvilke repository’er. Du kan ikke forsvare, hvad du ikke kan inventere.

Du har sagt, at sikkerheden ikke længere kan begynde ved CI/CD. Hvad ser en moderne sikkerhedspipeline ud til, når beskyttelse skal starte tidligere i udviklingsprocessen?

Hvis sikkerheden starter ved CI/CD, har du overgivet hele pre-commit-fasen til en miljø, du ikke kontrollerer. Agenten har allerede indtaget kontekst, og din legitimationsoplysning kan allerede være i en andens log. Du scannrer en kadaver.

En moderne pipeline starter på laptoppen. Det betyder at inventere agenter og udvidelser, der kører der, validere, hvilke MCP-servere og modeller de er tilladt at tale til, sanere, hvad der forlader maskinen, og blokerer ondsindede pakker, før de installerer. Herfra følger politikken arbejdet ind i IDE’en. Vi indsætter sikkerhedsstandarder direkte i agentens kontekstvindue, så genereret kode forbliver inden for guardrails fra den første token. Pipelinen kører stadig, udfører endelig verificering af kontroller, der allerede var gennemført upstream.

Pipelinen selv forsvinder ikke. Dens rol bliver verificering: bekræftelse af, at de upstream-kontroller holdt.

Da organisationer fortsætter med at adoptere AI-kodningsagenter, hvilke er de mest kritiske ændringer, de må gøre i dag for at sikre, at deres udviklingsmiljøer forbliver sikre over de næste få år?

Den største fejl er at sikre kun, hvad der committes. Den interessante risiko ligger nu i de otte timer, før en commit sker. Uset drama kan udspille sig på laptoppen, i prompten eller i pakke-installationen. Hvis dine værktøjer starter ved PR’en, beskytter du den forkerte halvdel af arbejdsgangen.

Tæt relateret: stop med at behandle kodningsagenter som produktivitetssoftware. De er ikke-menneskelige brugere med shell-adgang, repository-skriveadgang og udgående netværksforbindelser. Styre dem, som du styre enhver anden privilegeret identitet, med en inventar, godkendte funktioner og audit-logs.

Den sidste skift er sværere kulturelt. De fleste nuværende “AI-sikkerheds”-værktøjer viser fund og router dem til mennesker. Mennesker kan ikke triage i den hastighed, agenter genererer. Hvad du adopterer, må fikse problemer automatisk inden for arbejdsgangen, med sporbar begrundelse, eller det bliver endnu et dashboard, som ingen læser.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Boost Security.