Giovanni Vignone, CEO y Fundador de Octane Security – Serie de Entrevistas

Giovanni Vignone, CEO y Fundador de Octane Security, lanzó la empresa en 2022 para abordar la creciente necesidad de ciberseguridad proactiva en Web3. Con solo 22 años, se propuso crear una plataforma impulsada por IA que funciona como un ingeniero de seguridad 24/7, analizando bases de código de contratos inteligentes en tiempo real, integrándose directamente en pipelines CI/CD y detectando vulnerabilidades que las auditorías tradicionales a menudo pasan por alto.

En esta conversación, exploramos la misión de Octane de integrar la detección continua y explicable de vulnerabilidades en el ciclo de vida del desarrollo de software — y lo que se necesita para asegurar el futuro de contratos inteligentes.

¿Qué inspiró la decisión de dejar Duke y crear Octane a tiempo completo? ¿Hubo un momento particular que aclaró la oportunidad?

Durante mi tercer año en Duke, obtuve acceso beta temprano a la plataforma de OpenAI y comencé a experimentar con grandes modelos de lenguaje en contratos inteligentes en cripto. Los resultados realmente me abrieron los ojos a lo que era posible.

Hubo un momento específico que destaca. Introduje un contrato inteligente en la interfaz de chat y le pedí que encontrara cualquier problema. Los resultados necesitaban trabajo, pero pude ver de inmediato el enorme potencial de usar LLMs para detectar vulnerabilidades difíciles de encontrar. Esto fue en marzo de 2023.

Esto ocurrió alrededor del mismo tiempo en que veía todos estos hackeos y explotaciones sucediendo en toda la industria. Me di cuenta de que había una necesidad urgente de solucionar estos problemas de seguridad, y estos modelos nos ofrecían una forma única de abordarlos. Simplemente me di cuenta de que era el momento adecuado para apostar todo por Octane.

¿Cuáles fueron algunos de los mayores desafíos técnicos u operacionales al llevar Octane del concepto a la adopción por parte de las principales empresas de cripto?

El mayor desafío técnico fue descubrir cómo identificar vulnerabilidades y mostrárselas a los usuarios de una manera que pudieran usar realmente. Esto fue muy difícil porque las vulnerabilidades no son blanco y negro, tienen múltiples dimensiones.

Cuando analizamos una vulnerabilidad potencial, debemos considerar varias cosas: ¿cuál es el impacto (¿alguien podría perder dinero o un estado importante?), qué tan fácil es explotarla, qué se puede hacer para corregirla y qué está causando el problema en primer lugar? Manejar todos estos aspectos a la vez y presentarlos claramente requirió mucho trabajo.

Invertimos mucho esfuerzo en convertir cada uno de estos componentes en un producto para que los clientes pudieran usar Octane para encontrar vulnerabilidades, comprender rápidamente cuán graves son y comenzar a corregirlas de inmediato. Construir sistemas que pudieran detectar consistentemente estos problemas en diferentes bases de código requirió tanto conocimientos técnicos como una gran cantidad de datos sobre todo tipo de vulnerabilidades.

Octane pretende funcionar como un ingeniero de seguridad de IA integrado en cada equipo de desarrollo. ¿Qué hitos son necesarios para lograr plenamente ese objetivo en toda la industria?

Nuestro primer gran hito es cambiar la forma en que los desarrolladores piensan sobre la seguridad, lograr que la incorporen desde el primer día en lugar de añadirla unas semanas antes del lanzamiento. Esto significa demostrarles que comenzar con la seguridad realmente ahorra tiempo al permitirles corregir problemas antes.

También necesitamos ayudar a los usuarios a ver y comprender lo que ocurre cuando detectan vulnerabilidades temprano, para que puedan experimentar los beneficios de primera mano.

En el lado del producto, debemos admitir más lenguajes más allá de Solidity: otros lenguajes de contratos inteligentes y, eventualmente, lenguajes de programación regulares también. Siempre estamos trabajando en mejorar la precisión de nuestros modelos y en detectar más tipos de vulnerabilidades.

¿Cómo evolucionará la plataforma para abordar amenazas complejas que no son de código, como phishing o exploits basados en malware?

De hecho, ya manejamos algunas de estas amenazas hoy. Señalamos riesgos de centralización, lo que ayuda a los equipos a saber qué claves privadas y roles son especialmente sensibles.

También detectamos patrones comunes de phishing en contratos inteligentes, como cuando alguien usa tx.origin para la lógica de verificación del llamador, lo que puede conducir a ataques de phishing. Nos aseguramos de señalar esto a los usuarios.

En este momento, Octane funciona principalmente como una herramienta de seguridad previa al despliegue, en lugar de algo que detecte amenazas en tiempo real. Nuestro plan es seguir ampliando lo que podemos detectar antes de que el código se ponga en producción, proporcionando a los desarrolladores las herramientas para corregir problemas potenciales antes de que se conviertan en ataques reales.

¿Qué hace que el aprendizaje automático no supervisado —específicamente el clustering— sea un enfoque más eficaz para clasificar vulnerabilidades de contratos inteligentes que los sistemas tradicionales basados en reglas?

El aprendizaje automático no supervisado realmente nos ha ayudado a mapear qué tipos de errores existen. Aunque todavía usamos técnicas basadas en reglas para construir nuestros modelos supervisados, el aprendizaje no supervisado, especialmente el clustering, nos ayuda a determinar qué modelos debemos crear y cómo priorizarlos.

