Jeff Williams, zakladatel OWASP a zakladatel & CTO Contrast Security – rozhovor

Jeff Williams, zakladatel OWASP a zakladatel & CTO Contrast Security, je široce uznávanou osobností v moderní aplikaci zabezpečení. Během několika posledních desetiletí pomohl formovat, jak organizace přistupují k bezpečnému vývoji softwaru, správě zranitelností a ochraně aplikací během runtime. Williams sehrál ústřední roli při budování OWASP z malé dobrovolnické iniciativy do globálně uznávané neziskové bezpečnostní nadace, přispěl k významným projektům, jako je OWASP Top Ten, WebGoat, ESAPI, ASVS a XSS Prevention Cheat Sheet. Před založením Contrast Security v roce 2014 založil také Aspect Security, jednu z prvních firem, které se specializovaly výhradně na konzultace aplikací zabezpečení, školení, penetrační testování a bezpečné vývojové postupy pro podniky.

OWASP je nezisková nadace zaměřená na zlepšení softwarového zabezpečení prostřednictvím open-source projektů, globální komunitní spolupráce, vzdělávání a průmyslových standardů. Založena v roce 2001, organizace se stala jednou z nejvýznamnějších autorit v aplikaci zabezpečení, s stovkami místních kapitol, tisíci přispěvatelů a široce přijímanými zdroji používanými vývojáři, bezpečnostními odborníky, podniky a vládami po celém světě. OWASP je nejlépe známá projekty, jako je OWASP Top Ten, který identifikuje nejkritičtější rizika zabezpečení webových aplikací, spolu s mnoha bezpečnostními rámci, testovacími nástroji, dokumentačními projekty a vzdělávacími iniciativami. Organizace funguje na základě filozofie nezávislého dodavatele, což činí její vzdělávací zdroje a bezpečnostní pokyny volně dostupnými pro globální technologickou komunitu.

Contrast Security je společnost pro aplikaci zabezpečení, která se zaměřuje na ochranu softwaru z vnitřku spuštěné aplikace, místo aby se spoléhala pouze na externí skenovací nástroje. Platforma společnosti používá technologii runtime instrumentace, aby poskytovala reálnou viditelnost do zranitelností, útoků, API, open-source závislostí a chování aplikací napříč vývojovým a produkčním prostředím. Jejich nabídky zahrnují oblasti, jako je Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) a analýza softwarové kompozice. Contrast Security se umístila kolem integrace zabezpečení přímo do moderních DevSecOps pracovních postupů, umožňujících vývojářům, AppSec týmům a bezpečnostním operačním týmům identifikovat a odstraňovat zranitelnosti rychleji, zatímco udržují rychlé dodávky softwaru.

Po pomoci při formování moderního aplikovaného zabezpečení prostřednictvím vaší práce s Open Web Application Security Project (OWASP), jaká mezera v průmyslu vedla k založení Contrast Security, a jak se původní teze udržela, zatímco bezpečnostní výzvy se vyvíjely?

Průmysl se utopil v teoretických statických nálezech a nebyl schopen se zaměřit na problémy, které skutečně záleží. Bezpečnostní týmy měly skenery generující obrovské backlogy bez znalosti, které zranitelnosti jsou dosažitelné, využitelné nebo napadené v produkci. Založili jsme Contrast na jednoduché myšlence: bezpečnostní rozhodnutí by měla pocházet z přímého pozorování skutečných běžících aplikací, ne odhadů zvenčí.

Nakonec doufám, že průmysl pokročí do bodu, kdy se dostaneme z kola najíždění problémů, oprav a najíždění dalších problémů navždy. Doufám, že budeme moci začít vytvářet software, který má silnou bezpečnostní architekturu a skutečný argument, že má správné obrany pro očekávané hrozby. Kombinace runtime zabezpečení a AI má potenciál, ale jsme roky pryč.

Popisujete vznik „Mythos-level zranitelností“. Co definuje tuto novou třídu rizika a proč jsou tak obtížné pro konvenční bezpečnostní nástroje detekovat?

