Jeff Williams, Fundador da OWASP e Fundador e CTO da Contrast Security – Série de Entrevistas

Jeff Williams, Fundador da OWASP e Fundador e CTO da Contrast Security, é amplamente considerado uma das figuras mais influentes na segurança de aplicativos moderna. Ao longo de várias décadas, ele ajudou a moldar a forma como as organizações abordam o desenvolvimento de software seguro, gerenciamento de vulnerabilidades e proteção de aplicativos em tempo de execução. Williams desempenhou um papel central na construção da OWASP a partir de uma pequena iniciativa de voluntários em uma fundação de segurança sem fins lucrativos globalmente reconhecida, contribuindo para projetos emblemáticos como o OWASP Top Ten, WebGoat, ESAPI, ASVS e a Folha de Dicas de Prevenção de XSS. Antes de fundar a Contrast Security em 2014, ele também fundou a Aspect Security, uma das primeiras empresas dedicadas exclusivamente à consultoria de segurança de aplicativos, treinamento, testes de penetração e práticas de desenvolvimento seguro para organizações empresariais.

OWASP é uma fundação sem fins lucrativos focada em melhorar a segurança de software por meio de projetos de código aberto, colaboração comunitária global, educação e padrões da indústria. Fundada em 2001, a organização se tornou uma das autoridades mais importantes em segurança de aplicativos, com centenas de capítulos locais, milhares de contribuintes e recursos amplamente adotados utilizados por desenvolvedores, profissionais de segurança, empresas e governos em todo o mundo. A OWASP é mais conhecida por projetos como o OWASP Top Ten, que identifica os principais riscos de segurança de aplicativos web, ao lado de numerosos quadros de segurança, ferramentas de teste, projetos de documentação e iniciativas de treinamento. A organização opera com uma filosofia de neutralidade de fornecedores, tornando seus recursos educacionais e orientações de segurança gratuitamente acessíveis à comunidade tecnológica global.

Contrast Security é uma empresa de segurança de aplicativos focada em proteger o software a partir do próprio aplicativo em execução, em vez de confiar apenas em ferramentas de varredura externas. A plataforma da empresa utiliza tecnologia de instrumentação em tempo de execução para fornecer visibilidade em tempo real sobre vulnerabilidades, ataques, APIs, dependências de código aberto e comportamento de aplicativos em ambientes de desenvolvimento e produção. Suas ofertas abrangem áreas como Teste de Segurança de Aplicativos Interativo (IAST), Detecção e Resposta de Aplicativos (ADR), Autoproteção de Aplicativos em Tempo de Execução (RASP) e análise de composição de software. A Contrast Security se posicionou em torno da integração de segurança diretamente nos fluxos de trabalho de DevSecOps modernos, permitindo que desenvolvedores, equipes de segurança de aplicativos e equipes de operações de segurança identifiquem e remediem vulnerabilidades mais rapidamente, mantendo ciclos de entrega de software rápidos.

Depois de ajudar a moldar a segurança de aplicativos moderna por meio do seu trabalho com o Open Web Application Security Project (OWASP), qual lacuna na indústria o levou a fundar a Contrast Security, e como essa tese original se manteve à medida que os desafios de segurança evoluíram?

A indústria estava afogada em descobertas teóricas estáticas e não conseguia se concentrar nos problemas que realmente importam. As equipes de segurança tinham varredores gerando grandes backlogs sem saber quais vulnerabilidades eram alcançáveis, exploráveis ou estavam sob ataque em produção. Fundamos a Contrast com uma ideia simples: as decisões de segurança devem vir da observação direta de aplicativos em execução, não de suposições de fora.

Ultimamente, eu espero que a indústria progrida para o ponto em que paramos de encontrar problemas, consertá-los e encontrar mais para sempre. Eu sou otimista de que possamos começar a criar software que tenha uma arquitetura de segurança sólida e um argumento real de que tem as defesas certas para as ameaças esperadas. A combinação de segurança em tempo de execução e IA tem o potencial, mas estamos anos longe.

