Jeff Williams, grunnlegger av OWASP og grunnlegger og CTO av Contrast Security – Intervju-serie

Jeff Williams, grunnlegger av OWASP og grunnlegger og CTO av Contrast Security, regnes som en av de mest innflytelsesrike personene i moderne applikasjonssikkerhet. I løpet av de siste flere tiårene har han hjulpet til å forme hvordan organisasjoner nærmer seg sikker programvareutvikling, sårbarhetsstyring og runtime-applikasjonssikkerhet. Williams spilte en sentral rol i å bygge opp OWASP fra en liten frivillig initiativ til en globalt anerkjent non-profit sikkerhetsstiftelse, og bidro til banebrytende prosjekter som OWASP Top Ten, WebGoat, ESAPI, ASVS og XSS Prevention Cheat Sheet. Før han grunnla Contrast Security i 2014, grunnla han også Aspect Security, ett av de tidligste firmaene som var dedikert eksklusivt til applikasjonssikkerhetsrådgivning, opplæring, penetrerings_testing og sikker utviklingspraksis for bedrifter.

OWASP er en non-profit stiftelse som fokuserer på å forbedre programvaresikkerheten gjennom åpne prosjekter, globale samarbeidsprosjekter, utdanning og bransjestandarder. Grunnlagt i 2001, har organisasjonen blitt en av de viktigste myndighetene i applikasjonssikkerhet, med hundrevis av lokale avdelinger, tusenvis av bidragsytere og vidt aksepterte ressurser som brukes av utviklere, sikkerhetspersoner, bedrifter og myndigheter over hele verden. OWASP er best kjent for prosjekter som OWASP Top Ten, som identifiserer de mest kritiske web-applikasjonssikkerhetsrisiko, samt tallrike sikkerhetsrammer, testverktøy, dokumentasjonsprosjekter og opplæringsinitiativer. Organisasjonen opererer med en leverandør-nøytral filosofi, som gjør det mulig for dem å tilby gratis tilgjengelige utdanningsressurser og sikkerhetsveiledning til den globale teknologisamfunnet.

Contrast Security er et selskap som fokuserer på å beskytte programvare fra innenfor den kjørende applikasjonen selv, i stedet for å bare stole på eksterne skanningsverktøy. Selskapets plattform bruker runtime-instrumenteringsteknologi for å gi sanntidsinnsikt i sårbarheter, angrep, API-er, åpne kildekoder og applikasjonsatferd i både utviklings- og produksjonsmiljøer. Deres tilbud omfatter områder som Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) og programvare-sammensetningsanalyse. Contrast Security har posisjonert seg rundt å integrere sikkerhet direkte i moderne DevSecOps-arbeidsflyter, og muliggjør at utviklere, AppSec-team og sikkerhetsoperasjonsteam kan identifisere og rette opp sårbarheter raskere, samtidig som de opprettholder raske programvareleveringscykler.

Etter å ha hjulpet til å forme moderne applikasjonssikkerhet gjennom ditt arbeid med Open Web Application Security Project (OWASP), hva var det som førte til at du grunnla Contrast Security, og hvordan har den opprinnelige tesen holdt seg etter at sikkerhetsutfordringene har utviklet seg?

Bransjen druknet i teoretiske, statiske funn og var ikke i stand til å fokusere på de problemene som virkelig betyr noe. Sikkerhetsteam hadde skannere som genererte massive bakloger uten å vite hvilke sårbarheter som var tilgjengelige, utnyttbare eller under angrep i produksjon. Vi grunnla Contrast på en enkel idé: sikkerhetsbeslutninger bør komme fra direkte observasjon av kjørende applikasjoner, ikke fra å gjette fra utsiden.

Til slutt håper jeg at bransjen utvikler seg til et punkt der vi kan slutte å finne problemer, fikse dem og finne flere for alltid. Jeg er håpefull at vi kan begynne å lage programvare som har en sterk sikkerhetsarkitektur og en reel begrunnelse for at den har riktige forsvar mot forventede trusler. Kombinasjonen av runtime-sikkerhet og AI har potensialet, men vi er år unna.

