Jeff Williams, Fundador de OWASP y Fundador y CTO de Contrast Security – Serie de Entrevistas

Jeff Williams, Fundador de OWASP y Fundador y CTO de Contrast Security, es considerado uno de los personajes más influyentes en la seguridad de aplicaciones modernas. Durante las últimas décadas, ha ayudado a dar forma a la forma en que las organizaciones abordan el desarrollo de software seguro, la gestión de vulnerabilidades y la protección de aplicaciones en tiempo de ejecución. Williams desempeñó un papel central en la construcción de OWASP desde una pequeña iniciativa de voluntarios hasta una fundación de seguridad sin fines de lucro reconocida a nivel mundial, contribuyendo a proyectos emblemáticos como el OWASP Top Ten, WebGoat, ESAPI, ASVS y la Hoja de Trucos de Prevención de XSS. Antes de fundar Contrast Security en 2014, también fundó Aspect Security, una de las primeras empresas dedicadas exclusivamente a la consultoría de seguridad de aplicaciones, capacitación, pruebas de penetración y prácticas de desarrollo seguro para organizaciones empresariales.

OWASP es una fundación sin fines de lucro centrada en mejorar la seguridad del software a través de proyectos de código abierto, colaboración comunitaria global, educación e industria. Fundada en 2001, la organización se ha convertido en una de las autoridades más importantes en seguridad de aplicaciones, con cientos de capítulos locales, miles de contribuyentes y recursos ampliamente adoptados utilizados por desarrolladores, profesionales de seguridad, empresas y gobiernos de todo el mundo. OWASP es más conocida por proyectos como el OWASP Top Ten, que identifica los riesgos de seguridad de aplicaciones web más críticos, junto con numerosos marcos de seguridad, herramientas de prueba, proyectos de documentación y iniciativas de capacitación. La organización opera con una filosofía de neutralidad de proveedor, lo que hace que sus recursos educativos y orientación de seguridad sean accesibles de forma gratuita a la comunidad tecnológica global.

Contrast Security es una empresa de seguridad de aplicaciones centrada en proteger el software desde dentro de la aplicación en ejecución en lugar de confiar únicamente en herramientas de escaneo externas. La plataforma de la empresa utiliza tecnología de instrumentación en tiempo de ejecución para proporcionar visibilidad en tiempo real de vulnerabilidades, ataques, API, dependencias de código abierto y comportamiento de la aplicación en entornos de desarrollo y producción. Sus ofertas abarcan áreas como Pruebas de Seguridad de Aplicaciones Interactivas (IAST), Detección y Respuesta de Aplicaciones (ADR), Autoprotección de Aplicaciones en Tiempo de Ejecución (RASP) y análisis de composición de software. Contrast Security se ha posicionado alrededor de la integración de la seguridad directamente en flujos de trabajo de DevSecOps modernos, lo que permite a los desarrolladores, equipos de AppSec y equipos de operaciones de seguridad identificar y remediar vulnerabilidades más rápido mientras mantienen ciclos de entrega de software rápidos.

Después de ayudar a dar forma a la seguridad de aplicaciones moderna a través de su trabajo con el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP), ¿qué brecha en la industria lo llevó a fundar Contrast Security, y cómo ha mantenido su tesis original a medida que los desafíos de seguridad han evolucionado?

La industria se ahogaba en hallazgos teóricos estáticos y no podía centrarse en los problemas que realmente importaban. Los equipos de seguridad tenían escáneres que generaban enormes retardos sin saber qué vulnerabilidades eran accesibles, explotables o estaban bajo ataque en producción. Fundamos Contrast en una idea sencilla: las decisiones de seguridad deben provenir de la observación directa de aplicaciones en ejecución, no de adivinar desde afuera.

En última instancia, espero que la industria progrese hasta el punto de que podamos dejar de estar en la rueda de encontrar problemas, solucionarlos y encontrar más para siempre. Espero que podamos empezar a crear software que tenga una arquitectura de seguridad sólida y un argumento real de que tiene las defensas adecuadas para las amenazas esperadas. La combinación de seguridad en tiempo de ejecución y IA tiene el potencial, pero estamos años atrás.

Ha descrito la emergencia de “vulnerabilidades de nivel mitológico”. ¿Qué define esta nueva clase de riesgo, y por qué son tan difíciles de detectar para las herramientas de seguridad convencionales?