Este enfoque nos permite dividir nuestros modelos en pipelines de análisis más especializados para diferentes tipos de vulnerabilidades.

En realidad, utilizamos tanto ML supervisado como no supervisado juntos: aprendizaje no supervisado para comprender el panorama y métodos supervisados para construir capacidades de detección precisas. Esta combinación funciona mejor que depender únicamente de los sistemas tradicionales basados en reglas.

¿Puedes compartir un ejemplo donde el clustering reveló una nueva clase de vulnerabilidades que no se había reconocido previamente en auditorías o revisiones de seguridad?

El clustering no crea realmente nuevas categorías de vulnerabilidades desde cero; toma datos existentes y los agrupa de manera significativa. Nuestros datos provienen de exploits en cadena del mundo real, informes públicos de vulnerabilidades y otras fuentes de errores en contratos inteligentes.

Lo que el aprendizaje no supervisado hace muy bien es ayudarnos a refinar cómo entendemos las categorías de vulnerabilidades existentes. Detecta patrones y conexiones entre diferentes vulnerabilidades que de otro modo pasarían desapercibidos, lo que nos permite crear mejores métodos de detección.

A través de este reconocimiento de patrones y agrupamiento de datos, hemos creado modelos más matizados que pueden detectar variaciones sutiles de tipos de vulnerabilidades conocidas, en lugar de descubrir clases completamente nuevas de vulnerabilidades.

¿Cómo maneja Octane los casos límite donde una vulnerabilidad no encaja claramente en las categorías existentes dentro de la taxonomía?

Intentamos equilibrar cuán específicas versus generales hacemos nuestra taxonomía. Cuanto más generales sean nuestras categorías y modelos, mejor podemos detectar casos límite extraños que no encajan perfectamente en ningún lado. Pero las categorías más específicas brindan a los usuarios mejores explicaciones y nos permiten detectar tipos de errores conocidos de manera más consistente.

Cuando nos encontramos con vulnerabilidades que Octane pasa por alto o que no coinciden claramente con nuestras categorías existentes, evaluamos si debemos agregar más datos sobre esa vulnerabilidad a un modelo existente, o si necesitamos crear un modelo completamente nuevo para detectar ese tipo de error en el futuro.

Este enfoque flexible nos permite seguir mejorando nuestras capacidades de detección mientras mantenemos un marco que tiene sentido para los usuarios.

Después de analizar miles de errores, ¿qué patrones recurrentes o causas raíz han destacado en las vulnerabilidades de contratos inteligentes?

Hemos observado varios patrones difíciles que aparecen una y otra vez. La reentrancia sigue siendo un problema importante en los contratos inteligentes. Otra gran categoría proviene del hecho de que las transacciones son visibles públicamente en el mempool, lo que crea vulnerabilidades donde los atacantes pueden ver transacciones pendientes y robar información o provocar que las transacciones fallen, lo que la gente llama front-running, aunque ocurre de muchas maneras diferentes.

También hemos encontrado muchas vulnerabilidades críticas que provienen de simples errores de los desarrolladores. Antes se llamaban genéricamente “errores de lógica”, pero eso es demasiado vago. Un error común que vemos es que los desarrolladores olvidan actualizar variables de estado en ciertas rutas de código donde realmente deberían hacerlo.

Estos son solo algunos ejemplos; tenemos un desglose privado mucho más detallado de todos los errores que hemos desarrollado mediante nuestros esfuerzos de análisis de datos.

Los contratos inteligentes varían mucho entre ecosistemas y lenguajes. ¿Cómo garantiza Octane que sus modelos sigan siendo efectivos en estos entornos diversos?

Muchas vulnerabilidades siguen patrones comunes sin importar el lenguaje o ecosistema específico. Esto nos permite crear modelos que pueden detectar eficazmente estas vulnerabilidades en diferentes bases de código.

Diseñamos nuestros modelos para centrarse en los principios básicos de seguridad que se aplican ampliamente en los sistemas de contratos inteligentes, teniendo en cuenta las características específicas de los diferentes lenguajes. Este enfoque nos ayuda a mantener la efectividad en varios entornos sin tener que reconstruir todo para cada nuevo lenguaje.

Al centrarnos en los patrones centrales de vulnerabilidades en lugar de los detalles superficiales, hemos creado modelos que pueden adaptarse al diverso mundo del desarrollo de contratos inteligentes.

Las herramientas de seguridad basadas en IA a menudo enfrentan escepticismo respecto a la explicabilidad. ¿Cómo garantiza Octane que las clasificaciones y alertas de vulnerabilidades sean accionables para los desarrolladores?

Hemos dedicado mucho trabajo a nuestro proceso de validación back-end para verificar vulnerabilidades mediante comprobaciones adicionales.

Clasificamos cuidadosamente nuestros hallazgos para separar vulnerabilidades críticas (que podrían afectar realmente la base de código) de problemas menos graves o advertencias que representan buenas prácticas. Esta categorización ayuda a los desarrolladores a centrarse en lo que más importa.

Nuestra interfaz de usuario está diseñada para ser simple y clara, resaltando los problemas más graves para que reciban atención inmediata en lugar de quedar enterrados entre un montón de alertas menos importantes. Al proporcionar explicaciones claras y centrarse en lo que es accionable, nos aseguramos de que los desarrolladores puedan comprender y corregir rápidamente las vulnerabilidades que encontramos.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar Octane Security.