Du har beskrevet oppkomsten av “Mythos-nivå sårbarheter.” Hva definerer denne nye klassen av risiko, og hvorfor er de så vanskelige for konvensjonelle sikkerhetsverktøy å oppdage?

Mythos-nivå sårbarheter er feil som oppstår fra kompleksiteten i moderne programvarestaker. Interaksjonen mellom rammeverksatferd, avhengigheter og arkitektoniske mønster er så kompleks at utviklere ofte ikke fullt ut forstår det. Konvensjonelle verktøy er fortsatt optimert for relativt enkle, kjente mønster og observerbare hendelser. Mythos-stil sårbarheter krever ofte en dypere forståelse av applikasjonsatferd, kjørefløt og runtime-kontekst.

Hvorfor feiler hele kategorier av sårbarheter i å generere varsler i moderne Sikkerhetsoperasjons-sentere (SOC), og hva avslører dette om hvordan sikkerhetsteam måler risiko i dag?

De fleste SOC-er er bygget rundt observerbare hendelser: logger, signaturer, nettverkstrafikk, endpoint-aktivitet. Men mange applikasjonslag-angrep produserer aldri meningsfulle signaler i disse systemene. Utvikleren visste ikke at det var en sårbarhet og la ikke til noen logging som ville avsløre et angrep. Derfor er de fleste applikasjons-utnyttelser fullstendig usynlige i logger. SOC-team kan bare reagere på det de kan se. Derfor er det kritisk å sikre at vi instrumenterer applikasjonen med sikkerhetssensorer som kan oppdage og rapportere avvikende atferd.

Moderne applikasjonsarkitekturer som mikrotjenester, API-er og serverløse systemer har utviklet seg raskt. Hvor er disse arkitekturer foran nåværende deteksjonsbaserte sikkerhets tilnærmingene?

Disse arkitekturer har knust den gamle perimetre-modellen. Forespørsler går nå gjennom dusinvis av tjenester, efemere funksjoner, API-er, køer og tredjepartsavhengigheter før de fullfører en transaksjon. De fleste deteksjonssystemer ser fortsatt på fragmenter i stedet for hele kjørefløten. De kan inspisere pakker eller logger, men de kan ikke forstå intensjon, datafløt eller om farlig kode faktisk ble kjørt. Sikkerhet handler om kontekst, så vi må bygge en modell, en digital tvilling, av vår applikasjonsinfrastruktur som gjør det mulig for oss (eller AI-agenter) å resonnere om hva vi ser skje.

OWASP Top Ten fortsatt å highlighte problemer som usikker design og sårbare komponenter. Hvorfor består disse risikoene til tross for vidt utbredt bevissthet og verktøy?

Bevissthet fikser ikke incitamenter eller kompleksitet. De fleste organisasjoner måler fremgang ved skanningsvolum, billett-lukking eller compliance-kontrollister i stedet for faktisk eksponeringsreduksjon.

Samtidig har programvareforsyningskjedene eksplodert i størrelse. Utviklere monterer applikasjoner fra tusenvis av komponenter de ikke skrev og absolutt ikke evaluerte for sikkerhet. Sikkerhetsteam er overveldet av å triage teoretiske risiko og kan ikke fokusere på de 1-2% som virkelig betyr noe. Uten runtime-bevis, bryter prioritering ned. Og med oppkomsten av kraftige AI-modeller og harness, øker volumet eksponentielt.

Hvordan bør organisasjoner tenke om sin avhengighet av logger og varsler når noen av de mest kritiske sårbarhetene ikke produserer observerbare signaler?

Logger er bevis på hva applikasjoner velger å rapportere, ikke nødvendigvis bevis på hva som faktisk skjer. Det er en farlig distinksjon. Organisasjoner må skifte fra indirekte observasjon til direkte observasjon. I stedet for å håpe at et angrep skaper en detekterbar artifact, bør sikkerhetssystemer identifisere sårbare atferd og angrepsatferd på runtime. Hvis farlig kode kjøres, bør systemet vite det umiddelbart — uavhengig av om en loggpost eksisterer.

Du har forkirket for runtime-synlighet som en løsning. Hva ser sanntidssynlighet ut i praksis, og hvordan endrer det måten sikkerhetsteam opererer på en daglig basis?

