La presión: los equipos de seguridad del open source bajo la avalancha de vulnerabilidades asistidas por IA

¿De qué se trata?

El 26 de mayo de 2026, Daniel Stenberg, desarrollador principal de curl, publica The pressure: un texto breve y personal sobre lo que la investigación de vulnerabilidades asistida por IA está provocando en el pipeline de seguridad de uno de los proyectos de software libre más omnipresentes del mundo. Las cifras son rotundas: la entrada de informes de seguridad va de cuatro a cinco veces por encima del ritmo de 2024 y al doble del de 2025, más de un informe al día de media, y doce CVE ya confirmadas con la mitad del ciclo de release todavía por delante, lo que sitúa a curl en trayectoria de superar las treinta CVE publicadas en 2026 antes de medio año.

Esto no es un advisory de vulnerabilidad. Cubrimos el asunto precisamente porque el fenómeno que describe Stenberg ya no es exclusivo de curl. Simon Willison lo resumió ese mismo día. Help Net Security había documentado el patrón ocho días antes, con Linus Torvalds calificando la lista de seguridad del kernel de Linux como «prácticamente inmanejable» y el equipo de seguridad de producto de GitHub publicando nuevos requisitos de envío para filtrar los informes inflados por IA. El tema es ese cambio operativo, no el contador de bugs.

Cómo funciona

Aquí no hay exploit. El mecanismo es operativo, y ha atravesado dos fases distintas en los últimos dieciocho meses.

Fase                 Periodo          Señal dominante               Respuesta de mantenedores
-------------------- ---------------- ----------------------------- -------------------------------
1. AI slop           mediados 2024 →  Informes alucinados,          Bug bounties endurecen
                     2026             baja calidad                  requisitos o cierran
2. Caos de alta      marzo 2026 →     Informes detallados,          «Presión sin precedentes»;
   calidad           en curso         creíbles, a menudo            recalibrado de SLA, capacidad
                                      duplicados, asistidos por IA  y flujo de advisories

Fase 1 — el AI slop. A lo largo de 2025 y hasta principios de 2026, los proyectos con bug bounty público se ahogaban en informes verosímiles que no sobrevivían a la verificación. El post de Stenberg de enero de 2026, The end of the curl bug-bounty, documenta la trayectoria de curl: tasa de vulnerabilidades confirmadas que cae de más del 15 % en 2024 a menos del 5 % en 2025, con cierre del programa el 31 de enero de 2026. Apache Log4j, Nextcloud y otros transitaron por el mismo camino. Help Net Security cita la propia contabilidad de Stenberg, que sitúa el slop IA en torno al 20 % de los envíos de 2025, con solo un 5 % de envíos correspondiendo a vulnerabilidades reales.

Fase 2 — el caos de alta calidad. El post del 22 de abril de 2026, High-Quality Chaos, documenta el punto de inflexión. Tras mover curl la recepción de informes a GitHub y luego de vuelta a HackerOne sin bounties, el slop cayó y la tasa de vulnerabilidades confirmadas «vuelve a — e incluso supera — el nivel pre-IA de 2024, alrededor del 15-16 %», mientras el volumen absoluto de informes seguía subiendo. Casi todos los informes muestran ahora huellas de asistencia IA, incluidos «duplicados muy detallados imposibles de producir por un humano». El post del 26 de mayo es la misma persona, seis semanas después, describiendo qué le pasa a un equipo de mantenedores cuando la tasa de informes buenos también supera uno al día en un proyecto con unas treinta mil millones de instalaciones en el mundo.

Lista no exhaustiva de proyectos cuyos mantenedores han confirmado públicamente a Stenberg que observan la misma tendencia: Apache httpd, BIND, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, kernel de Linux, OpenLDAP, PowerDNS, Python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL.

Por qué importa

Tres desplazamientos convierten este tema en uno de seguridad, no de gestión comunitaria.

Primero, el cuello de botella ya no es el descubrimiento de bugs sino el pipeline de divulgación. Help Net Security cita a Shubham Shah (Assetnote): las organizaciones tardan ahora mucho más en revisar los informes legítimos — el bucle de retroalimentación que mantiene comprometidos a los buenos investigadores se degrada. Si un equipo de mantenedores no puede triagear al ritmo al que la investigación asistida por IA puede enviar, el tiempo efectivo de corrección del proyecto se alarga sea cual sea la calidad de las herramientas. El mismo modelo que encuentra un bug para un defensor puede encontrarlo para un atacante; cuanto más larga la cola, más larga es también la ventana.

Segundo, el coste lo absorbe una población pequeña y sin red. El post de Stenberg es inusualmente franco: semanas de 50 horas, «todos los días», y su esposa pidiéndole que reduzca el ritmo. El proyecto curl no es propiedad de ninguna empresa, no forma parte de ninguna fundación paraguas y cuenta aproximadamente con el mismo personal que hace cinco años. El PMC de Apache Log4j, según Piotr P. Karwasz en los comentarios al post de enero, pelea con la misma restricción. Es un punto único de fallo para bibliotecas que sostienen una fracción sustancial del software del mundo.

Tercero, la variable dominante es ahora la gobernanza, no la detección. La nota pública de Mozilla sobre el triage asistido por Mythos en Firefox describe 271 defectos latentes corregidos antes de Firefox 150, con la observación de que «los defectos son finitos». Aun siendo cierto, esa cola finita debe pasar todavía por revisión humana, divulgación, parche, release, empaquetado aguas abajo y actualización del usuario final. Esas etapas no son comprimibles a velocidad IA hoy.