Mythos-level zranitelnosti jsou chyby, které vznikají z komplexity moderních softwarových zásobníků. Interakce mezi chováním frameworku, závislostmi a architektonickými vzory je tak složitá, že vývojáři často úplně nerozumí. Konvenční nástroje jsou stále optimalizovány pro relativně jednoduché známé vzory a pozorovatelné události. Mythos-style zranitelnosti často vyžadují porozumění chování aplikací, toku provádění a kontextu runtime na mnohem hlubší úrovni.

Proč celé kategorie zranitelností selhávají generovat výstrahy v moderních Security Operations Center (SOC) prostředích a co to odhaluje o tom, jak bezpečnostní týmy目前 měří riziko?

Most SOCs jsou postaveny kolem pozorovatelných událostí: logů, signatur, síťového provozu, aktivity koncových bodů. Ale mnoho aplikací vrstev útoků nikdy nevytváří významné signály v těchto systémech. Vývojář nevěděl, že existuje zranitelnost, a nezadal žádné protokolování, které by odhalilo exploit. Takže většina aplikací exploitů je zcela neviditelná v logích. SOC týmy mohou reagovat pouze na to, co vidí. Takže jak se aplikační a API vrstva stává stále důležitější, je kritické zajistit, aby jsme ji vybavili bezpečnostními senzory, které mohou detekovat a hlásit anomální chování.

Moderní aplikační architektury, jako jsou mikroslužby, API a serverless systémy, se vyvíjely rychle. Kde tyto architektury předhánějí současné založené na detekci bezpečnostní přístupy?

Tyto architektury rozbité staré perimetrové modely. Žádosti nyní procházejí desítky služeb, efemérních funkcí, API, front, třetích stran a závislostí, než dokončí transakci. Most detekčních systémů stále vidí fragmenty místo plné cesty provádění. Mohou prohlížet balíčky nebo logy, ale nemohou pochopit záměr, tok dat nebo zda nebezpečný kód skutečně spustil. Bezpečnost je o kontextu, takže potřebujeme postavit model, digitální dvojče, naší aplikační infrastruktury, které nám (nebo agentům AI) umožní uvažovat o tom, co se děje.

OWASP Top Ten stále zdůrazňuje problémy, jako je nezabezpečený design a zranitelné komponenty. Proč tato rizika přetrvávají navzdory širokému povědomí a nástrojům?

Povědomí neopravuje pobídky nebo složitost. Most organizací stále měří úspěch objemem skenování, uzavřením lístků nebo kontrolou dodržování předpisů spíše než skutečným snížením expozice.

Ve stejnou dobu softwarové dodavatelské řetězce explodovaly ve velikosti. Vývojáři sestavují aplikace z tisíců komponent, které nenapsali a určitě neohodnotili z hlediska zabezpečení. Bezpečnostní týmy jsou zahlceny pokusem o triáž teoretických rizik a nemohou se zaměřit na 1-2%, která skutečně záleží. Bez runtime důkazů se priorita rozpadá. A s výskytem powerful AI modelů a harnessů se objem zvyšuje exponenciálně.

Jak by organizace měly přehodnotit svou závislost na logách a výstrahách, když některé z nejkritičtějších zranitelností nezanechávají žádné pozorovatelné signály?

Logy jsou důkazem toho, co aplikace zvolily hlásit, ne nutně důkazem toho, co se skutečně stalo. To je nebezpečný rozdíl. Organizace potřebují přesunout se z nepřímého pozorování na přímé pozorování. Místo doufání, že exploit vytvoří detekovatelnou stopu, bezpečnostní systémy by měly identifikovat zranitelné chování a exploitační chování během runtime. Pokud nebezpečný kód spustil, systém by měl vědět okamžitě — bez ohledu na to, zda existuje logový záznam.

Vy jste hájil runtime viditelnost jako řešení. Co vypadá skutečná runtime viditelnost v praxi a jak mění způsob, jakým bezpečnostní týmy fungují denně?

