Jeff Williams, Fondatorul OWASP și Fondator & CTO al Contrast Security – Seria de Interviuri

Jeff Williams, Fondatorul OWASP și Fondator & CTO al Contrast Security, este considerat unul dintre cei mai influenți oameni în domeniul securității aplicațiilor moderne. De-a lungul ultimelor decenii, el a ajutat la modelarea modului în care organizațiile abordează dezvoltarea de software securizat, gestionarea vulnerabilităților și protecția aplicațiilor la runtime. Williams a jucat un rol central în construirea OWASP de la o mică inițiativă de voluntariat într-o fundație de securitate non-profit recunoscută la nivel global, contribuind la proiecte de referință precum OWASP Top Ten, WebGoat, ESAPI, ASVS și XSS Prevention Cheat Sheet. Înainte de a fonda Contrast Security în 2014, el a fondat și Aspect Security, una dintre primele firme dedicate exclusiv consultanței de securitate a aplicațiilor, training, testare de penetrare și practici de dezvoltare securizată pentru organizații enterprise.

OWASP este o fundație non-profit axată pe îmbunătățirea securității software prin proiecte open-source, colaborare comunitară globală, educație și standarde industriale. Fondată în 2001, organizația a devenit una dintre cele mai importante autorități în securitatea aplicațiilor, cu sute de capitole locale, mii de contribuitori și resurse larg adoptate de către dezvoltatori, profesioniști în securitate, întreprinderi și guverne din întreaga lume. OWASP este cel mai bine cunoscută pentru proiecte precum OWASP Top Ten, care identifică cele mai critice riscuri de securitate a aplicațiilor web, alături de numeroase cadre de securitate, unelte de testare, proiecte de documentare și inițiative de training. Organizația funcționează cu o filozofie neutră din punct de vedere al furnizorilor, făcând resursele educaționale și ghidurile de securitate disponibile gratuit pentru comunitatea tehnologică globală.

Contrast Security este o companie de securitate a aplicațiilor axată pe protejarea software-ului de la interiorul aplicației în sine, și nu doar pe baza unor unelte de scanare externe. Platforma companiei utilizează tehnologia de instrumentare la runtime pentru a oferi vizibilitate în timp real asupra vulnerabilităților, atacurilor, API-urilor, dependențelor open-source și comportamentului aplicației în medii de dezvoltare și producție. Ofertele sale acoperă domenii precum Testarea Interactivă de Securitate a Aplicațiilor (IAST), Detectarea și Răspunsul la Aplicații (ADR), Protecția Aplicațiilor la Runtime (RASP) și analiza compoziției software. Contrast Security s-a poziționat în jurul integrării securității direct în fluxurile de lucru DevSecOps moderne, permițând dezvoltatorilor, echipelor de securitate a aplicațiilor și echipelor de operațiuni de securitate să identifice și să remedieze vulnerabilitățile mai rapid, menținând în același timp ciclurile rapide de livrare a software-ului.

După ce ați ajutat la modelarea securității aplicațiilor moderne prin munca dvs. cu Proiectul de Securitate a Aplicațiilor Web Deschis (OWASP), ce lacună din industrie v-a determinat să fondați Contrast Security, și cum s-a menținut teza originală pe măsură ce provocările de securitate au evoluat?

Industria se îneca în constatări teoretice statice și nu putea să se concentreze pe problemele care contează cu adevărat. Echipele de securitate aveau scanere care generau liste imense de vulnerabilități fără a ști care dintre ele erau accesibile, exploatabile sau atacate în producție. Am fondat Contrast pe o idee simplă: deciziile de securitate ar trebui să vină din observarea directă a aplicațiilor care rulează, și nu din ghicirea de la exterior.

În cele din urmă, sper ca industria să progreseze până la punctul în care vom putea să ne oprim din a găsi probleme, a le remedia și a găsi altele la infinit. Sper să putem începe să creăm software care are o arhitectură de securitate puternică și un argument real că are apărări potrivite pentru amenințările așteptate. Combinația de securitate la runtime și inteligență artificială are potențial, dar suntem departe de a o atinge.

Ați descris apariția “vulnerabilităților de nivel mitic”. Ce definește această nouă clasă de risc, și de ce sunt atât de greu de detectat pentru uneltele de securitate convenționale?

