Jeff Williams, Oprichter van OWASP en Oprichter & CTO van Contrast Security – Interview Serie

Jeff Williams, Oprichter van OWASP en Oprichter & CTO van Contrast Security, wordt algemeen beschouwd als een van de meest invloedrijke figuren in de moderne toepassingsbeveiliging. In de afgelopen decennia heeft hij geholpen bij het vormgeven van de manier waarop organisaties secure softwareontwikkeling, kwetsbaarheidsbeheer en runtime-toepassingsbeveiliging benaderen. Williams speelde een centrale rol bij het opbouwen van OWASP van een kleine vrijwilligersinitiatief tot een wereldwijd erkende non-profitbeveiligingsstichting, met bijdragen aan baanbrekende projecten zoals de OWASP Top Ten, WebGoat, ESAPI, ASVS en de XSS Prevention Cheat Sheet. Voordat hij Contrast Security in 2014 oprichtte, richtte hij ook Aspect Security op, een van de eerste bedrijven die zich uitsluitend richtte op toepassingsbeveiligingsconsulting, -training, -penetratietesten en -beveiligingspraktijken voor ondernemingen.

OWASP is een non-profitstichting die zich richt op het verbeteren van de softwarebeveiliging door middel van open-sourceprojecten, wereldwijde gemeenschaps samenwerking, onderwijs en industrienormen. Opgericht in 2001, is de organisatie uitgegroeid tot een van de belangrijkste autoriteiten op het gebied van toepassingsbeveiliging, met honderden lokale afdelingen, duizenden bijdragers en breed geaccepteerde bronnen die worden gebruikt door ontwikkelaars, beveiligingsprofessionals, ondernemingen en overheden wereldwijd. OWASP is het meest bekend van projecten zoals de OWASP Top Ten, die de meest kritieke webtoepassingsbeveiligingsrisico’s identificeert, naast talloze beveiligingskaders, testtools, documentatieprojecten en trainingsinitiatieven. De organisatie werkt met een vendor-neutrale filosofie, waardoor de educatieve bronnen en beveiligingsrichtlijnen gratis toegankelijk zijn voor de wereldwijde technologiegemeenschap.

Contrast Security is een toepassingsbeveiligingsbedrijf dat zich richt op het beschermen van software vanuit de uitvoerende toepassing zelf, in plaats van te vertrouwen op externe scans. Het platform van het bedrijf gebruikt runtime-instrumentatie technologie om real-time zicht te bieden in kwetsbaarheden, aanvallen, API’s, open-source afhankelijkheden en toepassingsgedrag in zowel ontwikkelings- als productieomgevingen. De aanbod omvat gebieden zoals Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) en software-samenstellinganalyse. Contrast Security heeft zich gepositioneerd rond het integreren van beveiliging rechtstreeks in moderne DevSecOps-workflows, waardoor ontwikkelaars, AppSec-teams en beveiligingsoperatieteams kwetsbaarheden sneller kunnen identificeren en verhelpen, terwijl ze toch snelle softwareleveringscycli kunnen behouden.

Na het helpen vormgeven van de moderne toepassingsbeveiliging door uw werk met het Open Web Application Security Project (OWASP), wat was de kloof in de industrie die u ertoe bracht Contrast Security op te richten, en hoe heeft die oorspronkelijke these zich gehouden nu beveiligingsuitdagingen zijn geëvolueerd?

De industrie verzoop in theoretische statische bevindingen en kon zich niet concentreren op de problemen die echt belangrijk zijn. Beveiligingsteams hadden scanners die enorme achterstanden genereerden zonder te weten welke kwetsbaarheden bereikbaar, uitvoerbaar of aangevallen waren in productie. We richtten Contrast op op een eenvoudig idee: beveiligingsbeslissingen moeten komen van het direct observeren van daadwerkelijk uitgevoerde toepassingen, niet van het raden van buitenaf.

Uiteindelijk hoop ik dat de industrie vordert tot het punt waarop we van de hamsterwieltjes van het vinden van problemen, het oplossen ervan en het vinden van meer voor altijd afkomen. Ik hoop dat we kunnen beginnen met het creëren van software die een sterke beveiligingsarchitectuur heeft en een echt argument heeft dat het de juiste verdedigingen heeft voor de verwachte bedreigingen. De combinatie van runtime-beveiliging en AI heeft het potentieel, maar we zijn jaren verwijderd.

U heeft de opkomst van “Mythos-niveau kwetsbaarheden” beschreven. Wat definieert deze nieuwe klasse van risico’s, en waarom zijn ze zo moeilijk voor conventionele beveiligingstools om te detecteren?

