Zaid Al Hamani, CEO og grunnlegger av Boost Security – Intervju-serie

Zaid Al Hamani, CEO og grunnlegger av Boost Security, er en cybersecurity- og DevSecOps-leder med over to tiårs erfaring med å bygge og skale globale teknologioperasjoner. Siden han grunnla Boost Security i 2020, har han fokusert på å modernisere hvordan organisasjoner sikrer programvareutvikling, med utgangspunkt i tidligere roller som VP for Application Security i Trend Micro og medgrunnlegger/CEO av IMMUNIO. Tidligere hadde han ledende stillinger i Canonical, der han ledet produkt-, ingeniør- og globale støtteinitiativer, og i SITA, der han ledet store, kritiske IT-operasjoner. Hans karriere viser en sterk rekord av å bygge lag, optimalisere systemer og fremme moderne sikkerhetspraksis.

Boost Security er et cybersecurity-selskap som fokuserer på å sikre den moderne programvareforsyningskjeden gjennom en utvikler-vennlig DevSecOps-plattform. Deres teknologi integreres direkte i CI/CD-pipelines for å automatisk detektere, prioritere og rette opp sårbarheter, redusere manuell overhead samtidig som utviklingshastigheten opprettholdes. Ved å samordne applikasjon- og forsyningskjedensikkerhet i ett system, gir plattformen full visibilitet over kode, avhengigheter og infrastruktur, og hjelper organisasjoner å styrke motstandskraften i komplekse, sky-baserte miljøer.

Tidligere ledet du applikasjonssikkerhet i Trend Micro og var medgrunnlegger av IMMUNIO. Hva førte til at du grunnla Boost Security, og hva var det største hull i markedet som du var unikt posisjonert til å identifisere tidlig?

IMMUN.IO var ett av de første RASP-selskapene som ble grunnlagt – og vår erfaring frem til da var at WAF-er som en runtime-sikkerhetsteknologi var umulig å vedlikeholde, og ikke særlig effektive. Vi forestilte oss en måte å erstatte WAF-er med en mer nøyaktig, enklere å vedlikeholde løsning – ved å instrumentere applikasjonen.

Dette var i 2012, da DevOps ennå var i sin barndom, og de fleste lag ikke var agile, og Kubernetes ikke var en realitet ennå.

Trend Micro kjøpte opp IMMUN.IO i 2017. Da var det mange flere DevOps-praksiser: CI/CD-pipelines, agile utviklingspraksiser, raskere iterasjoner og utgivelser, sky, osv. Programvareutviklingsteamer var bedre til å bygge programvare, og levere raskere. Sikkerheten var likevel fortsatt brutt:

• Skanninger er for treg, eller resultater kommer for sent
• Resultater er for komplekse for utviklere å håndtere
• Det var en generelt uakseptabel feilpositiv rate
• Mange nye typer artefakter ble ikke scannet: infrastruktur som kode, containere, API-er osv.

Å produsere programvare raskt var enklere. Å produsere sikker programvare raskt var fortsatt vanskelig.

Dette var det opprinnelige problemet vi satte oss for å løse. Få DevSecOps til å fungere i den virkelige verden; kan du få en programvareutviklingsteam til å enkelt legge til sikkerhet i SDLC-en, i en hastighet som matcher de nye standardene? Kan du gjøre dekningen bred – hvor ett plattform er alt du trenger? Kan du gjøre det slik at utviklere, ikke bare adopterer teknologien, men også omfavner den og ser fordelen? Kan du skalerer det slik at du ikke trenger hærer av sikkerhetseksperter for å holde pace med mengden kode som skrives…

Vi hjalp selskaper å injisere sikkerhet i SDLC-en under DevOps-æraen. Det var å gå fra 1 til 10. Vi er nå i agentic-koding-æraen – hvor agenter skriver en enorm mengde kode – men det er fundamentalt det samme problemet – hastighet og volum av kode gikk fra 10 til 100; og vi har som mål å fortsette den samme banen.

