Curl revisó cinco afirmaciones. Una era una vulnerabilidad

HackerOne podía celebrar un récord reportado de $81 millones en recompensas mientras los mantenedores de curl, una herramienta de transferencia de datos de código abierto, se preparaban para terminar su programa en la plataforma. El mercado pagaba más por encontrar fallas; un proyecto dijo que los reportes que llegaban por su canal requerían demasiado trabajo para evaluarse. La cobertura de finales de 2025 reportó el pago; curl anunció su plan en enero de 2026.

Las recompensas por errores se crearon para resolver un problema de descubrimiento: dar a personas externas una vía legítima para divulgar fallas de seguridad y recompensar los hallazgos que acepta el propietario de un software. La IA ha cambiado el costo de entrar a esa vía sin eliminar el trabajo del receptor. Un modelo puede generar rápidamente otra afirmación plausible; un mantenedor aún debe reproducirla, comprobar si es nueva, determinar si es una vulnerabilidad y decidir qué corregir. La verificación, más que la oferta de candidatos, se ha convertido en el recurso limitado. Los programas de recompensas están empezando a restringir el acceso y automatizar la recepción, pero ningún paso establece si producen más seguridad por hora de revisión.

El contrato original de recompensas compraba alcance

El modelo inicial de HackerOne conectaba a investigadores de sombrero blanco con empresas y cobraba una comisión de 20% sobre los pagos de recompensas. Una empresa obtenía acceso a personas que no podía contratar; un investigador obtenía una vía autorizada para reportar una falla. La recompensa seguía a un hallazgo aceptado. Ese acuerdo tenía sentido cuando encontrar y documentar un problema creíble implicaba un trabajo significativo para quien lo enviaba.

El contrato no ponía precio a cada decisión antes de la aceptación. Un receptor debe identificar la versión afectada, recrear las condiciones, comparar reportes previos, determinar el impacto y, a veces, pedir más evidencia. Un reporte rechazado puede consumir esas horas sin generar un pago de recompensa. En un proyecto de código abierto, la persona que realiza ese trabajo también puede ser quien debe publicar la corrección.

Daniel Stenberg identificó pronto el desajuste. En enero de 2024, el fundador de curl dijo que el acceso fácil a los modelos de lenguaje grandes estaba produciendo reportes basura de errores asistidos por IA que desperdiciaban tiempo y energía de los desarrolladores. Su advertencia no requería que la IA fuera mala para encontrar vulnerabilidades. Solo requería que las personas que envían afirmaciones débiles pudieran imponer trabajo a quienes deciden si esas afirmaciones son reales.

Las cinco afirmaciones de curl exigieron cinco decisiones

El plan de curl de enero de 2026 de terminar su programa de HackerOne siguió a sus quejas sobre envíos de baja calidad generados por IA. En mayo, Stenberg publicó una evaluación más acotada e inusualmente visible: la revisión manual de cinco vulnerabilidades presuntas de curl atribuidas a Mythos encontró tres falsos positivos, un error ordinario y una vulnerabilidad. Las cinco requirieron atención antes de que el equipo pudiera distinguir una de las otras cuatro.

Esa revisión no es una tasa medida de falsos positivos para Mythos, mucho menos para la investigación de seguridad con IA. El registro proporcionado no establece si esos cinco reportes fueron generados por IA, asistidos por IA o producidos bajo un método de pruebas particular. Curl es un proyecto, y su decisión de dejar un canal de recompensas no puede establecer tasas de rechazo ni valor neto de seguridad en todo el mercado. El relato de Stenberg sí muestra con precisión lo que oculta un total de candidatos: una vulnerabilidad alegada y una vulnerabilidad evaluada son unidades de trabajo distintas.

Otros operadores de recompensas habrían respondido con controles más estrictos para participantes y agentes de IA para el triage de reportes. El filtrado puede limitar quién entra a una cola, y un agente puede ayudar a ordenar lo que entra en ella. Ninguno puede resolver una falla disputada simplemente haciendo más corta la cola en un panel; alguien debe poder inspeccionar la evidencia detrás de la decisión.

Los registros de recompensas documentan la mitad pagada del intercambio

La cobertura de finales de 2025 situó las recompensas de HackerOne en un récord de $81 millones durante el año anterior, un alza interanual de 13%. Google reportó haber pagado $10 millones a 632 investigadores por hallazgos de 2023; Microsoft reportó $17 millones a 344 investigadores entre junio de 2024 y junio de 2025. Esos montos documentan una economía considerable de recompensas y el valor continuo de la investigación externa.

No revelan un denominador común. Un total de pagos no puede mostrar cuántos reportes se abrieron, cuántos duplicaron trabajo previo, cuántos no pudieron reproducirse o cuánto tiempo dedicaron los mantenedores a llegar a esas conclusiones. Cuenta dinero transferido después de un resultado, no el trabajo realizado para cada resultado posible. Por lo tanto, los costos de seguridad pueden trasladarse al receptor sin aparecer en la transacción que hizo que valiera la pena enviar el reporte.

