Zaid Al Hamani, CEO a zakladatel Boost Security – Interview Series

Zaid Al Hamani, CEO a zakladatel Boost Security, je lídr v oblasti kybernetické bezpečnosti a DevSecOps s více než dvacetiletou zkušeností s budováním a škálováním globálních technologických operací. Od založení Boost Security v roce 2020 se zaměřil na modernizaci způsobu, jakým organizace zajišťují bezpečnost softwarového vývoje, a to na základě svých předchozích rolí, včetně viceprezidenta pro bezpečnost aplikací ve společnosti Trend Micro a spoluzakladatele/CEO společnosti IMMUNIO. Předtím zastával seniorní vedoucí pozice ve společnosti Canonical, kde vedl produkt, inženýrství a globální podpůrné iniciativy, a ve společnosti SITA, kde řídil rozsáhlé, kritické IT operace. Jeho kariéra ukazuje silnou stopu budování týmů, optimalizace systémů a rozvoje moderních bezpečnostních postupů.

Boost Security je kybernetická bezpečnostní společnost zaměřená na zajišťování moderního softwarového dodavatelského řetězce prostřednictvím platformy DevSecOps orientované na vývojáře. Jejich technologie se integruje přímo do CI/CD pipeline, aby automaticky detekovala, priorizovala a odstraňovala zranitelnosti, snižovala manuální režii a zachovávala rychlost vývoje. Díky sjednocení bezpečnostních aplikací a dodavatelského řetězce do jednoho systému poskytuje platforma úplnou viditelnost napříč kódem, závislostmi a infrastrukturou, pomáhající organizacím posílit odolnost v komplexních, cloud-nativních prostředích.

Předtím jste vedl bezpečnost aplikací ve společnosti Trend Micro a spoluzakládal společnost IMMUNIO. Co vás vedlo k založení Boost Security a jakou mezeru na trhu jste byli jedinečně schopni identifikovat?

IMMUN.IO byla jedna z prvních společností RASP, která byla založena – a naše zkušenost do té doby byla, že WAF jako technologická bezpečnost v běhu byla nemožná k údržbě a nebyla příliš efektivní. Představili jsme si způsob, jak WAF bude nahrazena přesnější, snadněji udržovatelnou řešením – instrumentováním aplikace.

To bylo v roce 2012, DevOps byly ještě v počátcích, většina týmů nebyla agilní a Kubernetes nebyl ještě věcí.

Trend Micro získala IMMUN.IO v roce 2017. Do té doby se DevOps praktiky rozvinuly: CI/CD pipeline, agilní vývojové postupy, rychlejší iterace a uvolňování, cloud atd. Týmy pro vývoj softwaru byly lepší v budování softwaru a rychlejším uvolňováním. Bezpečnost však byla stále rozbitá:

• Kontroly jsou příliš pomalé, nebo výsledky přicházejí příliš pozdě
• Výsledky jsou příliš složité pro vývojáře, aby je mohli řešit
• Existuje obecně nepřijatelná míra falešně pozitivních výsledků
• Mnoho nových typů artefaktů nebylo skenováno: infrastruktura jako kód, kontejnery, API atd.

Produkovat software rychleji bylo snazší. Produkovat bezpečný software rychleji však bylo stále obtížné.

To byla původní problém, který jsme se pokusili vyřešit. Umožnit DevSecOps fungovat ve skutečném světě; můžete-li získat tým pro vývoj softwaru, aby snadno přidali bezpečnost do SDLC, při rychlosti, která odpovídá novým standardům rychlosti? Můžete-li udělat pokrytí široké – kde jedna platforma je vše, co potřebujete? Můžete-li to udělat tak, aby vývojáři, nejen přijali technologii, ale také ji uvítali a viděli její výhody? Můžete-li to udělat tak, aby to škálovalo, abyste nepotřebovali armády bezpečnostních odborníků, aby drželi krok s množstvím kódu…