Sanntidssynlighet betyr å forstå hva applikasjonen faktisk gjør i produksjon: hvilke ruter er eksponert, hvilke biblioteker er aktive, hvor sensitiv data flyter, hva kode kjøres og om et angrep nådde sårbare funksjoner. Operasjonelt endrer det sikkerhet fra en reaktiv jakt til en presisjonsdisiplin. Team stopper å jakte på massive sårbarhetsbakloger og starter å fokusere på den lille prosenten av eksponeringer som er tilgjengelige, kritiske og aktivt målrettede. Det forbedrer signal-til-støy-forholdet og respons-hastigheten dramatisk. I gjennomsnitt er bare 38% av åpne kildebiblioteker pakket i en applikasjon faktisk lastet inn i minne og kjørt. Og ikke all kode i denne undermengden brukes. Så en enkel ting som runtime-sikkerhet muliggjør er en fokus på koden som faktisk kjøres, og ikke alle ubrukte biblioteker og funksjoner som følger med en applikasjon.

Hvordan sammenlignes instrumenteringsbasert sikkerhet med tradisjonelle tilnærminger som SAST, DAST eller perimetre-overvåking når det gjelder effektivitet og skalerbarhet?

Tradisjonelle verktøy antar risiko fra utsiden. Instrumentering observerer virkeligheten ved å observere den faktiske koden som kjøres. Instrumentering kan se sanntids-kjørefløt, rammeverksatferd, autentiseringskontekst, datafløt og utnyttelses-suksess i sanntid. Det eliminerer store kategorier av falske positiver og avslører sårbarheter som perimetre-verktøy fullstendig mangler.
På skala blir presisjon kritisk. Organisasjoner kan ikke manuelt triage millioner av teoretiske funn lenger. Runtime-bevis blir det eneste bærbare filteret. Runtime fungerer i sanntid, så det er et bedre match for utviklings- og CI/CD-piper. Og runtime er kontinuerlig, så du er ikke begrenset til en snapshot-punkt-i-tid-syn på sikkerhet.

Når AI-systemer og autonome applikasjoner blir mer utbredt, blir de usynlige sårbarhetene farligere, og hvordan bør team forberede seg?

AI gjør usynlige sårbarheter mye farligere fordi det akselerer begge sider av problemet. Utviklere genererer programvare raskere, og angripere finner og utnytter svakheter raskere. Men de fleste sikkerhetsprogrammer avhenger fortsatt av menneske-i-løkken prosesser som ikke kan operere på AI-hastighet. Team bør forberede seg på to måter. Først, bygge sterke runtime-forsvar som kan oppdage, blokkere og inneholde angrep i produksjon mens sårbarheter fikses. Det gir organisasjoner luftdekning. For det andre, bruke AI og automasjon til å skrive mer sikker kode fra første sted — med bedre design, testing, gjennomgang og verifisering. Ellers skaper vi risiko raskere enn vi kan håndtere det.

Hvis du skulle rådgive en moderne Sikkerhetsoperasjons-senter-leder i dag, hva er de første konkrete skrittene de bør ta for å lukke dette synsgapet før det fører til et større brudd?

Først, aksepter at perimetre-telemetri alene er utilstrekkelig for moderne applikasjonssikkerhet. Faktisk er det umulig å se eller stoppe mange applikasjons- og API-angrep ved perimetre. SOC-en må ha synlighet innenfor kjørende applikasjoner, ikke bare infrastrukturen som hoster dem. For det andre, prioriter runtime-bevis over teoretiske funn. Fokus på sårbarheter som er i aktiv kode, identifiser aktive angrepsveier og eksponerte tjenester som faktisk kjøres i produksjon. Til slutt, foren applikasjonssikkerhet og deteksjonsingeniørarbeid. Fremtidens SOC kan ikke behandle applikasjoner som opakke svarte bokser lenger. Applikasjoner er nå det primære angrepsflaten, og de trenger førsteklasses synlighet på runtime.

Takk for det flotte intervjuet, lesere som ønsker å lære mer kan besøke OWASP eller Contrast Security.