Jeff Williams, grundlægger af OWASP og grundlægger & CTO af Contrast Security – Interviewserie

Jeff Williams, grundlægger af OWASP og grundlægger & CTO af Contrast Security, regnes bredt for at være en af de mest indflydelsesrige figurer i moderne applikationssikkerhed. Over de seneste årtier har han hjulpet med at forme, hvordan organisationer tilgår sikker softwareudvikling, sårbarhedsstyring og runtime-applikationsbeskyttelse. Williams spillede en central rol i opbygningen af OWASP fra en lille frivilliginitiativ til en globalt anerkendt nonprofit-sikkerhedsstiftelse, og bidrog til banebrydende projekter som OWASP Top Ten, WebGoat, ESAPI, ASVS og XSS Prevention Cheat Sheet. Før han grundlagde Contrast Security i 2014, grundlagde han også Aspect Security, et af de første firmaer, der udelukkende var dedikeret til applikationssikkerhedsrådgivning, uddannelse, penetrationstest og sikker udviklingspraksis for virksomheder.

OWASP er en nonprofit-stiftelse, der fokuserer på at forbedre software-sikkerheden gennem open-source-projekter, global samarbejde, uddannelse og branchestandarder. Stiftelsen blev grundlagt i 2001 og er blevet en af de vigtigste myndigheder i applikationssikkerhed, med hundredvis af lokale afdelinger, tusindvis af bidragsydere og bredt accepterede ressourcer, der bruges af udviklere, sikkerhedseksperter, virksomheder og regeringer verden over. OWASP er bedst kendt for projekter som OWASP Top Ten, der identificerer de mest kritiske web-applikations-sikkerhedsrisici, samt talrige sikkerhedsrammer, testværktøjer, dokumentationsprojekter og uddannelsesinitiativer. Stiftelsen opererer med en vendor-neutral filosofi, der gør det muligt for den at tilbyde uddannelsesressourcer og sikkerhedsvejledning frit tilgængelig for den globale teknologiske fællesskab.

Contrast Security er et applikationssikkerhedsfirma, der fokuserer på at beskytte software fra indenfor den kørende applikation selv, snarere end at kun stole på eksterne scanningværktøjer. Firmaets platform bruger runtime-instrumenteringsteknologi til at give realtids indsigt i sårbarheder, angreb, API’er, open-source-afhængigheder og applikationsadfærd på tværs af udviklings- og produktionsmiljøer. Dets tilbud omfatter områder som Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) og software-sammensætningsanalyse. Contrast Security har positioneret sig omkring integration af sikkerhed direkte i moderne DevSecOps-workflows, der giver udviklere, AppSec-teams og sikkerhedsoperationsteams mulighed for at identificere og afhjælpe sårbarheder hurtigere, samtidig med at de opretholder hurtige softwareleveringscykler.

Efter at have hjulpet med at forme moderne applikationssikkerhed gennem dit arbejde med Open Web Application Security Project (OWASP), hvilket hul i branchen førte til, at du grundlagde Contrast Security, og hvordan har den oprindelige tese holdt sig, efterhånden som sikkerhedsudfordringerne har udviklet sig?

Branchen var ved at drukne i teoretiske statiske fund og kunne ikke fokusere på de problemer, der virkelig betød noget. Sikkerhedsteams havde scannere, der genererede massive tilbageholdenheder uden at vide, hvilke sårbarheder der var tilgængelige, udnyttelige eller under angreb i produktion. Vi grundlagde Contrast på en simpel idé: sikkerhedsbeslutninger skal komme fra direkte observation af kørende applikationer, ikke fra gætteri udefra.

Til sidst håber jeg, at branchen udvikler sig til et punkt, hvor vi kan komme af hamsterhjulet med at finde problemer, løse dem og finde flere for evigt. Jeg er optimistisk om, at vi kan begynde at skabe software, der har en stærk sikkerhedsarkitektur og en reel argumentation for, at den har de rigtige forsvar mod de forventede trusler. Kombinationen af runtime-sikkerhed og AI har potentialet, men vi er år væk.