Pomáhali jsme společnostem vstřikovat bezpečnost do SDLC během éry DevOps. To bylo přechod od 1 na 10. Nyní jsme v éře agenty kódování – kde agenti píší enormní množství kódu – ale je to fundamentálně stejný problém – rychlost a objem kódu šel z 10 na 100; a naše cílem je pokračovat ve stejné trajektorii.

Vy jste dříve argumentoval, že software development lifecycle (SDLC) se fundamentálně posunul po proudu. Jaký byl moment, kdy jste si uvědomil, že tradiční DevSecOps přístupy již nejsou dostatečné?

Byl to okamžik, kdy jsme sledovali, jak útočníci skutečně pronikají. Viděli jsme stejný vzorec: vystavený GitHub Actions workflow, který nikdo nekontroloval od chvíle, kdy byl forkován, token s produkční cloudovou přístupem vložený do konfiguračního souboru runneru, legitimní CI úloha uchvácená pro nasazení útočných payloadů. Tyto se staly známými jako „živé z pipeline“ útoky, protože útočník používá vaši vlastní automatizaci proti vám, s kredity, které vaše bezpečnostní tým již schválil.

DevSecOps stack, který jsme postavili za posledních deset let, neměl odpověď na to. SAST skenuje aplikaci zdroj. SCA skenuje aplikaci závislosti. Oba předpokládají, že pipeline, který je spouští, je důvěryhodný. Zatímco pipeline sám je YAML soubor se shell příkazy, síťovým přístupem a citlivými kredity, a téměř nikdo ho nekontroluje.

Když se to stane nejlehčím způsobem, můžete dodat dokonale čistý kód a přesto útočníkovi dát váš cloud.

Jak by měly podniky přehodnotit SDLC ve světě, kde agenti AI generují kód nepřetržitě místo toho, aby vývojáři psali kód krok za krokem?

Všichni musíme přestat myslet na SDLC jako na sekvenci kontrolních bodů. Agenti AI zkrátili čas mezi „někdo napsal tohle“ a „to je v produkci“ z týdnů na minuty. Starý model předpokládal lidský rytmus mezi kontrolou kódu, SAST, SCA a deploy, ale jsme již za tím.

Bezpečnost musí žít tam, kde agent operuje: na vývojářově stroji, uvnitř kontextu promptu, v agentových spojeních s MCP servery a externími modely. Do té doby, než kód dosáhne pipeline, jste již ztratili šanci ho ovlivnit. Agent již stáhl závislost. Model již viděl kredity. Přesuňte kontroly po proudu, tam, kde skutečně probíhá práce.

Mnohé organizace stále považují nástroje pro kódování AI za jednoduché produktivní vrstvy. Proč věříte, že reprezentují zcela novou útočnou plochu, a not only rozšíření stávajících pracovních postupů?

Považovat nástroj pro kódování AI za produktivní vrstvu je jako považovat junior developera s root přístupem za produktivní vrstvu. Označení je technicky přesné, ale nedává vám žádný užitečný rámec pro přemýšlení o tom, co může go wrong.

Kódovací agent čte váš filesystem, scrapuje environmentální proměnné pro kontext, fetchuje závislosti z veřejných registrů, otevírá odchozí spojení na vzdálené modelové poskytovatele a MCP servery, a spouští shell příkazy. Každá z těchto akcí dříve vyžadovala lidskou účast. Nyní se dějí v milisekundách, se stejnými oprávněními jako vývojář, který spustil agenta.

To spojuje důvěryhodné hranice, které dříve byly samostatné: vývojářova autorita, co může externí nástroj fetch, a co může spustit nedůvěryhodný kód. To vytváří nové příležitosti pro útočníky a slepá místa, která obránci nemohou ani vidět, natož bránit.

Boost Security rámcuje vývojářský laptop jako novou řídicí plochu. Jaká rizika existují na koncovém bodu, která bezpečnostní týmy目前 přehlížejí?

