Jeff Williams, grundare av OWASP och grundare och CTO av Contrast Security – Intervjuer

Jeff Williams, grundare av OWASP och grundare och CTO av Contrast Security, anses allmänt vara en av de mest inflytelserika personerna inom modern applikationssäkerhet. Under de senaste decennierna har han hjälpt till att forma hur organisationer närmar sig säker programvaruutveckling, sårbarhets hantering och skydd av applikationer i realtid. Williams spelade en central roll i att bygga upp OWASP från en liten volontärinitiativ till en globalt erkänd ideell säkerhetsstiftelse, och bidrog till banbrytande projekt som OWASP Top Ten, WebGoat, ESAPI, ASVS och XSS Prevention Cheat Sheet. Innan han grundade Contrast Security 2014, grundade han också Aspect Security, ett av de tidigaste företagen som enbart fokuserade på applikationssäkerhets konsulttjänster, utbildning, penetrationstestning och säkra utvecklingspraxis för företag.

OWASP är en ideell stiftelse som fokuserar på att förbättra programvarusäkerheten genom öppen källkod, global samarbete, utbildning och branschstandarder. Grundat 2001, har organisationen blivit en av de viktigaste myndigheterna inom applikationssäkerhet, med hundratals lokala kapitel, tusentals bidragsgivare och allmänt antagna resurser som används av utvecklare, säkerhetsproffs, företag och regeringar över hela världen. OWASP är mest känt för projekt som OWASP Top Ten, som identifierar de mest kritiska webbapplikationssäkerhetsriskerna, samt ett antal säkerhetsramverk, testverktyg, dokumentationsprojekt och utbildningsinitiativ. Organisationen drivs med en leverantörsneutral filosofi, vilket gör att dess utbildningsresurser och säkerhetsvägledning är fritt tillgängliga för den globala teknikgemenskapen.

Contrast Security är ett företag som fokuserar på applikationssäkerhet, som skyddar programvara från insidan av den körande applikationen snarare än att enbart förlita sig på externa skanningsverktyg. Företagets plattform använder sig av teknik för instrumentering i realtid för att ge direkt insyn i sårbarheter, attacker, API:er, öppen källkod och applikationsbeteende över utvecklings- och produktionsmiljöer. Deras erbjudanden omfattar områden som interaktiv applikationssäkerhetstestning (IAST), applikationsupptäckt och respons (ADR), skydd av applikationer i realtid (RASP) och analys av programvarukomposition. Contrast Security har positionerat sig kring att integrera säkerhet direkt i moderna DevSecOps-arbetsflöden, vilket möjliggör för utvecklare, AppSec-team och säkerhetsoperationsteam att identifiera och åtgärda sårbarheter snabbare samtidigt som de upprätthåller snabba programvarudistributionscykler.

Efter att ha bidragit till att forma modern applikationssäkerhet genom ditt arbete med Open Web Application Security Project (OWASP), vad var det som ledde dig att grunda Contrast Security, och hur har den ursprungliga tesen hållit sig när säkerhetsutmaningarna har utvecklats?

Branschen drunknade i teoretiska, statiska fynd och kunde inte fokusera på de problem som faktiskt betyder något. Säkerhetsteam hade skannrar som genererade enorma köer utan att veta vilka sårbarheter som var tillgängliga, utnyttjbara eller under attack i produktion. Vi grundade Contrast på en enkel idé: säkerhetsbeslut bör komma från direkt observation av körande applikationer, inte från gissningar utifrån.

Till slut hoppas jag att branschen utvecklas till en punkt där vi kan sluta med att hitta problem, fixa dem och hitta fler för alltid. Jag hoppas att vi kan börja skapa programvara som har en stark säkerhetsarkitektur och ett verkligt argument för att den har rätt försvar för de förväntade hoten. Kombinationen av säkerhet i realtid och AI har potentialen, men vi är fortfarande flera år bort.