Du har argumentert for at programvareutviklingslivssyklusen (SDLC) har fundamentalt skiftet oppstrøms. Hva var øyeblikket du innsett at tradisjonelle DevSecOps-tilnærminger ikke lenger var tilstrekkelige?

Det var å se hvordan angripere faktisk fikk tilgang. Vi så hele tiden den samme mønsteret: en åpen GitHub Actions-arbeidsflyt som ingen hadde gjennomgått siden repoen ble forket, en token med produksjonsklyng-tilgang innebygget i en runner-konfigurasjon, en legitim CI-jobb kapret for å deployere angriper-payload. Disse ble kjent som “living off the pipeline”-angrep, fordi motparten bruker din egen automatisering mot deg, med kredensialer som sikkerhetsteamet allerede hadde godkjent.

DevSecOps-staken vi hadde bygget opp over en tiårsperiode hadde ingen svar på det. SAST-scanner applikasjonskilde. SCA-scanner applikasjonsavhengigheter. Begge antar at pipelineen som kjører dem er pålitelig. I mellomtiden er pipelineen selv en YAML-fil med shell-kommandoer, nettverksaksess og sensitive kredensialer, og nesten ingen gjennomgår den.

Når det blir den letteste veien, kan du levere perfekt ren kode og likevel gi angriperne skyen din.

Hvordan bør bedrifter tenke om SDLC på nytt i en verden hvor AI-agenter genererer kode kontinuerlig i stedet for at utviklere skriver den steg for steg?

Vi må alle slutte å tenke på SDLC som en rekke kontrollpunkter. AI-agenter har kollapset tiden mellom “noen skrev dette” og “dette er i produksjon” fra uker til minutter. Den gamle modellen antok en menneskelig kadens mellom kodegjennomgang, SAST, SCA og deploy, men vi er utenfor det nå.

Sikkerheten må bo der agenten opererer: på utviklerens maskin, inne i prompt-konteksten, i agentens forbindelser til MCP-servere og eksterne modeller. Før koden når pipelineen, har du allerede tapt sjansen til å forme den. Agenten har allerede trukket avhengigheten. Modellen har allerede sett kredensialen. Flytt kontrollene oppstrøms, til der arbeidet faktisk skjer.

Mange organisasjoner behandler fortsatt AI-kodingverktøy som enkle produktivitetslag. Hvorfor mener du at de representerer en helt ny angrepsflate i stedet for bare en utvidelse av eksisterende arbeidsflyter?

Å behandle et AI-kodingverktøy som et produktivitetslag er som å behandle en juniorutvikler med root-tilgang som et produktivitetslag. Etiketten er teknisk sett riktig, men den gir deg ingen nyttig ramme for å tenke på hva som kan gå galt.

En AI-kodingagent leser filsystemet ditt, skraper miljøvariabler for kontekst, henter avhengigheter fra offentlige registre, åpner utgående forbindelser til fjernmodelltilbydere og MCP-servere, og kjører shell-kommandoer. Hver av disse handlingene krevde tidligere en menneskelig innsats. Nå skjer de på millisekunder, med de samme privilegier som utvikleren som lanserte agenten.

Denne kollapsen smelter sammen tillitsgrenser som tidligere var separate: utviklerens autoritet, hva en ekstern verktøy kan hente, og hva uverifisert kode kan kjøre. Dette skaper nye muligheter for angripere og blinde flekker som forsvarere ikke kan se, og mye mindre forsvare.

Boost rammer utviklerlaptoppen som den nye kontrollflaten. Hva slags risiko finnes det på endepunktet som sikkerhetsteam ikke ser?

Den største risikoen er inventar. De fleste sikkerhetsteam kan ikke fortelle deg hvilke AI-agenter som kjører på hvilke bærbare datamaskiner, hvilke MCP-servere og modeller disse agentene er tilkoblet, eller hvilke IDE-utvidelser som skraper repository-innhold akkurat nå. EDR har ingen visibilitet inn i agentlaget; SIEM kan ikke se hva disse agentene gjør lokalt heller.

