Zaid Al Hamani, CEO a zakladatel Boost Security – rozhovor

Zaid Al Hamani, CEO a zakladatel Boost Security, je odborníkem v oblasti kybernetické bezpečnosti a DevSecOps s více než dvacetiletou zkušeností s budováním a rozvojem 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ě pozice 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 produkty, inženýrství a globální podpůrné iniciativy, a ve společnosti SITA, kde spravoval rozsáhlé, kritické IT operace. Jeho kariéra je charakterizována silnou schopností budovat týmy, optimalizovat systémy a rozvíjet moderní bezpečnostní postupy.

Boost Security je kybernetická bezpečnostní společnost, která se zaměřuje na zajištění moderního softwarového dodavatelského řetězce prostřednictvím platformy DevSecOps pro vývojáře. Jejich technologie se přímo integruje do CI/CD pipeline, aby automaticky detekovala, priorizovala a odstraňovala zranitelnosti, snižovala manuální režii a udržovala rychlost vývoje. Díky sjednocení aplikací a bezpečnostních dodavatelských řetězců do jednoho systému poskytuje platforma úplnou viditelnost kódu, závislostí a infrastruktury, což pomáhá organizacím posílit odolnost v komplexních, cloudový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šenosti do té doby byly takové, že WAF jako bezpečnostní technologie v době běhu byly nemožné udržet a nebyly příliš efektivní. Představovali jsme si způsob, jak WAF bude nahrazena přesnější a snadněji udržovatelnou řešením – instrumentováním aplikace.

To bylo v roce 2012, DevOps byly ještě v počátcích, most týmy nebyly agilní a Kubernetes nebyl ještě věcí.

Trend Micro získala IMMUN.IO v roce 2017. Do té doby existovaly již více DevOps postupy: CI/CD pipeline, agilní vývojové postupy, rychlejší iterace a cykly vydání, cloud atd. Týmy pro vývoj softwaru byly lepší v budování softwaru a jeho expedici. 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š komplexní pro vývojáře, aby je mohli uplatnit
• Existuje obecně nepřijatelná míra falešně pozitivních výsledků
• Mnohé nové typy artefaktů nejsou skenovány: infrastruktura jako kód, kontejnery, API atd.

Produkovat software rychleji bylo snazší. Produkovat bezpečný software rychleji 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, aby jste nemuseli mít armády bezpečnostních odborníků, aby drželi krok s množstvím kódu napsaného…

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

Argumentovali jste, že software development lifecycle (SDLC) se fundamentálně posunul po proudu. Jaký byl okamžik, kdy jste si uvědomili, ž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 stále 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 konfigurace runneru, legitimitní CI úloha uchvácená pro nasazení útočných paylaodů. 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 spustí, je důvěryhodný. Zatímco pipeline sám je YAML soubor se shellovými 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 stále útočníkovi dát váš cloud.

Jak by měly organizace přehodnotit SDLC ve světě, kde AI agenti generují kód nepřetržitě, spíše než vývojáři píšící krok za krokem?

Musíme všichni přestat myslet na SDLC jako na sekvenci kontrolních bodů. AI agenti zkrátili dobu 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 za tím nyní.

Bezpečnost musí žít tam, kde agent operuje: na vývojářově stroji, uvnitř 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í AI kódovací nástroje za jednoduché vrstvy produktivity. Proč jste přesvědčeni, že reprezentují zcela novou útočnou plochu, spíše než jen rozšíření stávajících pracovních postupů?

Považovat AI kódovací nástroj 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 myšlení o tom, co by mohlo 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í shellové 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ěrné 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 popisuje vývojářský laptop jako novou řídicí plochu. Jaká rizika existují na koncovém bodu, která bezpečnostní týmy v současnosti přehlížejí?

Největší riziko je inventura. Most bezpečnostních týmů nemůže říci, které AI agenty běží na kterých laptopích, které MCP servery tyto agenty komunikují, nebo které IDE rozšíření právě skenují repozitářový obsah. EDR nemá viditelnost do agentní vrstvy; SIEM nemůže vidět, co tyto agenty dělají lokálně.