Skutečná runtime viditelnost znamená porozumění tomu, co aplikace skutečně dělá v produkci: které trasy jsou vystaveny, které knihovny jsou aktivní, kam citlivé údaje proudí, jaký kód spustil a zda útok dosáhl zranitelné funkcionality. Operačně to mění bezpečnost z reaktivního loveckého cvičení na přesnou disciplínu. Týmy přestanou honit obrovské backlogy zranitelností a začnou se zaměřovat na malý procentní podíl expozic, které jsou dosažitelné, kritické a aktivně zaměřené. To dramaticky zlepšuje poměr signálu k šumu a rychlost reakce. Průměrně pouze 38% open source knihoven zabalených v aplikaci je skutečně načteno do paměti a spuštěno. A ne všechny kódy v tomto podmnožině jsou použity. Takže jedna jednoduchá věc, kterou runtime zabezpečení umožňuje, je zaměřit se na kód, který skutečně běží, a ne na všechny nevyužité knihovny a funkce, které přicházejí s aplikací.

Jak se instrumentace-založené zabezpečení porovnává s tradičními přístupy, jako je SAST, DAST nebo perimetrové monitorování, z hlediska účinnosti a škálovatelnosti?

Tradiční nástroje inferují riziko zvenčí. Instrumentace pozoruje realitu pozorováním skutečného kódu, jak běží. Instrumentace může vidět skutečné cesty provádění, chování frameworku, kontext ověření, tok dat a úspěch exploitu v reálném čase. Eliminuje obrovské kategorie falešných pozitiv a odhaluje zranitelnosti, které perimetrové nástroje úplně přehlížejí.
Na škále se tato přesnost stává kritickou. Organizace nemohou ručně triážovat miliony teoretických nálezů. Runtime důkazy se stávají jediným udržitelným filtrem. Runtime funguje v reálném čase, takže je lepší shoda pro vývoj a CI/CD potrubí než skenování a triáž. A runtime je kontinuální, takže není omezený na snímek bodu v čase zabezpečení.

Jak se AI systémy a autonomní aplikace stávají více převládajícími, stávají se tyto neviditelné zranitelnosti nebezpečnějšími, a jak by se týmy měly připravit?

AI dělá neviditelné zranitelnosti mnohem nebezpečnějšími, protože urychluje obě strany problému. Vývojáři generují software rychleji a útočníci nacházejí a využívají slabosti rychleji. Ale most bezpečnostních programů stále závisí na lidských procesech, které nemohou fungovat na rychlosti AI. Týmy by se měly připravit dvěma způsoby. Za prvé, postavit silnější runtime obrany, které mohou detekovat, blokovat a izolovat útoky v produkci, zatímco zranitelnosti jsou opravovány. To dává organizacím vzduchový kryt. Za druhé, použít AI a automatizaci pro psaní bezpečnějšího kódu zpočátku — s lepšími designy, testováním, kontrolou a ověřením. Jinak vytváříme riziko rychleji, než jsme schopni ho spravovat.

Pokud byste radil modernímu Security Operations Center (SOC) leaderovi dnes, jaké jsou první konkrétní kroky, které by měl podniknout, aby uzavřel tuto viditelnostní mezeru, než povede k重大nímu porušení?

Za prvé, přijměte, že perimetrová telemetrie sama o sobě je nedostatečná pro moderní aplikaci zabezpečení. Ve skutečnosti je nemožné vidět nebo zastavit mnoho aplikací a API útoků na perimetru. SOC potřebuje viditelnost uvnitř běžících aplikací, ne pouze infrastruktury, která je hostí. Za druhé, priorizujte runtime důkazy nad teoretickými nálezy. Zaměřte se na zranitelnosti, které jsou v aktivním kódu, identifikujte aktivní útočné cesty a vystavené služby, které skutečně fungují v produkci. Nakonec sjednoťte aplikaci zabezpečení a detekční inženýrství. Budoucí SOC nemůže považovat aplikace za neprůhledné černé skříňky. Aplikace jsou nyní primární útočnou plochou a potřebují první třídou viditelnost během runtime.

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