Defensas

El manual defensivo aquí es operativo más que técnico, y se aplica tanto si su equipo mantiene una biblioteca open source, opera un programa de bug bounty o consume advisories aguas arriba. Ninguna de las recomendaciones siguientes requiere acceso a modelos de frontera.

1. Ajustar los requisitos de envío a la nueva realidad. Las reglas revisadas de bug bounty de GitHub, publicadas en mayo de 2026, son una plantilla útil: proof-of-concept funcional que demuestre impacto de seguridad concreto, validación de hallazgos asistidos por IA antes del envío, informes concisos sin relleno de IA y cierre explícito de informes en categorías públicamente no elegibles. La guía de uso responsable de IA del kernel de Linux es una segunda referencia. Ambas son breves y trasladables a proyectos más pequeños.

2. Desacoplar la recepción de informes de la recompensa monetaria cuando el slop domina. La decisión de curl en enero de 2026 — mantener abierto el canal de divulgación pero eliminar los bounties — es el experimento natural más limpio disponible: tras el cambio, la tasa de vulnerabilidades confirmadas volvió a niveles pre-IA. La lección no es «abolir los bounties» — los grandes proveedores siguen beneficiándose — sino «el incentivo bounty necesita un diseño específico para los envíos de la era IA». HackerOne y Bugcrowd superponen triage asistido por IA a la revisión humana; pregunte a su plataforma qué se filtra y con qué tasa de falsos negativos antes de comprometer personal a un programa en riesgo de colapso.

3. Recalibrar SLA de parche y SLA de divulgación juntos. Si su objetivo interno para CVE de motores de navegador, kernel y bibliotecas omnipresentes sigue siendo «30 días desde la divulgación», esa cifra se fijó cuando la tasa de hallazgos creíbles era menor. Por el lado de la divulgación — tiempo desde el informe aceptado hasta el CVE público — la restricción viene ahora de la capacidad de triage del mantenedor, no del ritmo del investigador. Siga los dos números y repórtelos a dirección como una sola curva.

4. Financiar las bibliotecas que embarca. La única petición explícita de Stenberg en el post del 26 de mayo es que las empresas que dependen de curl o libcurl en software comercial financien al equipo. Lo mismo se aplica a los proyectos listados arriba. Un contrato de soporte o un mantenedor patrocinado cuesta materialmente menos que el riesgo a la baja de que el pipeline de seguridad de una biblioteca crítica se apague. Para los equipos de seguridad y cumplimiento es una línea de presupuesto, no una línea de RSC.

5. Reflejar el flujo de trabajo IA en el lado defensivo. El patrón que produce la avalancha de entrada — un modelo que detecta clases de bugs candidatos desde código fuente público — es reproducible sobre código interno sin acceso de tipo Mythos. Triage su propio código base buscando análogos sin parchear de las CVE divulgadas en la versión de la biblioteca que embarca. Genere reproducciones mínimas a partir del texto del advisory antes de que llegue el PoC oficial. La asimetría favorece a los defensores solo si los defensores usan las mismas herramientas.

6. Tratar la atrición de mantenedores como un riesgo de cadena de suministro. Un único mantenedor principal que reduce horas, abandona un proyecto o se quema es un evento de supply chain para todo lo que está aguas abajo. Añada la pregunta «¿quién mantiene esto y con qué capacidad?» a su lista de due diligence para cualquier biblioteca por encima de un umbral de criticidad definido. La lista de proyectos arriba es un punto de partida razonable.

7. Participar en el grupo de trabajo de la OSSF. El Vulnerability Disclosures Working Group de la Open Source Security Foundation está recogiendo feedback sobre buenas prácticas frente a los envíos asistidos por IA. Si su organización presenta informes, opera un programa de bounty o consume advisories a escala, sus datos operativos son útiles a ese trabajo y las plantillas de política que resulten son reutilizables en su propio programa.

Estado

Elemento	Referencia	Fecha	Notas
Stenberg, The pressure	daniel.haxx.se	2026-05-26	>1 informe/día; 12 CVE confirmadas a mitad de ciclo
Resumen link blog Willison	simonwillison.net	2026-05-26	Amplificación el mismo día, etiquetas security/AI
Stenberg, High-Quality Chaos	daniel.haxx.se	2026-04-22	Tasa de vulnerabilidades confirmadas vuelve al 15-16 %
Stenberg, End of the curl bug-bounty	daniel.haxx.se	2026-01-26	Programa bounty cerrado el 31-01-2026
Help Net Security, AI is drowning maintainers	helpnetsecurity.com	2026-05-18	Cita a Torvalds, GitHub, HackerOne
Actualización bug-bounty GitHub Security	github.blog	2026-05	Nuevos requisitos, PoC obligatorio
OSSF Vulnerability Disclosures WG #178	github.com/ossf	2026	Convocatoria abierta sobre prácticas anti-slop

El encuadre correcto aquí no es «la IA produce demasiados bugs» — es «el pipeline de divulgación con revisión humana del que depende todo el ecosistema de software se dimensionó para un mundo en el que encontrar bugs era más lento que corregirlos, y esa hipótesis ya no se sostiene para todos los proyectos». Los mantenedores que sostienen la infraestructura lo señalan de forma explícita. El coste de actuar sobre esa señal — financiación, política, herramientas — es pequeño frente al coste de actuar después de que el equipo de seguridad de una biblioteca crítica haya dejado de existir.