Encontrar fallos de seguridad en software de código abierto

A quién le sirve. Equipos técnicos que usan o mantienen software de código abierto y quieren una primera revisión de seguridad; si no programas, sirve para entender qué hacen hoy estos agentes.

Qué hicieron

Big Sleep, creado por Google DeepMind y Project Zero, se dirigió a proyectos de código abierto muy usados. Encontró y notificó 20 vulnerabilidades desconocidas hasta entonces, sobre todo en FFmpeg e ImageMagick. El artículo no detalla cómo trabaja el agente ni cuánta revisión humana hubo. Sí describe el caso anterior de SQLite, donde el agente rastreó la causa de un fallo del que el equipo de inteligencia de amenazas de Google solo había visto indicios de explotación.

Cómo salió

Se notificaron 20 fallos, cuyos detalles se mantienen en reserva según el procedimiento habitual de divulgación. El artículo no dice nada de su gravedad ni de su estado de corrección. El fallo anterior de SQLite (CVE-2025-6965) se valoró con un 7,2 en la escala CVSS.

Conviene saber

Los detalles de los 20 fallos aún no son públicos, así que no se pueden comprobar. El artículo tampoco dice cuántos avisos eran válidos ni cuánta revisión humana hizo falta.

Qué necesitas

• Un agente de programación con IA, como Claude Code o Gemini CLI. La fuente no dice que Big Sleep, el agente de Google, esté disponible al público.
• Una copia del repositorio que quieres revisar, en una carpeta de pruebas.
• Alguien con conocimientos de seguridad que valide los hallazgos.
• Un entorno aislado donde comprobar los fallos sin riesgo.

Cómo hacerlo tú, paso a paso

1. Elige un proyecto de código abierto que uses o mantengas y clona su repositorio en una carpeta de pruebas.
2. Pide al agente que revise el código en busca de fallos de seguridad, como errores de memoria, inyecciones, lectura insegura de datos de entrada y claves escritas en el código.
3. Pídele que anote cada hallazgo en un archivo con la ruta, una explicación breve y la gravedad.
4. Pídele una lista ordenada con los mejores hallazgos.
5. Valida cada uno tú o con alguien de seguridad, en un entorno aislado.
6. Si el fallo es real, avisa en privado a los responsables del proyecto, siguiendo su procedimiento de seguridad. No lo hagas público antes.

Clona [dirección del repositorio de código abierto] y revisa su código en [lenguaje] en busca de posibles fallos de seguridad, como errores de memoria, inyecciones, lectura insegura de datos de entrada y claves escritas en el código. Anota cada hallazgo en un archivo con la ruta, una explicación breve y la gravedad que le das. Habrás terminado cuando tengas una lista ordenada con tus [número] mejores hallazgos. No cambies código ni abras incidencias ni propuestas de cambio.

Consejos

• No tomes como referencia los 20 fallos del caso: sus detalles aún no son públicos y no se sabe cuántos avisos eran válidos.
• Dile al agente que no cambie código ni abra incidencias o propuestas de cambio públicas.
• Revisa solo software que uses o cuya revisión esté permitida.

Preguntas frecuentes

Fuentes

• computing.co.uk ↗

En el directorio desde el 3 de octubre de 2026.