Vulnerabilitățile de nivel mitic sunt defecte care apar din complexitatea stivelor de software moderne. Interacțiunea dintre comportamentul framework-ului, dependențe și modele arhitecturale este atât de complexă încât dezvoltatorii adesea nu o înțeleg pe deplin. Uneltele convenționale sunt încă optimizate pentru modele și evenimente observabile relativ simple. Vulnerabilitățile de nivel mitic adesea necesită o înțelegere a comportamentului aplicației, a fluxului de execuție și a contextului de runtime la un nivel mult mai profund.

De ce întregi categorii de vulnerabilități nu generează alerte în medii de operare de securitate moderne (SOC), și ce revelează acest lucru despre modul în care echipele de securitate măsoară riscul în prezent?

Majoritatea SOCs sunt construite în jurul evenimentelor observabile: jurnale, semnături, trafic de rețea, activitate de punct terminal. Dar multe atacuri la nivel de aplicație nu produc semnale semnificative în aceste sisteme. Dezvoltatorul nu știa că există o vulnerabilitate și nu a adăugat nicio înregistrare care ar fi putut dezvălui o exploatare. Prin urmare, majoritatea exploatărilor de aplicații sunt complet invizibile în jurnale. Echipele SOC pot răspunde doar la ceea ce pot vedea. Prin urmare, pe măsură ce stratul de aplicații și API devine din ce în ce mai important, este critic să ne asigurăm că îl instrumentăm cu senzori de securitate care pot detecta și raporta comportamentul anormal.

Arhitecturile de aplicații moderne, cum ar fi microservicii, API și sisteme fără server, au evoluat rapid. În ce domenii depășesc aceste arhitecturi abordările de securitate bazate pe detectare actuale?

Aceste arhitecturi au spart vechiul model de perimetru. Cererile traversează acum zeci de servicii, funcții efemere, API, cozi și dependențe terțe înainte de a finaliza o tranzacție. Majoritatea sistemelor de detectare încă văd fragmente în locul întregului flux de execuție. Ele pot inspecta pachete sau jurnale, dar nu pot înțelege intenția, fluxul de date sau dacă codul periculos a fost executat cu adevărat. Securitatea este despre context, așa că trebuie să construim un model, un gemene digital, al infrastructurii noastre de aplicații care să ne permită (sau agenților AI) să raționăm despre ceea ce se întâmplă.

OWASP Top Ten continuă să sublinieze probleme precum proiectarea nesigură și componentele vulnerabile. De ce persistă aceste riscuri, în ciuda conștientizării și instrumentelor larg răspândite?

Conștientizarea nu rezolvă problemele de stimulente sau complexitate. Majoritatea organizațiilor încă măsoară succesul prin volumul de scanare, închiderea de bilete sau liste de verificare a conformității, și nu prin reducerea reală a expunerii.

În același timp, lanțurile de aprovizionare cu software au explodat în dimensiune. Dezvoltatorii asamblează aplicații din mii de componente pe care nu le-au scris și cu siguranță nu le-au evaluat pentru securitate. Echipele de securitate sunt copleșite încercând să triajeze riscuri teoretice și nu se pot concentra pe acel 1-2% care contează cu adevărat. Fără dovezi la runtime, prioritizarea se prăbușește. Și cu apariția puternicelor modele AI și harnașamente, volumul este în creștere exponențială.

Cum ar trebui organizațiile să reconsidere dependența lor de jurnale și alerte atunci când unele dintre cele mai critice vulnerabilități nu lasă semne observabile?

Jurnalele sunt dovezi ale ceea ce aplicațiile aleg să raporteze, și nu neapărat dovezi ale ceea ce s-a întâmplat cu adevărat. Acesta este un lucru periculos. Organizațiile trebuie să treacă de la observarea indirectă la observarea directă. În loc să sperăm că o exploatare creează un artifact detectabil, sistemele de securitate ar trebui să identifice comportamentul vulnerabil și comportamentul de exploatare la runtime. Dacă codul periculos se execută, sistemul ar trebui să știe imediat — indiferent dacă există sau nu o intrare în jurnal.

Ați susținut vizibilitatea la runtime ca soluție. Ce înseamnă vizibilitatea reală la runtime în practică, și cum schimbă ea modul în care echipele de securitate operează zilnic?