Você descreveu a emergência de “vulnerabilidades do nível de mito”. O que define essa nova classe de risco, e por que elas são tão difíceis para as ferramentas de segurança convencionais detectarem?

As vulnerabilidades do nível de mito são falhas que surgem da complexidade de pilhas de software modernas. A interação entre o comportamento do framework, dependências e padrões arquitetônicos é tão complexa que os desenvolvedores muitas vezes não a entendem completamente. As ferramentas convencionais ainda são otimizadas para padrões simples conhecidos e eventos observáveis. As vulnerabilidades do estilo mito muitas vezes exigem uma compreensão mais profunda do comportamento do aplicativo, fluxo de execução e contexto em tempo de execução.

Por que categorias inteiras de vulnerabilidades falham em gerar alertas em ambientes de Segurança de Operações (SOC) modernos, e o que isso revela sobre como as equipes de segurança medem o risco atualmente?

A maioria dos SOCs é construída em torno de eventos observáveis: logs, assinaturas, tráfego de rede, atividade de endpoint. Mas muitos ataques de camada de aplicativo nunca produzem sinais significativos nesses sistemas. O desenvolvedor não sabia que havia uma vulnerabilidade e não adicionou nenhum registro que revelasse uma exploração. Portanto, a maioria das explorações de aplicativos é completamente invisível nos logs. As equipes de SOC só podem responder ao que elas podem ver. Portanto, à medida que a camada de aplicativo e API se torna cada vez mais importante, é crítico garantir que a instrumentemos com sensores de segurança que possam detectar e relatar comportamento anormal.

Arquiteturas de aplicativos modernas, como microsserviços, APIs e sistemas sem servidor, evoluíram rapidamente. Onde essas arquiteturas estão superando as abordagens de segurança baseadas em detecção atuais?

Essas arquiteturas destruíram o antigo modelo de perímetro. As solicitações agora atravessam dezenas de serviços, funções efêmeras, APIs, filas e dependências de terceiros antes de concluir uma transação. A maioria dos sistemas de detecção ainda vê fragmentos em vez do caminho de execução completo. Eles podem inspecionar pacotes ou logs, mas não podem entender a intenção, o fluxo de dados ou se o código perigoso foi executado realmente. A segurança é sobre contexto, então precisamos construir um modelo, um duplo digital, de nossa infraestrutura de aplicativos que nos permita (ou agentes de IA) raciocinar sobre o que estamos vendo acontecer.

A OWASP Top Ten continua a destacar questões como design inseguro e componentes vulneráveis. Por que esses riscos persistem apesar da conscientização e da ferramentação generalizada?

A conscientização não resolve incentivos ou complexidade. A maioria das organizações ainda mede o sucesso por volume de varredura, fechamento de tickets ou listas de verificação de conformidade, em vez de redução real de exposição.

Ao mesmo tempo, as cadeias de suprimento de software explodiram em tamanho. Os desenvolvedores montam aplicativos a partir de milhares de componentes que não escreveram e certamente não avaliaram para segurança. As equipes de segurança estão sobrecarregadas tentando triar riscos teóricos e não podem se concentrar nos 1-2% que realmente importam. Sem evidências em tempo de execução, a priorização se quebra. E com o surgimento de modelos de IA poderosos e harnesses, o volume está aumentando exponencialmente.

Como as organizações devem repensar sua dependência de logs e alertas quando algumas das vulnerabilidades mais críticas não deixam sinais observáveis?

Os logs são evidências do que os aplicativos escolhem relatar, não necessariamente evidências do que realmente aconteceu. Essa é uma distinção perigosa. As organizações precisam mudar de observação indireta para observação direta. Em vez de esperar que uma exploração crie um artefato detectável, os sistemas de segurança devem identificar o comportamento vulnerável e o comportamento de exploração em tempo de execução. Se o código perigoso for executado, o sistema deve saber imediatamente — independentemente de haver um registro de log.

Você defendeu a visibilidade em tempo de execução como uma solução. O que a verdadeira visibilidade em tempo de execução parece na prática, e como ela muda a forma como as equipes de segurança operam diariamente?