Du har beskrevet opkomsten af “Mythos-niveau-sårbarheder.” Hvad definerer denne nye klasse af risici, og hvorfor er de så svære for konventionelle sikkerhedsværktøjer at opdage?

Mythos-niveau-sårbarheder er fejl, der opstår fra kompleksiteten i moderne software-stacks. Interaktionen mellem framework-adfærd, afhængigheder og arkitekturmønstre er så kompleks, at udviklere ofte ikke fuldt ud forstår det. Konventionelle værktøjer er stadig optimeret til relativt simple kendte mønstre og observerbare begivenheder. Mythos-stil-sårbarheder kræver ofte en dybere forståelse af applikationsadfærd, eksekveringsflow og runtime-kontekst.

Hvorfor mislykkes hele kategorier af sårbarheder for at generere alarmsignaler i moderne Security Operations Center (SOC)-miljøer, og hvad afslører det om, hvordan sikkerhedsteams måler risici i øjeblikket?

De fleste SOC’er er bygget omkring observerbare begivenheder: logs, signaturer, netværkstrafik, endpoint-aktivitet. Men mange applikationslag-angreb producerer aldrig meningsfulde signaler i disse systemer. Udvikleren vidste ikke, at der var en sårbarhed, og tilføjede ikke nogen logging, der ville afsløre et udnyttelse. Derfor er de fleste applikationsudnyttelser fuldstændig usynlige i logs. SOC-teams kan kun reagere på, hvad de kan se. Derfor er det kritisk, at vi instrumenterer applikationslaget med sikkerhedssensorer, der kan opdage og rapportere om afvigende adfærd.

Moderne applikationsarkitekturer som mikrotjenester, API’er og serverless-systemer er udviklet hurtigt. Hvor er disse arkitekturer overhåndtaget nuværende detectionsbaserede sikkerhedsapproacher?

Disse arkitekturer har ødelagt den gamle perimeter-model. Anmodninger traverserer nu dusinvis af tjenester, efemære funktioner, API’er, køer og tredjepartsafhængigheder, før de afslutter en transaktion. De fleste detectionsystemer ser stadig kun fragmenter i stedet for den fulde eksekveringsvej. De kan inspicere pakker eller logs, men de kan ikke forstå intention, dataflow eller om farligt kode faktisk blev eksekveret. Sikkerhed handler om kontekst, så vi har brug for at bygge en model, en digital tvilling, af vores applikationsinfrastruktur, der giver os (eller AI-agenter) mulighed for at resonere om, hvad vi ser ske.

OWASP Top Ten fortsætter med at fremhæve problemer som usikker design og sårbare komponenter. Hvorfor består disse risici, på trods af bred bevidsthed og værktøjer?

Bevidsthed fikser ikke incitamenter eller kompleksitet. De fleste organisationer måler stadig succes ud fra scanvolumen, billetløsning eller overholdelse af checkliste, snarere end reel eksponeringsreduktion.

Samtidig eksploderede softwareforsyningskæder i størrelse. Udviklere samler applikationer fra tusindvis af komponenter, de ikke selv skrev, og bestemt ikke evaluerede for sikkerhed. Sikkerhedsteams er overvældede af at triage teoretiske risici og kan ikke fokusere på de 1-2%, der virkelig betyder noget. Uden runtime-bevis kan prioritering bryde sammen. Og med opkomsten af kraftfulde AI-modeller og -harness, øges volumenet eksponentielt.

Hvordan bør organisationer omtilpasse deres afhængighed af logs og alarmsignaler, når nogle af de mest kritiske sårbarheder ikke producerer observerbare signaler?

Logs er bevis for, hvad applikationer vælger at rapportere, ikke nødvendigvis bevis for, hvad der faktisk sker. Det er en farlig distinktion. Organisationer har brug for at skifte fra indirekte observation til direkte observation. I stedet for at håbe, at et udnyttelse skaber et detecterbart artifact, skal sikkerhedssystemer identificere den sårbare adfærd og udnyttelsesadfærden på runtime. Hvis farligt kode eksekveres, skal systemet vide det med det samme — uanset om en log-indtastning findes eller ej.

Du har advokeret for runtime-synlighed som en løsning. Hvad ser sand runtime-synlighed ud som i praksis, og hvordan ændrer det, hvordan sikkerhedsteams opererer på en daglig basis?