Největší z nich je inventář. Většina bezpečnostních týmů nemůže říci, které agenty AI běží na kterých laptopech, ke kterým MCP serverům jsou tyto agenty připojeny, nebo které IDE rozšíření právě skenují repozitářní obsah. EDR nemá viditelnost do agentní vrstvy; SIEM nemůže vidět, co tyto agenty dělají lokálně.

Pod tím leží kreditační chaos. Vyvinuli jsme open-source nástroj nazvaný Bagel částečně proto, aby to učinil konkrétním. Typický vývojářský laptop drží GitHub tokeny s přístupem pro zápis do produkčních repozitářů, cloudové kredity, které mohou spustit infrastrukturu, npm nebo PyPI tokeny, které mohou publikovat do milionů uživatelů, a AI služba klíče, které útočníci prodávají. Žádný z nich není zabezpečen způsobem, jakým je zabezpečen CI runner. Stejný stroj, který drží tyto kredity, také prohlíží web a instaluje náhodné VS Code rozšíření.

Spojte tyto dvě věci a máte skutečnou útočnou plochu. Nedůvěryhodné rozšíření běžící s vývojářskými oprávněními v prostředí plném cloudových klíčů je nejvyšší prioritou v moderní firmě. Většina týmů se na to ještě nezačala dívat.

Vy jste zdůraznili „kontextovou past“, kde agenti AI mohou přístup k místním souborům, environmentálním proměnným a konfiguracím. Jak rozšířené je riziko úniku citlivých dat prostřednictvím promptů a proč je tak obtížné je detekovat?

Dostatečně rozšířené, aby jsme je považovali za výchozí stav každé neřízené vývojářské prostředí. Každý kódovací agent, který jsme prozkoumali, agresivně čte lokální kontext. Čtou dotfile, environmentální proměnné, nedávné soubory, někdy celé adresářové stromy, a odesílají tento kontext na vzdálený model. Nástroje jsou navrženy tak, aby fungovaly tímto způsobem; agresivní čtení kontextu je to, co je dělá užitečnými.

Problém detekce začíná tím, že provoz z úniku vypadá identicky jako normální použití produktu. Je to TLS na api.openai.com nebo api.anthropic.com. Přichází z schváleného obchodního aplikace. Standardní DLP vidí vývojáře, který používá AI nástroj, který společnost právě zakoupila. Nevídí, že jedna ze strun v tomto promptu je AWS tajný klíč, který agent získal z půl zapomenutého .env souboru v sourozeneckém adresáři.

Chytnete to pouze tím, že prozkoumáte prompty předtím, než opustí laptop, což je přesně tam, kde téměř žádný bezpečnostní stack目前 není umístěn.

Můžete nás provést realistickým scénářem, kde agent AI zavádí zranitelnost rychleji, než tradiční bezpečnostní nástroje mohou identifikovat?

Zde je jeden, který jsme viděli varianty opakovaně. Vývojář žádá agenta, aby přidali funkci, která potřebuje HTTP retry knihovnu. Agent navrhuje název balíčku. Balíček je pravděpodobně znějící, ale ve skutečnosti neexistuje na npm. Do hodiny útočník registruje, naplní jej funkční retry logikou plus malým post-install skriptem, který čte ~/.aws/credentials a pošle obsah na webhook. Agent spustí npm install bez kontroly, protože agenti nekontrolují reputaci. Kredita je pryč, než vývojář dokonce spustí kód.

Sám útok není technicky sofistikovaný, ale tradiční bezpečnost dodavatelského řetězce je postavena kolem známých zranitelností v známých balíčcích: CVE, SBOM, licence skenování. Ten framework nemá nic říci o balíčku, který neexistoval, když byl poslední scan proveden, byl vytvořen speciálně pro AI hallucinaci a je pořízen předtím, než se aktualizují hrozby.

Okno od publikace do kompromisu je nyní měřeno v minutách. Cokoliv, co kontroluje po faktu, kontroluje příliš pozdě.