Pod tím leží credential chaos. Vytvořili jsme open-source nástroj nazvaný Bagel částečně proto, aby se toto problém stalo konkrétnějším. Typický vývojářský laptop drží GitHub tokeny s write přístupem k produkčním repozitářům, cloudové kredity, které mohou spustit infrastrukturu, npm nebo PyPI tokeny, které mohou publikovat miliony uživatelům, a AI služba klíče, které útočníci znovu prodávají. Žádné z toho není zabezpečeno 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 dvě 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šší-prioritní cíl v moderní podnikové sféře. Most týmy ještě nezačaly hledat.

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

Dostatečně široce, aby jsme jej považovali za výchozí stav libovolného neřízeného vývojářského prostředí. Každý kódovací agent, který jsme prozkoumali, agresivně čte lokální kontext. Čtou dotfiles, 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í kontextový grab 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í produktové použití. Je to TLS do api.openai.com nebo api.anthropic.com. Pochází z schválené obchodní aplikace. Standardní DLP vidí developera, který používá AI nástroj, který společnost právě zakoupila licenci. Nevídí, že jeden z řetězců v tomto promptu je AWS tajný klíč, který agent načte z polozapomenutého .env souboru v sesterské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í aktuálně umístěn.

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

Toto je jeden scénář, který jsme viděli opakovaně. Developer žádá agenta, aby přidali funkci, která potřebuje knihovnu HTTP retry. Agent navrhuje název balíčku. Balíček je pravděpodobně znějící, ale ve skutečnosti neexistuje na npm. Do hodiny zaregistruje útočník, 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. Kredity jsou 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í. Tento rámec nemá nic co říci o balíčku, který neexistoval, když byla poslední skenování provedena.

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

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

Už jsou. Útočníci aktivně monitorují populární AI nástroje pro halucinace a registrují navrhované názvy balíčků do několika minut. Výzkumníci před několika lety, kdy se to poprvé stalo, to nazvali slopsquatting a název ulpěl. Jakmile je název závislosti halucinová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 mají most týmy aktuálně. Začněte u ingestování. Blokujte typosquattované a nově registrované balíčky v okamžiku, kdy běží npm install nebo pip install, na vývojářově stroji, předtím, než cokoliv dosáhne disku. Postmortem detekce v CI nepomůže, když post-install skript již exfiltrace credential. Pak dejte agentovi guardrails, aby operoval uvnitř. Vložte vámi 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 hranice, agent dědí ji. A začněte sledovat AI Bill of Materials. Most týmy nemohou říci, které agenty, modely a balíčky se dotýkají kterých repozitářů. Nemůžete bránit to, co nemůžete inventarizovat.

Rekli jste, ž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 celou fázi před commitem prostředí, které nekontrolujete. Agent již ingestoval kontext, vaše kredity mohou být již v někoho jiného logu. Skenujete mrtvolu.

Moderní pipeline začíná na laptopu. To znamená inventarizaci agentů a rozšíření běžících tam, validaci, které MCP servery a modely jsou povoleny mluvit, sanitizaci toho, co opouští stroj, a blokování škodlivých balíčků předtím, 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ř guardrailů od prvního tokenu. Pipeline stále běží, provádějící finální verifikaci kontrol, které byly již vynuceny po proudu.

Pipeline samo o sobě nezmizí. Jeho role se stává verifikací: potvrzující, že upstream kontroly držely.

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

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 workflow.

Closely related: přestaňte považovat kódovací agenty za produktivní software. Jsou to nehumánní uživatelé se shellovým přístupem, repozitářovými write oprávněními a odchozími síťovými spojeními. Řídit je způsobem, jakým řídíte jakoukoli jinou privilegovanou identitu, s inventarizací, schválenými schopnostmi a auditními logy.

Poslední posun je obtížnější kulturně. Most current „AI bezpečnostní“ nástroje surface findings a route je k lidem. Lidé nemohou triage na rychlost, kterou agenty generují. Cokoliv, co adoptujete, musí automaticky řešit problémy uvnitř workflow, s traceable reasoning, nebo se stane dalším dashboardem, který nikdo nečte.

Děkuji vám za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Boost Security.