Sand runtime-synlighed indebærer at forstå, hvad applikationen faktisk gør i produktion: hvilke ruter er eksponeret, hvilke biblioteker er aktive, hvor følsomme data flyder, hvilken kode blev eksekveret, og om et angreb nåede sårbare funktioner. Operationelt ændrer det sikkerhed fra en reaktiv jagtøvelse til en præcis disciplin. Teams stopper med at jagte massive sårbarheds-tilbageholdenheder og fokuserer i stedet på den lille procentdel af eksponeringer, der er tilgængelige, kritiske og aktivt målrettede. Det forbedrer dramatisk signal-til-støj-forholdet og respons-hastigheden. I gennemsnit er kun 38% af open source-biblioteker, der er pakket i en applikation, faktisk indlæst i hukommelse og eksekveret. Og ikke al kode i denne undermængde bliver brugt. Så en enkel ting, som runtime-sikkerhed giver mulighed for, er at fokusere på den kode, der faktisk kører, og ikke alle de ubrugte biblioteker og funktioner, der følger med en applikation.

Hvordan sammenligner instrumentation-baseret sikkerhed med traditionelle tilgange som SAST, DAST eller perimeter-overvågning i forhold til effektivitet og skalerbarhed?

Traditionelle værktøjer slutninger risiko fra udenfor. Instrumentation observerer virkeligheden ved at observere den faktiske kode, mens den kører. Instrumentation kan se faktiske eksekveringsveje, framework-adfærd, autentiseringskontekst, dataflow og udnyttelses-succes i realtid. Det eliminerer enorme kategorier af falske positiver og afslører sårbarheder, som perimeter-værktøjer fuldstændig mangler.
På skala bliver præcision kritisk. Organisationer kan ikke længere manuelt triage millioner af teoretiske fund. Runtime-bevis bliver det eneste bæredygtige filter. Runtime fungerer i realtid, så det er en bedre match for udviklings- og CI/CD-pipelines end scanning og triage. Og runtime er kontinuerligt, så du er ikke begrænset til et snapshot-punkt-i-tid-syn på sikkerhed.

Som AI-systemer og autonome applikationer bliver mere udbredte, bliver disse usynlige sårbarheder mere farlige, og hvordan bør teams forberede sig?

AI gør usynlige sårbarheder mere farlige, fordi det accelererer begge sider af problemet. Udviklere genererer software hurtigere, og angribere finder og udnytter svagheder hurtigere. Men de fleste sikkerhedsprogrammer afhænger stadig af menneske-i-løkken-processer, der ikke kan fungere med AI-hastighed. Teams bør forberede sig på to måder. Først bygge stærkere runtime-forsvar, der kan opdage, blokere og indeholde angreb i produktion, mens sårbarheder bliver løst. Det giver organisationer luftbeskyttelse. Anden, brug AI og automatisering til at skrive mere sikker kode fra starten — med bedre design, test, gennemgang og verificering. Ellers skaber vi kun risiko hurtigere, end vi kan håndtere det.

Hvis du skulle rådgive en moderne Security Operations Center (SOC)-leder i dag, hvilke konkrete skridt bør de tage for at lukke dette synligheds-hul, før det fører til et større dataangreb?

Først accepter, at perimeter-telemetri alene er utilstrækkeligt for moderne applikationssikkerhed. I virkeligheden er det umuligt at se eller stoppe mange applikations- og API-angreb ved perimeteren. SOC’en har brug for synlighed inde i kørende applikationer, ikke kun den infrastruktur, der vært dem. Anden, prioriter runtime-bevis over teoretiske fund. Fokuser på sårbarheder, der er i aktiv kode, identificer aktive angrebsveje og eksponerede tjenester, der faktisk eksekveres i produktion. Til sidst, samlet applikationssikkerhed og detections-ingeniørarbejde. Fremtidens SOC kan ikke behandle applikationer som uigennemsigtige sorte kasser længere. Applikationer er nu det primære angrebs-overflade, og de har brug for førsteklasses synlighed på runtime.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge OWASP eller Contrast Security.