Apple ha tenido que poner un tope al número de fallos de seguridad que un investigador puede reportarle. El motivo es que su bandeja se llenó de vulnerabilidades escritas con modelos de lenguaje: bien redactadas, plausibles y a menudo falsas. La consecuencia inmediata es la que cuenta la historia: un fallo real de macOS se quedó sin reportar porque la firma que lo encontró ya había agotado su cuota.
Puntos clave
- Apple limita los envíos al programa de recompensas y aplica un periodo de espera de 30 días al alcanzar el tope; se puede pedir cuota extra.
- La causa es el volumen de reportes generados con IA, superficialmente plausibles y con frecuencia inexactos.
- Bynario reportó más de 50 vulnerabilidades en tres semanas y quedó bloqueada.
- El fallo que no pudo enviar era una cadena de escalada de privilegios que, según la firma, daba control completo de un Mac.
- Su consejero delegado, Alfredo Pesoli, estima su valor en el mercado negro entre 100.000 y 200.000 dólares.
Cómo se rompe un programa de recompensas
El diseño de un bug bounty asume una fricción que ya no existe. Encontrar un fallo y documentarlo bien costaba días de trabajo experto, así que el número de reportes se regulaba solo.
Los modelos de lenguaje han eliminado esa fricción sin eliminar el trabajo real. Alguien con conocimientos limitados puede generar veinte reportes en una tarde, cada uno con su descripción técnica, sus pasos de reproducción y su evaluación de impacto. La mayoría no se sostienen. Pero para saberlo, alguien en Apple tiene que leerlos y comprobarlos.
Y ahí está el desequilibrio: generar cuesta minutos, verificar cuesta horas de un ingeniero de seguridad.
La respuesta de Apple tiene tres piezas. Limitar el volumen por investigador. Subir la recompensa máxima por encima de 5 millones de dólares para las cadenas de exploits más graves, para atraer al trabajo serio. E introducir "target flags", un mecanismo de verificación que obliga a demostrar el hallazgo en lugar de describirlo.
Además, Apple usa sus propios sistemas de IA para triar lo que entra. IA contra IA, con humanos revisando lo que sobrevive.
El caso Bynario
Es el ejemplo perfecto de por qué la solución tiene coste. Bynario había reportado más de 50 vulnerabilidades en tres semanas. Con el tope nuevo, quedó bloqueada.
Cuando encontró una cadena de escalada de privilegios que, según ellos, daba control completo de un Mac, no pudo enviarla. Pesoli cifra el valor de ese fallo entre 100.000 y 200.000 dólares en el mercado negro.
Ese es el problema del límite por volumen: castiga igual al que envía cincuenta reportes basura y al que envía cincuenta reportes buenos. Un tope no distingue calidad, solo cantidad.
No es solo Apple
Google publicó a finales de julio que su tubería de seguridad con IA ayudó a arreglar 1.072 bugs de Chrome en un mes, más que en los dos años anteriores. Es la misma tecnología, en el lado bueno.
Ahí está el resumen honesto de la situación: la IA encuentra fallos reales a una velocidad que antes no existía, y también genera fallos inventados a esa misma velocidad. Quien tenga el proceso de verificación bien montado se lleva lo primero; quien no, se ahoga en lo segundo.
Por qué importa
Este patrón va a llegar a cualquier canal donde recibas trabajo de gente de fuera. Candidaturas a un puesto, propuestas de proveedores, incidencias de soporte, respuestas a un pliego.
En todos esos sitios pasa lo mismo: el coste de producir se ha desplomado y el de evaluar no. Si tu proceso asumía que enviar una propuesta cuesta esfuerzo, tu proceso ya está roto y probablemente no lo has notado.
Lo que funciona no es bajar la calidad de la revisión ni poner topes ciegos. Es pedir algo que solo pueda aportar quien haya hecho el trabajo de verdad: una prueba reproducible, un caso concreto con datos, una demostración en vivo. Apple lo llama "target flags"; en una empresa normal es pedir el ejemplo real en lugar del resumen.
Relacionado