Under dette ligger kredensial-messen. Vi bygget et åpen kilde-verktøy kalt Bagel delvis for å gjøre dette konkrekt. En typisk utviklerlaptop inneholder GitHub-tokens med skrive-tilgang til produksjonsrepoer, sky-kredensialer som kan spinne opp infrastruktur, npm- eller PyPI-tokens som kan publisere til millioner av brukere, og AI-tjenestenøkler som angripere reseller. Ingen av disse er hardnet på samme måte som en CI-runner er hardnet. Samme maskin som inneholder disse kredensialene surfer også på nettet og installerer tilfeldige VS Code-utvidelser.

Kombiner de to, og du har den faktiske angrepsflaten. En uverifisert utvidelse som kjører med utvikler-privilegier i en miljø full av sky-nøkler er det største målet i det moderne bedriftsmiljøet. De fleste team har ikke startet å se på det.

Du har fremhevet “kontekst-fellen”, hvor AI-agenter kan aksessere lokale filer, miljøvariabler og konfigurasjoner. Hvor utbredt er risikoen for at følsomme data lekker ut gjennom prompter, og hvorfor er det så vanskelig å oppdage?

Tilstrekkelig utbredt til at vi behandler det som standardtilstanden for enhver ustyrt utviklermiljø. Hver eneste AI-kodingagent vi har inspisert, henter lokal kontekst aggressivt. De leser dotfiler, miljøvariabler, nylige filer, noen ganger hele directory-trær, og sender denne konteksten til en fjernmodell. Verktøyene er designet for å fungere på denne måten; aggressiv kontekst-innhenting er hva gjør dem nyttige.

Detekteringsproblemet starter fordi trafikken fra et lekkasje ser identisk ut som normalt produktbruk. Det er TLS til api.openai.com eller api.anthropic.com. Det kommer fra en godkjent forretningsapplikasjon. Standard DLP ser en utvikler som bruker AI-verktøyet selskapet nettopp kjøpte en lisens for. Det ser ikke at en av strengene i den prompten er en AWS-hemmelig nøkkel som agenten hentet fra en halvt-glemt .env-fil i en søsterkatalog.

Du fanger det bare ved å inspisere prompter før de forlater laptoppen, som er akkurat der nesten ingen sikkerhetsstakker er plassert nå.

Du nevner maskin-hastighetsforsyningskjedeangrep. Kan du gå gjennom et realistisk scenario hvor en AI-agent introduserer en sårbarhet raskere enn tradisjonelle sikkerhetsverktøy kan identifisere den?

Her er ett vi har sett variasjoner av flere ganger. Utvikler ber en agent om å legge til en funksjon som trenger en HTTP-gjenopptak-bibliotek. Agenten foreslår et pakkenavn. Pakken er plausibelt-lydende, men eksisterer ikke faktisk på npm. Innen en time registrerer en angriper det, populerer det med fungerende gjenopptak-logikk pluss en liten post-install-skript som leser ~/.aws/credentials og poster innholdet til en webhook. Agenten kjører npm install uten å sjekke, fordi agenter ikke sjekker omdømme. Kredensialen er borte før utvikleren noen gang kjører koden.

Angrepet i seg selv er ikke teknisk sofistikert, men tradisjonell forsyningskjede-sikkerhet er bygget rundt kjente sårbarheter i kjente pakker: CVE-er, SBOM-er, lisensscanning. Denne rammen har ingenting å si om en pakke som ikke eksisterte da skanningen sist ble kjørt, ble skapt spesifikt for å matche en AI-hallusinasjon, og blir inntatt før noen trussel-kanal oppdateres.

Det vinduet fra publisering til kompromittering måles nå i minutter. Alt som sjekker etter faktum er for sent.