Du har beskrivit uppkomsten av “Mythos-nivås sårbarheter”. Vad definierar denna nya klass av risk, och varför är de så svåra för konventionella säkerhetsverktyg att upptäcka?

Mythos-nivås sårbarheter är brister som uppstår från komplexiteten i moderna programvarustaplar. Interaktionen mellan ramverksbeteende, beroenden och arkitekturmönster är så komplex att utvecklare ofta inte fullständigt förstår den. Konventionella verktyg är fortfarande optimerade för relativt enkla kända mönster och observerbara händelser. Mythos-stil sårbarheter kräver ofta en djupare förståelse av applikationsbeteende, exekveringsflöde och sammanhang i realtid.

Varför misslyckas hela kategorier av sårbarheter med att generera larm i moderna Security Operations Center (SOC)-miljöer, och vad avslöjar detta om hur säkerhetsteam mäter risk idag?

De flesta SOC:er byggs kring observerbara händelser: loggar, signaturer, nätverkstrafik, slutpunktsaktivitet. Men många applikationslagerattacker producerar aldrig meningsfulla signaler i dessa system. Utvecklaren visste inte att det fanns en sårbarhet och lade inte till någon loggningsinformation som skulle avslöja en exploatering. Så de flesta applikationsattacker är helt osynliga i loggar. SOC-team kan bara svara på vad de kan se. Så när applikations- och API-lagret blir allt viktigare, är det kritiskt att se till att vi instrumenterar det med säkerhetssensorer som kan upptäcka och rapportera avvikande beteende.

Modern applikationsarkitektur som mikrotjänster, API:er och serverless-system har utvecklats snabbt. Var är dessa arkitekturer mer avancerade än nuvarande detektionsbaserade säkerhetsansatser?

Dessa arkitekturer har krossat den gamla perimetermodellen. Förfrågningar korsar nu dussintals tjänster, efemära funktioner, API:er, köer och tredjepartsberoenden innan de slutför en transaktion. De flesta detektionssystem ser fortfarande fragment i stället för den fullständiga exekveringsvägen. De kan inspektera paket eller loggar, men de kan inte förstå avsikt, dataflöde eller om farlig kod faktiskt exekverades. Säkerhet handlar om sammanhang, så vi behöver bygga en modell, en digital tvilling, av vår applikationsinfrastruktur som möjliggör för oss (eller AI-agenter) att resonera om vad vi ser hända.

OWASP Top Ten fortsätter att belysa frågor som osäker design och sårbara komponenter. Varför kvarstår dessa risker trots allmän medvetenhet och verktyg?

Medvetenhet åtgärdar inte incitament eller komplexitet. De flesta organisationer mäter fortfarande framgång genom skanningsvolym, biljettstängning eller compliance-kontrollister snarare än faktisk exponeringsreduktion.

Samtidigt exploderade programvaruleverantörskedjor i storlek. Utvecklare sätter samman applikationer från tusentals komponenter som de inte skrev och definitivt inte utvärderade för säkerhet. Säkerhetsteam är överväldigade av att triera teoretiska risker och kan inte fokusera på de 1-2% som faktiskt betyder något. Utan bevis från realtid, bryter prioritering ner. Och med uppkomsten av kraftfulla AI-modeller och harness, ökar volymen exponentiellt.

Hur bör organisationer omvärdera sin tillit till loggar och larm när vissa av de mest kritiska sårbarheterna inte lämnar några observerbara signaler?

Loggar är bevis för vad applikationer väljer att rapportera, inte nödvändigtvis bevis för vad som faktiskt hände. Det är en farlig distinktion. Organisationer behöver skifta från indirekt observation till direkt observation. I stället för att hoppas att en exploatering skapar en upptäckbar artefakt, bör säkerhetssystem identifiera det sårbara beteendet och exploateringsbeteendet i realtid. Om farlig kod exekveras, bör systemet veta omedelbart — oavsett om en loggenhet finns eller inte.

