Encontramos, de forma completamente autónoma, un desbordamiento de buffer en heap en una base de datos en memoria usada en infraestructura crítica a escala masiva.
El hallazgo ya pasó por el triage oficial del programa de Vulnerability Disclosure del proyecto afectado, que lo confirmó como una vulnerabilidad real, de hecho nuestro reporte llegó como el segundo de dos reportes independientes sobre el mismo bug exacto, presentados por equipos que no tienen relación entre sí. Eso no es un detalle menor: significa que dos procesos de análisis completamente distintos, trabajando por separado, llegaron a la misma conclusión sobre el mismo punto exacto del código.
Cómo llegamos ahí: Nuestro pipeline no depende de fuzzing ni de ejecutar el software objetivo. Es análisis estático más razonamiento con LLM, en dos etapas:
Un motor de priorización determinista (sin IA, barato) recorre el 100% del código en el alcance y reduce el universo a un subconjunto pequeño de funciones candidatas, típicamente menos del 1% al 17% del total, según el proyecto.
Solo ese subconjunto pasa a razonamiento profundo con IA, que es la parte cara del proceso. Ahí es donde se arma la hipótesis de ataque concreta.
Cada hallazgo que sobrevive esas dos etapas pasa todavía por una revisión de verificación independiente contra el código fuente literal, separada del pipeline que lo generó, antes de escribirse cualquier reporte. Esa revisión no solo confirma “sí, el bug existe”, distingue explícitamente entre lo que quedó verificado contra el código fuente (el mecanismo del bug, línea por línea) y lo que es una inferencia razonada pendiente de confirmación (el alcance real del impacto, p. ej. si un patrón de corrupción de memoria escala hasta ejecución de código). Reportamos ambas cosas por separado, con ese nivel de honestidad, en vez de inflar la severidad para que el hallazgo suene más importante.
Ese mismo rigor nos llevó a corregir nuestra propia clasificación inicial del bug antes de enviarlo, nuestro primer pase lo había etiquetado con el CWE equivocado, y lo corregimos en la revisión manual antes de que saliera el reporte. Preferimos ese tipo de fricción interna a publicar algo que no resiste una segunda lectura.
Sobre la responsabilidad del proceso: No publicamos huellas técnicas, archivo, función, línea, mecanismo exacto o PoC hasta que exista una corrección pública del proyecto afectado. El hallazgo sigue bajo coordinated disclosure. Vamos a publicar el análisis técnico completo en cuanto el fix esté disponible, con crédito verificable vía el número de reporte del programa de disclosure.
Cubrir el 100% de este repositorio con ese nivel de profundidad, dos etapas, más la revisión de verificación independiente le tomó a Ixtli 24 horas, sin supervisión humana continua. Ese número es para nosotros el punto más importante de todo esto: ixtli no compite con el criterio del especialista, absorbe la parte del trabajo que más cansa y peor escala en una persona, sostener la misma atención en la función 10 que en la función 10,000, sin fatiga y sin saltarse nada para que el developer o el equipo de seguridad recuperen ese tiempo para lo que sí necesita su criterio: validar qué hallazgo es real, decidir su severidad real, y estructurar cómo se resuelve.
Este hallazgo, confirmado de forma independiente por el propio triage del proyecto afectado, es la prueba en producción de que ese filtro funciona: ixtli no reemplaza al equipo humano, le entrega el trabajo ya reducido a lo único que de verdad requiere su decisión.
Top comments (0)