Las vulnerabilidades de nivel mitológico son fallos que surgen de la complejidad de las pilas de software modernas. La interacción entre el comportamiento del marco, las dependencias y los patrones arquitectónicos es tan compleja que los desarrolladores a menudo no la entienden completamente. Las herramientas convencionales todavía están optimizadas para patrones relativamente simples y eventos observables. Las vulnerabilidades de estilo mitológico a menudo requieren una comprensión del comportamiento de la aplicación, el flujo de ejecución y el contexto de tiempo de ejecución a un nivel mucho más profundo.

¿Por qué categorías enteras de vulnerabilidades no generan alertas en entornos de Centro de Operaciones de Seguridad (SOC) modernos, y qué revela esto sobre cómo los equipos de seguridad miden actualmente el riesgo?

La mayoría de los SOC están construidos alrededor de eventos observables: registros, firmas, tráfico de red, actividad de punto final. Pero muchos ataques de capa de aplicación nunca producen señales significativas en esos sistemas. El desarrollador no sabía que había una vulnerabilidad y no agregó ningún registro que revelara una explotación. Así que la mayoría de las explotaciones de aplicaciones son completamente invisibles en los registros. Los equipos de SOC solo pueden responder a lo que pueden ver. Así que a medida que la capa de aplicación y API se vuelve cada vez más importante, es fundamental asegurarse de que la instrumentemos con sensores de seguridad que puedan detectar y informar sobre comportamiento anormal.

Las arquitecturas de aplicaciones modernas, como microservicios, API y sistemas sin servidor, han evolucionado rápidamente. ¿Dónde están estas arquitecturas superando a los enfoques de seguridad basados en la detección actuales?

Estas arquitecturas han roto el antiguo modelo de perímetro. Las solicitudes ahora atraviesan docenas de servicios, funciones efímeras, API, colas y dependencias de terceros antes de completar una transacción. La mayoría de los sistemas de detección todavía ven fragmentos en lugar del camino de ejecución completo. Pueden inspeccionar paquetes o registros, pero no pueden entender la intención, el flujo de datos o si el código peligroso se ejecutó realmente. La seguridad se trata de contexto, así que necesitamos construir un modelo, un gemelo digital, de nuestra infraestructura de aplicaciones que nos permita (o a agentes de IA) razonar sobre lo que estamos viendo.

El OWASP Top Ten sigue resaltando problemas como el diseño inseguro y los componentes vulnerables. ¿Por qué persisten estos riesgos a pesar de la conciencia y la instrumentación generalizadas?

La conciencia no soluciona los incentivos o la complejidad. La mayoría de las organizaciones todavía miden el éxito por el volumen de escaneo, el cierre de tickets o las listas de verificación de cumplimiento en lugar de la reducción real de la exposición.

Al mismo tiempo, las cadenas de suministro de software explotaron en tamaño. Los desarrolladores ensamblan aplicaciones a partir de miles de componentes que no escribieron y ciertamente no evaluaron para la seguridad. Los equipos de seguridad están abrumados tratando de triar riesgos teóricos y no pueden centrarse en el 1-2% que realmente importa. Sin evidencia en tiempo de ejecución, la priorización se desmorona. Y con la emergencia de modelos de IA y arneses poderosos, el volumen está aumentando exponencialmente.

¿Cómo deberían las organizaciones replantear su dependencia de registros y alertas cuando algunas de las vulnerabilidades más críticas no dejan señales observables?

Los registros son evidencia de lo que las aplicaciones eligen informar, no necesariamente evidencia de lo que realmente sucedió. Esa es una distinción peligrosa. Las organizaciones necesitan cambiar de la observación indirecta a la observación directa. En lugar de esperar a que una explotación cree un artefacto detectable, los sistemas de seguridad deben identificar el comportamiento vulnerable y el comportamiento de explotación en tiempo de ejecución. Si se ejecuta código peligroso, el sistema debe saberlo de inmediato, ya sea que exista o no una entrada de registro.

Ha abogado por la visibilidad en tiempo de ejecución como solución. ¿Qué se parece la verdadera visibilidad en tiempo de ejecución en la práctica, y cómo cambia la forma en que los equipos de seguridad operan a diario?