A visibilidade em tempo de execução real significa entender o que o aplicativo está realmente fazendo em produção: quais rotas estão expostas, quais bibliotecas estão ativas, onde os fluxos de dados sensíveis ocorrem, qual código foi executado e se um ataque alcançou a funcionalidade vulnerável. Operacionalmente, isso muda a segurança de um exercício de caça reativa para uma disciplina de precisão. As equipes param de perseguir grandes backlogs de vulnerabilidades e começam a se concentrar no pequeno percentual de exposições que são alcançáveis, críticas e ativamente visadas. Isso melhora dramaticamente a relação sinal-ruído e a velocidade de resposta. Em média, apenas 38% das bibliotecas de código aberto embaladas em um aplicativo são realmente carregadas na memória e executadas. E nem todo o código nesse subconjunto é usado. Então, uma coisa simples que a segurança em tempo de execução permite é um foco no código que realmente é executado, e não em todas as bibliotecas e funções não utilizadas que vêm com um aplicativo.

Como a segurança baseada em instrumentação se compara às abordagens tradicionais, como SAST, DAST ou monitoramento de perímetro, em termos de eficácia e escalabilidade?

As ferramentas tradicionais inferem risco de fora. A instrumentação observa a realidade observando o código real à medida que ele é executado. A instrumentação pode ver caminhos de execução reais, comportamento de framework, contexto de autenticação, fluxo de dados e sucesso de exploração em tempo real. Isso elimina enormes categorias de falsos positivos e expõe vulnerabilidades que as ferramentas de perímetro completamente perdem. Em escala, essa precisão se torna crítica. As organizações não podem mais triar manualmente milhões de descobertas teóricas. A evidência em tempo de execução está se tornando o único filtro sustentável. O tempo de execução funciona em tempo real, então é uma melhor correspondência para pipelines de desenvolvimento e CI/CD do que a varredura e a triagem. E o tempo de execução é contínuo, então você não está limitado a uma visão de ponto no tempo da segurança.

À medida que os sistemas de IA e aplicativos autônomos se tornam mais prevalentes, essas vulnerabilidades invisíveis se tornam mais perigosas, e como as equipes devem se preparar?

A IA torna as vulnerabilidades invisíveis muito mais perigosas porque acelera ambos os lados do problema. Os desenvolvedores estão gerando software mais rápido, e os atacantes estão encontrando e explorando fraquezas mais rápido. Mas a maioria dos programas de segurança ainda depende de processos com intervenção humana que não podem operar na velocidade da IA. As equipes devem se preparar de duas maneiras. Primeiro, construir defesas de tempo de execução mais fortes que possam detectar, bloquear e conter ataques em produção enquanto as vulnerabilidades estão sendo corrigidas. Isso dá às organizações uma cobertura aérea. Segundo, usar IA e automação para escrever código mais seguro desde o início — com melhor design, teste, revisão e verificação. Caso contrário, estamos apenas criando risco mais rápido do que podemos gerenciá-lo.

Se você estivesse aconselhando um líder de Segurança de Operações (SOC) moderno hoje, quais seriam os primeiros passos concretos que ele deveria tomar para fechar essa lacuna de visibilidade antes que ela leve a uma violação importante?

Primeiro, aceite que a telemetria de perímetro sozinha é insuficiente para a segurança de aplicativos moderna. Na verdade, é impossível ver ou parar muitos ataques de aplicativos e APIs no perímetro. O SOC precisa de visibilidade dentro dos aplicativos em execução, não apenas na infraestrutura que os hospeda. Em segundo lugar, priorize a evidência em tempo de execução sobre descobertas teóricas. Foque nas vulnerabilidades que estão em código ativo, identifique caminhos de ataque ativos e serviços expostos que estão sendo executados em produção. Finalmente, unifique a segurança de aplicativos e engenharia de detecção. O SOC futuro não pode mais tratar os aplicativos como caixas pretas opacas. Os aplicativos agora são a superfície de ataque principal, e eles precisam de visibilidade de primeira classe em tempo de execução.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar OWASP ou Contrast Security.