Zaid Al Hamani, CEO og grundlægger af Boost Security – Interviewserie

Zaid Al Hamani, CEO og grundlægger af Boost Security, er en cybersecurity- og DevSecOps-leder med mere end to årtiers erfaring med opbygning og skaleringsglobal teknologioperationer. Siden grundlæggelsen af Boost Security i 2020 har han fokuseret på at modernisere, hvordan organisationer sikrer softwareudvikling, og har tidligere haft roller som VP of Application Security i Trend Micro og Co-Founder/CEO af IMMUNIO. Tidligere havde han ledende stillinger i Canonical, hvor han ledte produkt-, ingeniør- og globale supportinitiativer, og i SITA, hvor han ledte store, kritiske IT-operationer. Hans karriere viser 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 udvikler-venlig DevSecOps-platform. Dens teknologi integrerer direkte i CI/CD-pipelines for at automatisk detektere, prioritere og afhjælpe sårbarheder, reducere manuel overhæng og opretholde udviklingshastighed. Ved at samle applikations- og forsyningskædesikkerhed i ét system giver platformen fuld visibilitet på tværs af kode, afhængigheder og infrastruktur, hvilket hjælper organisationer med at styrke robustheden i komplekse, cloud-native miljøer.

I før havde du ansvaret for applikationssikkerhed i Trend Micro og var medstifter af IMMUNIO. Hvad førte til, at du grundlagde Boost Security, og hvilken lukket marked 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 købte IMMUN.IO i 2017. På det tidspunkt var der mange flere DevOps-praksisser: CI/CD-pipelines, agile udviklingspraksisser, hurtigere iterationer og udgivelsescyklusser, cloud osv. Softwareudviklingshold var bedre til at bygge software og skibe hurtigere. Sikkerheden var dog stadig brudt:

• Scans er for langsomme eller resultater ankommer for sent
• Resultaterne er for komplekse for udviklere at agere på
• Der var generelt en utilfredsstillende falsk positiv rate
• Mange nye typer af artefakter blev ikke scannet: infrastruktur som kode, 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 arbejde i den virkelige verden; kan du få et softwareudviklingshold til let at tilføje sikkerhed til SDLC, i en hastighed der matcher de nye standarder for hastighed? Kan du gøre det så bredt, at en 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 under DevOps-æraen. Det var gået fra 1 til 10. Vi er nu i agent-kodningens æra – 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 er skiftet upstream. Hvad var det øjeblik, du indså, at traditionelle DevSecOps-tilgange ikke længere var tilstrækkelige?

Det var, da jeg så, hvordan angribere faktisk fik adgang. Vi så hele tiden det samme mønster: en åben 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 hijacked til at deployere angriberens payload. Disse blev kendt som “living off the pipeline”-angreb, fordi modparten bruger din egen automation imod dig, med legitimationsoplysninger, som sikkerhedsteamet 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 stadig give angriberne din sky.

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

Vi må alle stoppe med at tænke på SDLC 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 kodegennemgang, SAST, SCA og deploy, men vi er langt ud over det nu.

Sikkerheden må leve, 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 tabt 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ærkaten er teknisk set korrekt, men den giver dig ingen nyttig ramme for at tænke over, hvad der kan gå galt.

En 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 det på få millisekunder, med de samme privilegier som udvikleren, der startede agenten.

Denne sammenlægning fusionerer tillidsgrænser, der tidligere var adskilte: udviklerens autoritet, hvad et eksternt 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 kontrolplanet. Hvile risici findes der på endpointet, som sikkerhedsteams ikke er opmærksomme på?

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 scraper repository-indhold lige nu. EDR har ingen indsigt i agent-laget; SIEM kan ikke se, hvad disse agenter gør lokalt.

Under det ligger credential-rod. 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 produktion-repos, 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 gensælger. 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 det med hinanden, 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 ikke begyndt at kigge 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?

Tilstrækkelig udbredt til, at vi behandler det som den standardtilstand for enhver ubevogtet udviklermiljø. Hver eneste kodningsagent, vi har inspicereet, trækker lokal kontekst aggressivt. De læser dotfiles, miljøvariabler, nylige filer, undertiden hele directory-træer, og sender denne kontekst til en fjernmodel. Værktøjerne er designet til at fungere på denne måde; aggressiv kontekst-trækning er, hvad der gør dem nyttige.

Detektionsproblemet begynder, 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-glemt .env-fil i en søstermappe.

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 lige nu.

Du nævner maskin-hastighed forsyningskæde-angreb. 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 findes 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. Legitimationsoplysningerne er væk, inden 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 bliver indtaget, før nogen trusselsfeed opdateres.

Det vindue fra offentliggørelse til kompromis måles nu 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 hvilke 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 en afhængighedsnavn bliver hallucineret tilstrækkelig ofte, er det at sidde på det en passiv forsyningskæde-angreb med næsten nul indsats.

De praktiske forsvar ser anderledes ud end det, de fleste teams har i øjeblikket. Start med indtagelse. Bloker typosquattede og nyligt registrerede pakker på det øjeblik, npm install eller pip install kører, på udviklerens maskine, før noget rammer disk. 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 teams kan ikke fortælle dig, hvilke agenter, modeller og pakker, der berører hvilke repos.

Du har sagt, at sikkerheden ikke længere kan begynde ved CI/CD. Hvad ser en moderne sikkerheds-pipeline 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 et lig.

En moderne pipeline starter på laptoppen. Det betyder at inventarisere agenterne og udvidelserne, der kører der, validere, hvilke MCP-servere og modeller de er tilladt at tale til, sanere, hvad der forlader maskinen, og blokerer malicious 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 første token. Pipelinen kører stadig, og gør endelig verifikation på kontroller, der allerede er tvunget upstream.

Pipelinen selv forsvinder ikke. Dens rol bliver verifikation: at bekræfte, at upstream-kontrollerne 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 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, 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-skrive-privilegier 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 overflader fund og sender dem til mennesker. Mennesker kan ikke triage i den hastighed, agenter genererer. Hvad du adopterer, må løse problemerne 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.