Curl inundado por basura generada por IA: un desarrollador convierte el caos en 50 correcciones reales.

En la comunidad en torno a curl, una de las principales bibliotecas para trabajar con protocolos de red, desde hace dos años se discute una tendencia molesta: el proyecto se enfrenta cada vez más a informes falsos de fallos generados por redes neuronales. Un flujo de tickets automáticos sobre supuestas vulnerabilidades se ha convertido en una fuente de trabajo extra para los desarrolladores, obligados a dedicar tiempo a verificar problemas inventados. El autor y mantenedor del proyecto, Daniel Stenberg, ha escrito sobre esto en su blog y ha intentado convencer a los cazadores de recompensas de mostrar moderación y no generar informes ficticios.

Esta situación no es desconocida para el equipo de curl. Comunidades como la de Python, el proyecto Open Collective y los desarrolladores de Mesa han afrontado dificultades similares. En todos los casos se observa la misma pauta: el problema radica no en la tecnología, sino en las personas. La confirmación llegó recientemente, cuando el investigador polaco Joshua Rogers envió a curl decenas de informes elaborados con herramientas de IA para el análisis de código. A diferencia de la masa de comunicaciones previas de baja calidad, sus materiales resultaron valiosos: registraban tanto errores menores como deficiencias graves.

Stenberg señaló que gran parte de lo encontrado recordaba los resultados de analizadores estáticos: errores pequeños e inexactitudes sin importancia. No obstante, incluso esos detalles deben corregirse. Además, entre los informes hubo casos más serios, por ejemplo un acceso fuera de los límites de un arreglo en la implementación Kerberos5 FTP. Aunque ese defecto no se clasificó como una vulnerabilidad, sí fue corregido. En total, gracias a los informes de Rogers se incorporaron al proyecto alrededor de cincuenta correcciones.

En una conversación con The Register, Stenberg explicó que la experiencia con los informes de Rogers demuestra que las herramientas de IA pueden ser útiles si las emplea una persona que sabe lo que hace. Por sí mismas no resuelven el problema de la calidad, pero en manos de un desarrollador o investigador experimentado se convierten en una poderosa herramienta para buscar errores. Añadió además que este caso ilustra hasta qué punto resultan inútiles y molestos los flujos de tickets aleatorios generados por personas que confían ciegamente en la generación automática.

Mientras tanto, Rogers publicó un análisis de las utilidades que utilizó en su trabajo. En su lista figuraban Almanax, Corgea, ZeroPath, Gecko y Amplify. Llegó a la conclusión de que estos sistemas ya son capaces de encontrar vulnerabilidades reales en proyectos complejos y que en los próximos años desempeñarán un papel importante. Comparó la fase actual con la primera mitad de los años 2010, cuando el fuzzing volvió a cobrar protagonismo gracias a afl-fuzz, y señaló que los escáneres de IA tienen potencial para ejercer una influencia comparable en la búsqueda de errores.

Lo que más le impresionó fue ZeroPath. Durante la revisión de proyectos abiertos, la herramienta encontró cientos de defectos genuinos en aplicaciones críticas. Entre ellas figuran sudo, libwebm, Next.js, Avahi, hostap, así como curl y el servidor proxy Squid, donde ZeroPath detectó más de doscientas fallas. Rogers señaló que este escáner no solo es capaz de encontrar vulnerabilidades, sino que también muestra alta eficacia en la búsqueda de errores lógicos comunes si se configuran de antemano reglas especiales.

Sin embargo, estos sistemas también tienen limitaciones. Ninguno de los escáneres probados pudo detectar un bucle infinito en el paquete image-size para npm —un bug que ya se conocía y que aún no se ha corregido, aunque la solución se propuso en abril. Rogers subrayó que aquí también interviene el factor humano: el parche existe, pero nadie lo ha aplicado.