Zaid Al Hamani, administrerende direktør og grunnlegger av Boost Security – Intervju-serie

Zaid Al Hamani, administrerende direktør og grunnlegger av Boost Security, er en ledende ekspert på cybersikkerhet og DevSecOps 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, bygget på tidligere roller som vicepresident for applikasjonssikkerhet 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 for å bygge team, optimalisere systemer og fremme moderne sikkerhetspraksis.

Boost Security er et 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 arbeid samtidig som utviklingshastigheten opprettholdes. Ved å samle 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.

Du ledet tidligere applikasjonssikkerhet i Trend Micro og var medgrunnlegger av IMMUNIO. Hva ledet deg til å grunnlegge Boost Security, og hvilket hull i markedet var du 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 hvor WAF-er ville bli erstattet med en mer nøyaktig, enklere å vedlikeholde løsning – ved å instrumentere applikasjonen.

Dette var i 2012, DevOps var fortsatt i begynnelsen, de fleste teamene var ikke Agile, og Kubernetes var ikke en ting ennå.

Trend Micro kjøpte IMMUN.IO i 2017. På det tidspunktet var det mye flere DevOps-praksiser: CI/CD-pipelines, Agile-utviklingspraksiser, raskere iterasjoner og utgivelser, sky, osv. Programvareutviklingsteamene var bedre til å bygge programvare, og levere raskere. Sikkerheten var fortsatt ødelagt though:

• Skaninger er for treg, eller resultater ankommer 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 for eksempel

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

Dette var det opprinnelige problemet vi satte oss for å løse. Gjøre DevSecOps til å fungere i den virkelige verden; kan du få et programvareutviklingsteam til å enkelt legge til sikkerhet i SDLC, med en hastighet som matcher de nye standardene for hastighet? Kan du gjøre dekningen bred – hvor en 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 gjøre det så skaleringen ikke trenger hærer av sikkerhetseksperter for å holde pace med mengden kode som skrives…

Vi hjalp selskaper å injisere sikkerhet i SDLC 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 sikter på å 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 eksponert GitHub Actions-arbeidsflyt som ingen hadde gjennomgått siden repoen ble forket, en token med produksjonsklyng tilgang innbettet i en runner-konfigurasjon, en legitim CI-jobb kapret for å distribuere angriper-payload. Disse ble kjent som “living off the pipeline”-angrep, fordi motparten bruker din egen automatisering mot deg, med kredensialer din sikkerhetsteam allerede hadde godkjent.

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

Når det blir den enkleste måten, kan du levere perfekt ren kode og likevel gi angriperne din sky.

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 skritt for skritt?

Vi må alle slutte å tenke på SDLC som en rekke av 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, innenfor prompt-konteksten, i agentens forbindelser til MCP-servere og eksterne modeller. Før koden når pipelineen, har du allerede mistet sjansen til å forme den. Agenten har allerede trukket avhengigheten. Modellen har allerede sett kredensialen. Flytt kontrollene oppstrøms, til hvor arbeidet faktisk skjer.

Mange organisasjoner behandler fortsatt AI-kodingverktøy som enkle produktivitetslag. Hvorfor tror du 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 junior-utvikler med root-tilgang som et produktivitetslag. Etiketten er teknisk nøyaktig, men den gir deg ingen nyttig ramme for å tenke på hva som kan gå galt.

Et kodingagent leser din filsystem, scraper miljøvariabler for kontekst, henter avhengigheter fra offentlige registre, åpner utgående forbindelser til remote modelltilbydere og MCP-servere, og kjører shell-kommandoer. Hver av disse handlingene krevde tidligere en menneskelig i løkken. Nå skjer de på millisekunder, med samme privilegier som utvikleren som lanserte agenten.

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

Boost rammer utviklerlaptopen som den nye kontrollplanet. Hvilke risikoer finnes det på endepunktet som sikkerhetsteamene i dag overseer?

Det største er inventar. De fleste sikkerhetsteamene kan ikke fortelle deg hvilke AI-agenter som kjører på hvilke bærbare datamaskiner, hvilke MCP-servere disse agentene er koblet til, eller hvilke IDE-utvidelser som scraper 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 kredensialrotten. 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 upålitelig utvidelse som kjører med utvikler-privilegier i en miljø full av sky-koder er det største målet i det moderne bedriftsmiljøet. De fleste teamene har ikke startet å se på det.

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

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

Oppdagelsesproblemet starter fordi trafikken fra en 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 halv-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 i dag.

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 det?

Her er ett vi har sett variasjoner av gjentatte ganger. Utvikler ber en agent om å legge til en funksjon som trenger en HTTP-gjentakelsesbibliotek. Agenten foreslår et pakkenavn. Pakken er plausibelt-lydende, men eksisterer ikke på npm. Innen en time registrerer en angriper det, populerer det med fungerende gjentakelseslogikk 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 opprettet spesifikt for å matche en AI-hallusinasjon, og blir inntatt før noen trussel-feed oppdateres.

Vinduet fra publisering til kompromiss er nå målt i minutter. Alt som sjekker etter faktum er sjekker for sent.

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

De er allerede ett 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 noen år siden, da det først begynte å skje, kalte det slopsquatting og navnet har vært med siden.

De praktiske forsvar ser annerledes ut enn hva de fleste teamene har i dag. 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-oppdagelse i CI hjelper ikke når en 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, agenten arver den. Og start med å spore en AI Bill of Materials. De fleste teamene kan ikke fortelle deg hvilke agenter, modeller og pakker som berører hvilke repositoryer.

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

Hvis sikkerheten starter ved CI/CD, har du gitt hele pre-commit-fasen til en miljø du ikke kontrollerer. Agenten har allerede inntatt kontekst, din kredensial kan allerede være i noen andres logger. Du scannrer 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. Pipelineen kjører fortsatt, gjør en siste verifisering av kontrollene som allerede var påtvunget oppstrøms.

Pipelineen selv forsvinner ikke. Rollen blir verifisering: bekreftelse av at de oppstrøms kontrollene holdt.

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

Det største feilgrep er å sikre bare hva 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, 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 som du styre enhver annen privilegert identitet, med en inventar, godkjente kapasiteter og audit-logger.

Den siste skiftet er hardest kulturelt. De fleste gjeldende “AI-sikkerhets”-verktøy presenterer funn og router dem til mennesker. Mennesker kan ikke triage i samme hastighet som agenter genererer. Hva du adopterer, må 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.