Mythos-niveau kwetsbaarheden zijn fouten die ontstaan uit de complexiteit van moderne software-stacks. De interactie tussen framework-gedrag, afhankelijkheden en architectuurpatronen is zo complex dat ontwikkelaars ze vaak niet volledig begrijpen. Conventionele tools zijn nog steeds geoptimaliseerd voor relatief eenvoudige bekende patronen en waarneembare gebeurtenissen. Mythos-stijl kwetsbaarheden vereisen vaak een dieper begrip van toepassingsgedrag, uitvoeringsstroom en runtime-context.

Waarom ontbreken hele categorieën van kwetsbaarheden om alarmen te genereren in moderne Security Operations Center (SOC) omgevingen, en wat onthult dit over hoe beveiligingsteams momenteel risico’s meten?

De meeste SOC’s zijn gebouwd rond waarneembare gebeurtenissen: logs, handtekeningen, netwerkverkeer, eindpuntactiviteit. Maar veel toepassingslaag-aanvallen produceren nooit significante signalen in deze systemen. De ontwikkelaar wist niet dat er een kwetsbaarheid was en voegde geen logging toe die een exploit zou onthullen. Dus zijn de meeste toepassingsexploits volledig onzichtbaar in logs. SOC-teams kunnen alleen reageren op wat ze kunnen zien. Dus naarmate de toepassing en API-laag steeds belangrijker wordt, is het cruciaal om ervoor te zorgen dat we deze instrumenteren met beveiligingssensoren die kunnen detecteren en abnormaal gedrag melden.

Moderne toepassingsarchitecturen zoals microservices, API’s en serverless-systemen zijn snel geëvolueerd. Waar zijn deze architectuur uit het lood geslagen met de huidige detectie-gebaseerde beveiligingsbenaderingen?

Deze architectuur heeft het oude perimetermodel aan stukken geslagen. Verzoeken gaan nu door tientallen services, ephemere functies, API’s, wachtrijen en derde partij afhankelijkheden voordat een transactie is voltooid. De meeste detectiesystemen zien nog steeds fragmenten in plaats van het volledige uitvoeringspad. Ze kunnen pakketten of logs inspecteren, maar ze kunnen niet begrijpen wat de bedoeling is, gegevensstroom of of gevaarlijke code daadwerkelijk is uitgevoerd. Beveiliging gaat over context, dus we moeten een model, een digitale tweeling, van onze toepassingsinfrastructuur bouwen die ons (of AI-agents) in staat stelt om te redeneren over wat we zien gebeuren.

De OWASP Top Ten benadrukt nog steeds problemen zoals onveilig ontwerp en kwetsbare componenten. Waarom blijven deze risico’s bestaan ondanks brede bewustwording en tooling?

Bewustwording lost geen incentives of complexiteit op. De meeste organisaties meten nog steeds succes door scanvolume, ticketafsluiting of compliance-controlelijsten in plaats van daadwerkelijke blootstellingreductie.

Tegelijkertijd zijn software-toeleveringsketens enorm in omvang toegenomen. Ontwikkelaars bouwen toepassingen van duizenden componenten die ze niet zelf hebben geschreven en zeker niet hebben geëvalueerd voor beveiliging. Beveiligingsteams zijn overweldigd door het proberen om theoretische risico’s te triëren en kunnen zich niet concentreren op de 1-2% die echt belangrijk zijn. Zonder runtime-bewijs breekt priorisatie af. En met de opkomst van krachtige AI-modellen en -hulpmiddelen, neemt het volume exponentieel toe.

Hoe moeten organisaties hun afhankelijkheid van logs en alarmen heroverwegen als sommige van de meest kritieke kwetsbaarheden geen waarneembare signalen achterlaten?

Logs zijn bewijs van wat toepassingen kiezen om te melden, niet noodzakelijkerwijs bewijs van wat er echt gebeurt. Dat is een gevaarlijk onderscheid. Organisaties moeten verschuiven van indirecte observatie naar directe observatie. In plaats van te hopen dat een exploit een detecteerbaar artifact creëert, moeten beveiligingssystemen kwetsbaar gedrag en exploit-gedrag identificeren op runtime. Als gevaarlijke code wordt uitgevoerd, moet het systeem het onmiddellijk weten — of er nu een logboekingang bestaat of niet.

U heeft runtime-zichtbaarheid bepleit als oplossing. Wat ziet echte runtime-zichtbaarheid er in de praktijk uit, en hoe verandert dit de manier waarop beveiligingsteams dagelijks opereren?