La verdadera visibilidad en tiempo de ejecución significa entender qué está haciendo la aplicación en producción realmente: qué rutas están expuestas, qué bibliotecas están activas, dónde fluyen los datos sensibles, qué código se ejecuta y si un ataque alcanzó la funcionalidad vulnerable. Operativamente, cambia la seguridad de un ejercicio de caza reactivo a una disciplina de precisión. Los equipos dejan de perseguir enormes retardos de vulnerabilidades y comienzan a centrarse en el pequeño porcentaje de exposiciones que son accesibles, críticas y activamente objetivo. Eso mejora dramáticamente la relación señal ruido y la velocidad de respuesta. En promedio, solo el 38% de las bibliotecas de código abierto empaquetadas en una aplicación se cargan en la memoria y se ejecutan. Y no todo el código en este subconjunto se utiliza. Así que una cosa simple que la seguridad en tiempo de ejecución permite es centrarse en el código que realmente se ejecuta, y no en todas las bibliotecas y funciones no utilizadas que vienen con una aplicación.

¿Cómo se compara la seguridad basada en instrumentación con los enfoques tradicionales como SAST, DAST o monitoreo de perímetro en términos de efectividad y escalabilidad?

Las herramientas tradicionales infieren el riesgo desde afuera. La instrumentación observa la realidad observando el código real a medida que se ejecuta. La instrumentación puede ver caminos de ejecución reales, comportamiento del marco, contexto de autenticación, flujo de datos y éxito de explotación en tiempo real. Elimina enormes categorías de falsos positivos y expone vulnerabilidades que las herramientas de perímetro pasan por completo. A escala, esa precisión se vuelve crítica. Las organizaciones no pueden triar manualmente millones de hallazgos teóricos. La evidencia en tiempo de ejecución se está convirtiendo en el único filtro sostenible. La ejecución en tiempo de ejecución funciona en tiempo real, así que es una mejor coincidencia para flujos de trabajo de desarrollo y CI/CD que el escaneo y la triage. Y la ejecución en tiempo de ejecución es continua, así que no está limitada a una vista de instantánea de seguridad.

¿A medida que los sistemas de IA y las aplicaciones autónomas se vuelven más prevalentes, ¿se vuelven estas vulnerabilidades invisibles más peligrosas, y cómo deberían prepararse los equipos?

La IA hace que las vulnerabilidades invisibles sean mucho más peligrosas porque acelera ambos lados del problema. Los desarrolladores generan software más rápido, y los atacantes encuentran y explotan debilidades más rápido. Pero la mayoría de los programas de seguridad todavía dependen de procesos con humanos en el bucle que no pueden operar a la velocidad de la IA. Los equipos deben prepararse de dos maneras. Primero, construir defensas de tiempo de ejecución más sólidas que puedan detectar, bloquear y contener ataques en producción mientras se solucionan las vulnerabilidades. Eso da a las organizaciones cobertura aérea. Segundo, usar la IA y la automatización para escribir código más seguro desde el principio, con un mejor diseño, pruebas, revisión y verificación. De lo contrario, solo estamos creando riesgos más rápido de lo que podemos gestionarlos.

Si estuviera asesorando a un líder de Centro de Operaciones de Seguridad (SOC) moderno hoy, ¿cuáles son los primeros pasos concretos que deberían tomar para cerrar esta brecha de visibilidad antes de que conduzca a una violación importante?

Primero, acepte que la telemetría de perímetro sola es insuficiente para la seguridad de aplicaciones modernas. De hecho, es imposible ver o detener muchos ataques de aplicación y API en el perímetro. El SOC necesita visibilidad dentro de las aplicaciones en ejecución, no solo la infraestructura que las hospeda. Segundo, priorice la evidencia en tiempo de ejecución sobre los hallazgos teóricos. Centrarse en las vulnerabilidades que están en código activo, identificar rutas de ataque activas y servicios expuestos que se ejecutan realmente en producción. Finalmente, unifique la seguridad de aplicaciones y la ingeniería de detección. El futuro SOC no puede tratar a las aplicaciones como cajas negras opacas. Las aplicaciones son ahora la superficie de ataque principal, y necesitan visibilidad de primera clase en tiempo de ejecución.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar OWASP o Contrast Security.