Er hallucinerte avhengigheter i ferd med å bli en av de største risikoene i AI-drevet utvikling, og hva praktiske skritt kan organisasjoner ta for å forsvare seg mot dem?

De er allerede en av de største. Angripere overvåker aktivt populære AI-verktøy for hallucinasjoner og registrerer de foreslåtte pakkenavnene innen minutter. Forskere for et par år siden, da det først startet å skje, kalte det slopsquatting, og navnet har holdt. Når et avhengighetsnavn blir hallucinert ofte nok, å sitte på det er et passivt forsyningskjedeangrep med nærmest null innsats.

De praktiske forsvar ser annerledes ut enn det de fleste team har nå. Start ved inntak. Blokker typosquattede og nylig registrerte pakker i øyeblikket npm install eller pip install kjører, på utviklerens maskin, før noe treff disken. Postmortem-deteksjon i CI hjelper ikke når et post-install-skript allerede har eksfiltrert en kredensial. Deretter gi agenten retningslinjer for å operere innenfor. Injiserer din godkjente-avhengighetsliste direkte inn i agentens kontekst, så modellen ser hva som er tillatt før den genererer en forespørsel. Å be utviklere om å skrive “sikre prompter” er ikke en strategi. Hvis du blir strategisk, betyr det at sikkerheten setter grensen, og agenten arver den. Og start med å spore en AI-materialeliste. De fleste team kan ikke fortelle deg hvilke agenter, modeller og pakker som berører hvilke repository.

Du har sagt at sikkerhet ikke lenger kan starte ved CI/CD. Hva ser en moderne sikkerhetspipeline ut som når beskyttelse må starte tidligere i utviklingsprosessen?

Hvis sikkerheten starter ved CI/CD, har du overgitt hele pre-commit-fasen til en miljø du ikke kontrollerer. Agenten har allerede inntatt kontekst, og din kredensial kan allerede være i noen andres logger. Du scannar en kadaver.

En moderne pipeline starter på laptoppen. Det betyr å inventarisere agentene og utvidelsene som kjører der, validere hvilke MCP-servere og modeller de er tillatt å snakke med, sanere hva som forlater maskinen, og blokkere skadelige pakker før de installerer. Deretter følger politikken arbeidet inn i IDE-en. Vi injiserer sikkerhetsstandarder direkte inn i agentens kontekstvindu, så generert kode holder seg innenfor retningslinjene fra første token. Pipelinen selv forsvinner ikke. Rollen dens blir verifisering: å bekrefte at kontrollene som ble tvungne oppstrøms holdt.

Pipelinen selv blir ikke borte. Rollen dens blir verifisering: å bekrefte at kontrollene som ble tvungne oppstrøms holdt.

Ettersom organisasjoner fortsetter å adoptere AI-kodingagenter, hva er de mest kritiske endringene de må gjøre i dag for å sikre at deres utviklingsmiljøer forblir sikre over de neste få årene?

Den største feilen er å sikre bare det som committes. Den interessante risikoen ligger nå i de åtte timene før en commit skjer. Usett drama kan utspille seg på laptoppen, i prompten eller i pakkeinstallasjonen. Hvis dine verktøy starter ved PR-en, beskytter du feil halvdel av arbeidsflyten.

Nært beslektet: slutt å behandle kodingagenter som produktivitetsprogramvare. De er ikke-menneskelige brukere med shell-tilgang, repository-skrive-tilgang og utgående nettverksforbindelser. Styre dem på samme måte du styre enhver annen privilegert identitet, med en inventar, godkjente kapasiteter og audit-logger.

Den siste skiftet er vanskeligere kulturelt. De fleste nåværende “AI-sikkerhetsverktøy” presenterer funn og sender dem til mennesker. Mennesker kan ikke triage i samme hastighet som agenter genererer. Hva du enn adopterer, må det fikse problemer automatisk innenfor arbeidsflyten, med sporbar grunn, eller det blir et annet dashboard ingen leser.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Boost Security.