Buscar fallos de seguridad sin corregir en los cambios de SQLite

A quién le sirve. Equipos de seguridad e investigadores que quieren usar un agente para revisar cambios recientes de un programa de código abierto y buscar fallos parecidos a uno ya corregido; es un caso de especialistas.

Qué hicieron

Un agente de Gemini 1.5 Pro funcionó dentro de Naptime, el marco de Project Zero, que le da un navegador de código, un depurador, una herramienta para informar y un entorno aislado para scripts de Python. Los investigadores le dieron un fallo de SQLite ya corregido, junto con los mensajes y diferencias de los últimos cambios, y le pidieron que buscara problemas parecidos sin resolver. El agente enlazó el fallo antiguo con otro código, escribió un caso de prueba, provocó un cierre del programa y produjo un análisis de la causa.

Cómo salió

Encontró un desbordamiento por debajo en la pila en seriesBestIndex y SQLite lo corrigió el mismo día, antes de cualquier versión publicada. Probar con fuzzing (lanzar entradas aleatorias) durante 150 horas de procesador no lo redescubrió. El equipo dice que Big Sleep es muy experimental.

Conviene saber

El fallo estaba solo en una versión de desarrollo. Los investigadores creen que hoy un fuzzer específico para el objetivo sería probablemente igual de eficaz que el agente.

Qué necesitas

• Un agente de programación con acceso al código y a una terminal aislada, como Claude Code o Gemini CLI; el caso usó Naptime, una herramienta de Google Project Zero
• El código del programa a revisar, con su historial de cambios
• Un fallo ya corregido que sirva de ejemplo, con el cambio que lo arregló
• Un entorno aislado, como una máquina virtual o un contenedor, para ejecutar pruebas sin riesgo
• Una persona con conocimientos de seguridad que valide cada hallazgo

Cómo hacerlo tú, paso a paso

1. Elige el programa y un fallo ya corregido, con su cambio, como punto de partida.
2. Descarga el repositorio en un entorno aislado y reúne los mensajes y las diferencias de los últimos cambios.
3. Pega el prompt de la ficha con el periodo y el tipo de fallo, por ejemplo de seguridad de memoria.
4. Pídele que enlace el fallo antiguo con otro código parecido y que escriba un caso de prueba que lo confirme.
5. Ejecuta tú el caso de prueba en el entorno aislado y comprueba si provoca un cierre del programa.
6. Si se confirma, pide un análisis de la causa y avisa en privado a los responsables del programa antes de publicar nada.
7. Compara con otros métodos, como lanzar entradas aleatorias (fuzzing), para saber qué aporta cada uno.

En este repositorio [ruta o URL], revisa los cambios de [periodo o número de cambios], empezando por la corrección de [fallo conocido o cambio que lo arregló]. Busca fallos parecidos que esa corrección pudo dejar sin arreglar, sobre todo [tipo de fallo, por ejemplo seguridad de memoria]. Escribe un informe con cada cambio sospechoso, por qué parece vulnerable y cómo lo confirmarías. Habrás terminado cuando el informe esté escrito. No modifiques el código ni reveles nada públicamente.

Consejos

• No reveles ningún fallo públicamente antes de avisar a los responsables y darles tiempo para corregirlo. El prompt ya prohíbe divulgar.
• No pruebes nada contra sistemas ajenos en funcionamiento. Trabaja con una copia en tu entorno aislado.
• Desconfía de las conclusiones sin prueba. Pide siempre un caso que reproduzca el fallo.

Preguntas frecuentes

Fuentes

• scworld.com ↗
• techrepublic.com ↗

En el directorio desde el 3 de octubre de 2026.