Du har förespråkat runtime-synlighet som en lösning. Vad ser sann runtime-synlighet ut som i praktiken, och hur ändrar det sättet som säkerhetsteam opererar på en daglig basis?

Sann runtime-synlighet innebär att förstå vad applikationen faktiskt gör i produktion: vilka rutter som exponeras, vilka bibliotek som är aktiva, var känsliga data flödar, vilken kod exekveras och om en attack nådde sårbar funktion. Operativt ändrar det säkerhet från en reaktiv jaktövning till en precisionsdisciplin. Team slutar jaga enorma sårbarhetsköer och börjar fokusera på den lilla procenten av exponeringar som är tillgängliga, kritiska och aktivt riktade. Det förbättrar dramatiskt signal-till-brus-förhållandet och svarstiden. I genomsnitt är endast 38% av öppen källkods bibliotek som paketeras i en applikation faktiskt laddade in i minnet och exekverade. Och inte all kod i denna undermängd används. Så en enkel sak som runtime-säkerhet möjliggör är en fokusering på den kod som faktiskt körs, och inte alla outnyttjade bibliotek och funktioner som följer med en applikation.

Hur jämför instrumenteringsbaserad säkerhet med traditionella tillvägagångssätt som SAST, DAST eller perimeterövervakning när det gäller effektivitet och skalbarhet?

Traditionella verktyg antar risk från utsidan. Instrumentering observerar verkligheten genom att observera den faktiska koden när den körs. Instrumentering kan se faktiska exekveringsvägar, ramverksbeteende, autentiseringskontext, dataflöde och exploateringsframgång i realtid. Det eliminerar stora kategorier av falska positiva och exponerar sårbarheter som perimeterverktyg helt missar.
På skalnivå blir precisionen kritisk. Organisationer kan inte manuellt triera miljontals teoretiska fynd längre. Bevis från realtid blir det enda hållbara filtret. Runtime fungerar i realtid, så det är en bättre match för utvecklings- och CI/CD-pipelines än skanning och triage. Och runtime är kontinuerlig, så du är inte begränsad till en ögonblicksbild av säkerhet.

När AI-system och autonoma applikationer blir allt vanligare, blir dessa osynliga sårbarheter farligare, och hur bör team förbereda sig?

AI gör osynliga sårbarheter farligare eftersom det accelererar båda sidor av problemet. Utvecklare genererar programvara snabbare, och angripare hittar och utnyttjar svagheter snabbare. Men de flesta säkerhetsprogram beror fortfarande på mänskliga processer som inte kan fungera i AI-hastighet. Team bör förbereda sig på två sätt. Först, bygg starkare runtime-försvar som kan upptäcka, blockera och innesluta attacker i produktion medan sårbarheter fixas. Det ger organisationer lufttäcke. Andra, använd AI och automatisering för att skriva mer säker kod från början — med bättre design, testning, granskning och verifikation. Annars skapar vi risk snabbare än vi kan hantera den.

Om du skulle ge råd till en modern Security Operations Center (SOC)-ledare idag, vad är de första konkreta stegen de bör ta för att stänga detta synlighetsgap innan det leder till ett stort dataintrång?

Först, acceptera att perimeter-telemetri ensam är otillräcklig för modern applikationssäkerhet. I själva verket är det omöjligt att se eller stoppa många applikations- och API-attacker vid perimeter. SOC behöver synlighet inuti körande applikationer, inte bara infrastrukturen som värdar dem. Andra, prioritera bevis från realtid över teoretiska fynd. Fokusera på sårbarheter som är i aktiv kod, identifiera aktiva attackvägar och exponerade tjänster som faktiskt exekveras i produktion. Slutligen, förena applikationssäkerhet och upptäcktsengineering. Den framtida SOC kan inte behandla applikationer som opaka svarta lådor längre. Applikationer är nu den primära attackytan, och de behöver förstklassig synlighet i realtid.

Tack för den utmärkta intervjun, läsare som vill lära sig mer kan besöka OWASP eller Contrast Security.