Vizibilitatea reală la runtime înseamnă a înțelege ce face aplicația cu adevărat în producție: care rute sunt expuse, care biblioteci sunt active, unde curge datele sensibile, ce cod s-a executat și dacă un atac a ajuns la funcționalitatea vulnerabilă. Operațional, schimbă securitatea de la o vânătoare reactivă la o disciplină de precizie. Echipele încetează să urmărească liste imense de vulnerabilități și încep să se concentreze pe acel mic procent de expuneri care sunt accesibile, critice și țintite activ. Acest lucru îmbunătățește dramatic raportul semnal-zgomot și viteza de răspuns. În medie, doar 38% din bibliotecile open-source ambalate într-o aplicație sunt încărcate în memorie și executate. Și nu tot codul din această submulțime este utilizat. Prin urmare, una dintre lucrurile simple pe care securitatea la runtime le permite este concentrarea asupra codului care rulează cu adevărat, și nu asupra tuturor bibliotecilor și funcțiilor neutilizate care vin odată cu o aplicație.

Cum se compară securitatea bazată pe instrumentare cu abordările tradiționale, cum ar fi SAST, DAST sau monitorizarea perimetrului, în ceea ce privește eficacitatea și scalabilitatea?

Uneltele tradiționale inferă riscul din exterior. Instrumentarea observă realitatea prin observarea codului care rulează. Instrumentarea poate vedea căi de execuție reale, comportamentul framework-ului, contextul de autentificare, fluxul de date și succesul exploatației în timp real. Elimină categorii întregi de false pozitive și expune vulnerabilități pe care uneltele de perimetru le omit complet.
La scară, această precizie devine critică. Organizațiile nu pot triaja manual milioane de constatări teoretice. Dovezile la runtime devin singurul filtru sustenabil. Funcționează în timp real, deci este o potrivire mai bună pentru fluxurile de dezvoltare și CI/CD decât scanarea și triajul. Și este continuă, deci nu sunteți limitați la o vedere punctuală a securității.

Pe măsură ce sistemele AI și aplicațiile autonome devin mai prevalente, devin vulnerabilitățile invizibile mai periculoase, și cum ar trebui echipele să se pregătească?

AI face vulnerabilitățile invizibile mult mai periculoase, deoarece accelerează ambele părți ale problemei. Dezvoltatorii generează software mai rapid, și atacatorii găsesc și exploatează slăbiciunile mai rapid. Dar majoritatea programelor de securitate încă se bazează pe procese cu intervenție umană care nu pot opera la viteza AI. Echipele ar trebui să se pregătească în două moduri. Primul, să construiască apărări mai puternice la runtime care pot detecta, bloca și conține atacurile în producție în timp ce se remediază vulnerabilitățile. Acest lucru oferă organizațiilor un timp de grație. Al doilea, să utilizeze AI și automatizarea pentru a scrie cod mai sigur din start — cu o proiectare, testare, revizuire și verificare mai bune. Altfel, suntem doar creând risc mai rapid decât putem să îl gestionăm.

Dacă ați sfătui un lider de operațiuni de securitate modern (SOC) astăzi, care ar fi primii pași concreți pe care ar trebui să îi ia pentru a închide această lacună de vizibilitate înainte de a duce la o încălcare majoră?

Primul, acceptați că telemetria perimetrului singură este insuficientă pentru securitatea aplicațiilor moderne. De fapt, este imposibil să vedeți sau să opriți multe atacuri de aplicații și API la perimetru. SOC are nevoie de vizibilitate în interiorul aplicațiilor care rulează, și nu doar a infrastructurii care le găzduiește. Al doilea, prioritizați dovezi la runtime înainte de constatări teoretice. Concentrați-vă pe vulnerabilitățile care sunt în cod activ, identificați căile de atac active, și serviciile expuse care se execută cu adevărat în producție. În final, unificați securitatea aplicațiilor și ingineria de detectare. SOC-ul viitor nu poate trata aplicațiile ca cutii negre opace. Aplicațiile sunt acum suprafața principală de atac, și au nevoie de vizibilitate de clasa întâi la runtime.

Mulțumim pentru acest interviu minunat, cititorii care doresc să afle mai multe pot vizita OWASP sau Contrast Security.