Echte runtime-zichtbaarheid betekent dat men begrijpt wat de toepassing daadwerkelijk doet in productie: welke routes zijn blootgesteld, welke bibliotheken zijn actief, waar gevoelige gegevens stromen, welke code wordt uitgevoerd en of een aanval kwetsbare functionaliteit bereikt. Operationeel verandert dit beveiliging van een reactieve jacht in een precisiediscipline. Teams stoppen met het najagen van enorme kwetsbaarheidsachterstanden en beginnen met het focussen op het kleine percentage van blootstellingen dat bereikbaar, kritiek en actief wordt aangevallen. Dit verbetert dramatisch het signaal-ruisverhouding en de reactiesnelheid. Gemiddeld zijn slechts 38% van de open-source bibliotheken die in een toepassing zijn verpakt, daadwerkelijk in het geheugen geladen en uitgevoerd. En niet alle code in deze subset wordt gebruikt. Dus een eenvoudige zaak die runtime-beveiliging mogelijk maakt, is een focus op de code die daadwerkelijk wordt uitgevoerd, en niet alle ongebruikte bibliotheken en functies die samen met een toepassing komen.

Hoe vergelijkt instrumentatie-gebaseerde beveiliging met traditionele benaderingen zoals SAST, DAST of perimeter-monitoring in termen van effectiviteit en schaalbaarheid?

Traditionele tools concluderen risico’s van buitenaf. Instrumentatie observeert de realiteit door de daadwerkelijke code te observeren terwijl deze wordt uitgevoerd. Instrumentatie kan daadwerkelijke uitvoeringspaden, framework-gedrag, authenticatiecontext, gegevensstroom en exploit-succes in real-time zien. Het elimineert enorme categorieën van valse positieven en onthult kwetsbaarheden die perimeter-tools volledig missen.
Op schaal wordt die precisie kritiek. Organisaties kunnen miljoenen theoretische bevindingen niet langer handmatig triëren. Runtime-bewijs wordt de enige duurzame filter. Runtime werkt in real-time, dus het is een betere match voor ontwikkelings- en CI/CD-pijplijnen dan scannen en triëren. En runtime is continu, dus u bent niet beperkt tot een momentopname van beveiliging.

Als AI-systemen en autonome toepassingen meer gebruikelijk worden, worden deze onzichtbare kwetsbaarheden gevaarlijker, en hoe moeten teams zich hierop voorbereiden?

AI maakt onzichtbare kwetsbaarheden veel gevaarlijker omdat het zowel de ontwikkeling van software als de exploitatie van zwakheden versnelt. Maar de meeste beveiligingsprogramma’s vertrouwen nog steeds op mens-in-de-lus-processen die niet kunnen opereren op AI-snelheid. Teams moeten zich op twee manieren voorbereiden. Ten eerste moeten ze sterke runtime-verdedigingen opbouwen die aanvallen in productie kunnen detecteren, blokkeren en bevatten terwijl kwetsbaarheden worden verholpen. Dat geeft organisaties luchtdekking. Ten tweede moeten ze AI en automatisering gebruiken om meer beveiligde code te schrijven — met beter ontwerp, testen, beoordelen en verifiëren. Anders creëren we risico’s sneller dan we ze kunnen beheren.

Als u een moderne Security Operations Center (SOC) leider vandaag zou adviseren, wat zijn de eerste concrete stappen die ze moeten nemen om deze zichtbaarheidskloof te dichten voordat het leidt tot een grote inbreuk?

Ten eerste moet men accepteren dat perimeter-telemetrie alleen onvoldoende is voor moderne toepassingsbeveiliging. Feitelijk is het onmogelijk om veel toepassings- en API-aanvallen te zien of te stoppen op het perimeter. De SOC heeft zichtbaarheid nodig binnen uitgevoerde toepassingen, niet alleen de infrastructuur die ze host. Ten tweede moet men runtime-bewijs prioriteren boven theoretische bevindingen. Focus op kwetsbaarheden die in actieve code zitten, identificeer actieve aanvalsroutes en blootgestelde services die daadwerkelijk in productie worden uitgevoerd. Ten slotte moet men toepassingsbeveiliging en detectie-engineering verenigen. De toekomstige SOC kan toepassingen niet langer behandelen als ondoorzichtige zwarte dozen. Toepassingen zijn nu het primaire aanvalsoppervlak, en ze hebben first-class zichtbaarheid nodig op runtime.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen OWASP of Contrast Security bezoeken.