La IA abarató encontrar fallos. Ahora arreglarlos es el cuello de botella

El coste del descubrimiento se desplomó

Encontrar una vulnerabilidad plausible requería antes habilidad, tiempo y una comprensión sólida del código. Los grandes modelos de lenguaje han eliminado la mayor parte de ese coste. Investigadores y herramientas automáticas pueden generar hoy grandes volúmenes de informes candidatos contra proyectos populares de código abierto en cuestión de horas. El problema es que el trabajo no termina con el descubrimiento. Alguien debe reproducir el fallo, valorar su gravedad, escribir la corrección, revisarla y distribuirla a los usuarios. Ninguno de esos pasos se ha abaratado.

Esa asimetría obliga a los programas de recompensas a cambiar sus reglas. curl suspendió su programa de recompensas en enero de 2026. Google endureció su programa de recompensas de código abierto en marzo de 2026 y exige pruebas de mayor calidad, como una reproducción con OSS-Fuzz o un parche integrado, para ciertos niveles de pago. Google ha afirmado que muchos informes generados con IA incluyen condiciones de activación alucinadas o describen fallos con poco impacto real de seguridad. En abril, HackerOne pausó los pagos de Internet Bug Bounty. El programa había pagado más de 1,5 millones de dólares desde 2012 y tradicionalmente destinaba cerca del 80 % de las recompensas a nuevos hallazgos y el 20 % al apoyo a la corrección.

La explicación de HackerOne es la declaración más clara del problema hasta ahora. Dijo que la investigación asistida por IA está ampliando el descubrimiento de vulnerabilidades en todo el ecosistema, aumentando su cobertura y su velocidad, y que el equilibrio entre hallazgos y capacidad de corrección en código abierto ha cambiado de forma sustancial. Node.js, uno de los primeros proyectos afectados, sigue aceptando informes a través de HackerOne, aunque ya no paga recompensas por ellos.

Por qué los malos informes son caros

Un informe erróneo no es gratuito para quien lo recibe. El mantenedor debe leerlo, reproducirlo y explicar por qué no funciona, a menudo en un hilo lleno de intercambios educados pero poco útiles. Si el informe describe una ruta de activación que no existe, el mantenedor puede pasar horas investigando código que nunca se ejecuta. Multiplique eso por decenas de envíos y un equipo voluntario puede perder toda una semana solo en la clasificación. Los informes que parecen fiables pero son incorrectos cuestan más que los claramente malos, porque no se pueden descartar de un vistazo.

La respuesta de los programas ha sido devolver la carga de la prueba al informante. Pedir una reproducción con un fuzzer, una prueba de concepto que funcione sobre la versión actual o un parche obliga al informante a hacer parte del trabajo que, de otro modo, recaería en el mantenedor. Además, filtra los envíos de autores que no han ejecutado realmente el código.

Por qué esto importa más allá del código abierto

Lo que está en juego no es teórico. El Informe de Investigaciones de Brechas de Datos 2026 de Verizon encontró que cerca del 31 % de las brechas ya se originan en la explotación de vulnerabilidades de software, frente a cerca del 20 % el año anterior. En ese conjunto de datos, la explotación de vulnerabilidades ha superado al robo de credenciales como principal vía de acceso inicial. La mayor parte del software empresarial se construye sobre componentes de código abierto, así que un atasco en la corrección aguas arriba se convierte en un atasco en cada producto aguas abajo.

La cobertura de la brecha de financiación también ha puesto de relieve la escala del problema. Según informes, la Linux Foundation pidió ayuda financiera a empresas de IA, y Google, Anthropic, AWS, Microsoft y OpenAI se comprometieron conjuntamente con 12,5 millones de dólares para trabajo de seguridad en código abierto. Es una cifra considerable, pero es una contribución puntual frente al trabajo continuo de mantener bibliotecas muy usadas.

Qué debería cambiar

Lo correcto es pagar por la parte cara del trabajo. Descubrir fallos es ahora barato; un arreglo confirmado y distribuido no lo es. De ahí se derivan varios cambios.

• Los mantenedores deberían escribir un criterio de evidencia explícito en su política de seguridad. Los informes sin reproducción, sin prueba fallida o sin prueba de concepto pueden cerrarse automáticamente, con una plantilla breve que explique qué se necesita. Configurarlo lleva minutos y ahorra horas después.
• Los mantenedores deberían tratar la revisión de parches como una actividad con presupuesto. Si un proyecto depende de voluntarios, la financiación debe cubrir el tiempo de revisión, no solo los pagos por informes.
• Las empresas que dependen de software de código abierto deberían medir el tiempo de corrección, no el tiempo de notificación. Un equipo de seguridad que cuenta cuántos casos ha clasificado optimizará el volumen. Un equipo que sigue cuánto tiempo permanece sin parchear una vulnerabilidad en sus dependencias financiará el trabajo que importa.
• Las plataformas de recompensas deberían pagar más por los parches integrados que por los informes, y considerar pagar también por los artefactos de reproducción antes de iniciar la clasificación.
• Los investigadores que encuentran fallos reales deberían enviar un parche junto con el informe. Un parche que supera la suite de pruebas es lo más útil que un informante puede entregar a un mantenedor.

Qué significa esto para su equipo

Si dirige un producto que depende de componentes de código abierto, empiece por inventariar los proyectos aguas arriba de los que depende y compruebe si tienen un proceso activo de respuesta de seguridad. Pida a sus proveedores niveles de servicio para parches, no solo resultados de escaneo. Cuando se informa de una vulnerabilidad aguas arriba, el tiempo hasta una versión corregida es la cifra que determina su exposición, y esa cifra depende de la capacidad de los mantenedores que usted puede ayudar a financiar.

El problema del descubrimiento no va a desaparecer, y probablemente no debería. Que se encuentren más fallos no es un fracaso en sí mismo. El fracaso sería seguir recompensando el paso barato mientras el paso caro recae en unos pocos voluntarios agotados. Los programas que cambian sus reglas ahora intentan corregir eso, y los equipos que dependen de este software también deberían prestar atención.