"Encontrar errores no es lo mismo que encontrar vulnerabilidades": cómo Alex Hernández construyó Kuyfi

Kuyfi nace de una brecha que identifiqué mientras aprendía Rust y comenzaba a desarrollar smart contracts en Soroban. Ya existe una curva de aprendizaje importante para programar en Rust, y cuando además agregas conceptos de blockchain, autorización, estado y seguridad, esa barrera se vuelve todavía mayor.

Ahí entendí que el problema no era solamente aprender a escribir un contrato, sino entender cómo podría atacarlo otra persona. Un desarrollador que está comenzando puede construir algo que funciona perfectamente desde el punto de vista funcional, pero no necesariamente reconocer una vulnerabilidad que un atacante sí intentaría explotar.

Kuyfi busca reducir esa brecha. Analiza un contrato desplegado sin depender de su código fuente, reconstruye su superficie de ataque y ejecuta vectores para observar cómo responde realmente. Queremos que pensar como atacante deje de ser conocimiento reservado para especialistas y pase a formar parte natural del proceso de construcción de un smart contract.

Sí, y Kuyfi pasó por ideas bastante distintas. Una de las primeras era algo parecido a un SIEM para blockchain: monitorear transacciones y detectar comportamientos anómalos en tiempo real. Pero Stellar finaliza las operaciones rápidamente, detectar un comportamiento después de que llega a la blockchain no necesariamente permite prevenirlo.

Después exploramos un fondo comunitario de protección frente a incidentes de ciberseguridad. Las empresas aportarían a un pool y, ante un incidente validado, podrían usar esos fondos para recuperación. Pero rápidamente apareció un desafío más profundo: ¿cómo demuestras de forma objetiva que un ataque realmente ocurrió sin abrir la puerta a fraude? Oráculos, claims, modelos actuariales, nos alejábamos completamente del problema técnico que queríamos resolver.

Esas iteraciones nos ayudaron a entender dónde podíamos generar mayor impacto: no asegurando las consecuencias de una vulnerabilidad, sino ayudando a encontrarla antes de que sea explotada.

Darnos cuenta de que encontrar muchos errores no significaba estar encontrando muchas vulnerabilidades.

En una de las primeras versiones, Kuyfi analizaba los mensajes de error devueltos por las ejecuciones. Cuando lo probamos contra un contrato AMM real en Testnet, generamos 18 findings HIGH. Inicialmente parecía un buen resultado, pero cuando revisamos descubrimos que muchos eran falsos positivos. Kuyfi generaba inputs técnicamente válidos para Soroban, pero que no eran válidos dentro del contexto del contrato.

Tuvimos que decidir entre mostrar muchos findings o construir algo en lo que realmente pudiéramos confiar.

Cambiamos la arquitectura para analizar los DiagnosticEvent[] de Soroban y construir un execution trace. Ahora Kuyfi intenta entender dónde ocurrió el fallo, si fue un error de autorización, una precondición esperada o un problema realmente atribuible al contrato. Después de esa iteración, esos 18 findings dejaron de escalarse automáticamente como vulnerabilidades.

La parte difícil no es solo escribir código. Es tener la disciplina de cuestionar tu propio resultado y seguir iterando incluso cuando eso significa descartar algo que inicialmente parecía funcionar.

Reconstruir y atacar la superficie de un contrato sin tener acceso a su código fuente. Desde el bytecode, descubrir qué funciones existen es solo el principio. Después vienen las preguntas reales: qué parámetros recibe cada función, qué tipos utiliza structs, enums, unions, tipos anidados, y cómo construir inputs que produzcan un resultado significativo.

Ahí aparece el cambio de mentalidad más importante del proyecto: dejar de preguntarse "¿cómo debería usarse esta función?" y empezar a preguntarse "¿qué ocurre si alguien la usa de una forma que nunca imaginamos?". Traducir esa segunda pregunta automáticamente en vectores de ataque útiles ha sido lo que más iteraciones nos ha exigido.

Hoy sigue siendo una pregunta abierta, y de manera intencional. Kuyfi nació como una herramienta de desarrolladores para desarrolladores, y nuestra intención es mantener su núcleo open source. En esta etapa nos importa mucho más conseguir adopción y demostrar que realmente podemos aportar al ecosistema Soroban que optimizar prematuramente un modelo de monetización.

El orden importa: primero queremos construir una herramienta que los desarrolladores realmente quieran utilizar y en la que puedan confiar. Después podemos definir cuál es el modelo más sostenible para mantenerla.