Esa distinción también protege el argumento a favor de las recompensas. Un pago mayor podría acompañar correcciones más importantes, una revisión más costosa o ambas cosas. Sin registros comparables de recepción y evaluación, ni la salida de curl ni un año récord de recompensas pueden resolver cuál efecto predomina.

GitHub diferencia el acceso antes de poder demostrar el resultado

GitHub hizo que el reporte privado de vulnerabilidades estuviera disponible de forma general en 2023, dando a los investigadores una vía confidencial hacia los mantenedores de código abierto. La entrega privada puede reducir la exposición pública y facilitar la coordinación. Por sí sola, no establece que una afirmación entrante sea correcta.

En 2026, GitHub planeó un programa de recompensas de dos niveles con recompensas públicas menores y pagos más altos para investigadores solo por invitación en medio de una avalancha de reportes impulsados por IA. El plan pone un precio al historial previo de un investigador, en lugar de tratar de forma idéntica cada punto de entrada. También corre el riesgo de dificultar el acceso a un recién llegado capaz; la evidencia proporcionada aún no muestra su efecto sobre hallazgos válidos, carga de trabajo de los revisores o participación.

La prueba de trabajo ofrece una forma distinta de mejorar un envío individual. Un investigador puede proporcionar una versión afectada, pasos de reproducción, un resultado observado y el razonamiento que convierte el comportamiento en una falla de seguridad en vez de un error ordinario. Un receptor puede cuestionar cada parte. El plan de recompensas reportado de GitHub no establece esos requisitos, pero hace explícita la disyuntiva entre acceso abierto y capacidad de revisión. Los envíos de agentes también añaden una cuestión de autorización: un programa debe saber quién es responsable del trabajo de un investigador automatizado.

Las correcciones asistidas por IA vuelven insostenible un rechazo generalizado

Mozilla dijo que Mythos Preview y otros modelos de IA le ayudaron a identificar y lanzar 423 correcciones de errores de seguridad de Firefox en abril de 2026, frente a 31 un año antes. Las correcciones lanzadas están más adelante en el flujo de trabajo de seguridad que los hallazgos propuestos, aunque la comparación de Mozilla no aísla la contribución de Mythos ni convierte ambos abriles en experimentos controlados.

Anthropic reportó 5,500 vulnerabilidades verificadas de abril a octubre. También dijo que los socios de Glasswing encontraron más de 129,000 de abril a julio, incluidas más de 33,000 calificadas como de severidad crítica o alta. Anthropic reportó sus propios resultados y los de sus socios para períodos distintos, con descripciones diferentes de validación, por lo que ninguno de los totales proporciona un denominador para una tasa de aceptación. Sin embargo, sí descartan la idea de que el descubrimiento asistido por IA produzca únicamente reportes inutilizables.

Los proveedores están tomando decisiones distintas sobre dónde ocurre la verificación. OpenAI posicionó Codex Security en descubrimiento, validación y remediación propuesta. El OSS Scanner opcional de Anthropic, en cambio, ofrece a los proyectos de código abierto reportes generados por IA sin revisión humana antes de la entrega. El consentimiento opcional permite a un proyecto elegir si quiere recibirlos; no realiza la revisión del proyecto. La distinción es operativa: un hallazgo entregado con una ruta probada y una corrección propuesta exige algo distinto a un mantenedor que un hallazgo entregado como una posibilidad no probada.

Los programas de divulgación necesitan denominadores antes de optimizar el volumen

El Programa CVE asignó identificadores a más de 40,000 vulnerabilidades reportadas en 2024. Sus identificadores ofrecen un valioso registro compartido de fallas identificadas, no una contabilidad de cada candidato que un operador examinó camino a una decisión. Las divulgaciones de recompensas suelen hacer visible el otro extremo del proceso: investigadores aceptados y recompensas pagadas.

Un programa que busque evaluar la recepción asistida por IA tendría que publicar qué sucede entre esos puntos: envíos totales, duplicados, falsos positivos, vulnerabilidades reproducidas, tiempo hasta la primera reproducción, correcciones por severidad y tiempo de los revisores. Los operadores también necesitarían definiciones y períodos de reporte consistentes. De otro modo, un programa podría contar un error ordinario como hallazgo mientras otro cuenta solo un problema de seguridad reproducido, y sus totales parecerían comparables cuando su trabajo no lo fue.

Los $81 millones reportados de HackerOne pagaron a investigadores por hallazgos aceptados. Los mantenedores de curl tuvieron que evaluar cinco afirmaciones antes de poder llamar vulnerabilidad a una.