Stávají se hallucinované závislosti jedním z největších rizik ve vývoji řízeném AI a jaké praktické kroky mohou podniky podniknout, aby se proti nim bránily?

Už jsou. Útočníci aktivně monitorují populární AI nástroje pro hallucinace a registrují navrhované názvy balíčků do několika minut. Výzkumníci před několika lety, kdy se to poprvé stalo, nazvali to slopsquatting a název ulpěl. Jakmile je název závislosti hallucinován dostatečně často, sedět na něm je pasivní útok na dodavatelský řetězec s téměř nulovým úsilím.

Praktické obrany vypadají jinak, než co většina týmů目前 má. Začněte u ingestování. Blokujte typograficky podobné a nově registrované balíčky v okamžiku, kdy běží npm install nebo pip install, na vývojářově stroji, předtím, než něco zasáhne disk. Postmortem detekce v CI nepomůže, když post-install skript již exfiltrace kredity. Pak dejte agentovi zábradlí, aby operoval uvnitř. Vložte schválený seznam závislostí přímo do agentova kontextu, aby model viděl, co je povolené, než vygeneruje návrh. Žádání vývojářů, aby psali „bezpečné prompty“, není strategie. Pokud jste strategičtí, znamená to, že bezpečnost nastavuje hranici, agent dědí ji. A začněte sledovat AI Bill of Materials. Většina týmů nemůže říci, které agenty, modely a balíčky se dotýkají kterých repozitářů. Nemůžete bránit to, co nemůžete inventorizovat.

Vy jste řekl, že bezpečnost již nemůže začínat u CI/CD. Jak vypadá moderní bezpečnostní pipeline, když ochrana potřebuje začít dříve ve vývojovém procesu?

Pokud bezpečnost začíná u CI/CD, jste již vzdali celý pre-commit fázi prostředí, které nekontrolujete. Agent již ingestoval kontext, vaše kredita může již být v někoho jiného logu. Skenujete mrtvolu.

Moderní pipeline začíná na laptopu. To znamená inventorizovat agenty a rozšíření, které na něm běží, ověřovat, ke kterým MCP serverům a modelům jsou povoleny mluvit, sanovat, co opouští stroj, a blokovat škodlivé balíčky, než se nainstalují. Odtud politika následuje práci do IDE. Vkládáme bezpečnostní standardy přímo do agentova kontextového okna, aby vygenerovaný kód zůstal uvnitř zábradlí od prvního tokenu. Pipeline stále běží, dělající konečnou verifikaci kontrol, které byly již vynuceny po proudu.

Pipeline sám nezmizí. Jeho role se stává verifikací: potvrzující, že po proudu vynucené kontroly držely.

Jaké jsou nejkritičtější změny, které podniky musí udělat dnes, aby zajistily, že jejich vývojová prostředí zůstanou zabezpečená v příštích několika letech?

Největší chyba je zabezpečovat pouze to, co se commituje. Zajímavé riziko nyní žije v osmi hodinách před commitem. Neviditelná dramata se mohou rozvinout na laptopu, v promptu nebo v balíčku instalaci. Pokud vaše nástroje začínají u PR, chráníte špatnou polovinu pracovního postupu.

Úzce související: přestat považovat kódovací agenty za produktivní software. Jsou to nehumánní uživatelé se shell přístupem, repozitářovými právy pro zápis a odchozími síťovými spojeními. Řídit je způsobem, jakým řídíte jakýkoli jiný privilegovaný identifikátor, s inventářem, schválenými schopnostmi a auditními logy.

Poslední posun je obtížnější kulturně. Většina současných „AI bezpečnostních“ nástrojů surface findings a route them to humans. Humans cannot triage at the speed agents generate. Whatever you adopt has to fix issues automatically inside the workflow, with traceable reasoning, or it becomes another dashboard nobody reads. Thank you for the great interview, readers who wish to learn more should visit Boost Security.