curl va a tratar en público los fallos de seguridad que no sean graves. Desde el 26 de octubre, todo lo que el proyecto clasifique como severidad baja o media se gestiona en su repositorio de GitHub, a la vista de cualquiera. El canal privado queda reservado para alto y crítico. Lo ha contado Daniel Stenberg, y el motivo que da no es filosófico: están desbordados.
Qué ha pasado
Stenberg habla de una avalancha de informes de vulnerabilidad que no para, que no ven que vaya a aflojar en los próximos meses y que tiene a todos los mantenedores clave al límite. Su frase, traducida, es de las que no se escriben a la ligera:
Tenemos que actuar para sobrevivir. Este es el siguiente paso de una estrategia de supervivencia. Puede que no sea el último.
Los números que da explican la decisión mejor que cualquier manifiesto: en los últimos años, más del 90 % de lo que les ha entrado se podía clasificar rápidamente por debajo de «alto». Es decir, nueve de cada diez informes consumen el recurso más caro del proyecto —la atención de un puñado de personas— para acabar en un cajón de cosas menores.
No es el primer movimiento. Este mismo año cerraron el programa de recompensas por errores, porque los envíos generados con IA estaban cargando de trabajo al equipo de seguridad. Stenberg ha dicho más de una vez que no todos los informes asistidos por IA son basura, y lo mantiene. Pero describe un patrón muy concreto: gente que usa un modelo para generar combinaciones de opciones rarísimas, que no se darían en una aplicación real, y que luego presenta cualquier discrepancia menor como una vulnerabilidad.
Quien tenga dudas sobre la gravedad de lo que ha encontrado puede seguir enviándolo por HackerOne y el proyecto le dirá en qué cajón lo pone. Lo que cambia es el destino por defecto de lo leve. La política de seguridad del proyecto está, como siempre, en la documentación de curl.
Por qué importa
Lo interesante aquí no es curl. Es la asimetría.
Generar un informe de vulnerabilidad plausible cuesta hoy treinta segundos y céntimos. Evaluarlo cuesta lo que cuesta: leer el código, reproducir, entender si esa combinación de opciones existe en el mundo real, escribir la respuesta. Una hora larga de alguien que sabe. Cuando el coste de producir se derrumba y el de verificar no se mueve, el sistema revienta por el lado del verificador. Siempre. Lo hemos visto con el correo, con los comentarios de los blogs, con las tiendas de aplicaciones, y ahora le toca al triaje de seguridad del software que lleva tu coche, tu router y la mitad de tus contenedores.
Si mantienes un proyecto abierto, la lectura práctica es que el buzón privado de seguridad ha dejado de ser gratis. Era una cortesía razonable cuando llegaban cinco informes al mes. Con doscientos, es un canal que te obliga a responder en privado, en plazo y con cuidado, sin que nadie más pueda ayudarte. Abrirlo para lo leve es, literalmente, repartir el trabajo: más ojos valorando, más gente escribiendo el parche, más probabilidad de que alguien vea un problema parecido antes de la siguiente versión.
Y si tú solo consumes curl —que es lo más probable, porque lo consumimos todos—, hay una consecuencia operativa desde el 26 de octubre: parte de lo que antes te llegaba empaquetado como aviso ordenado ahora vive en una incidencia pública. La severidad que pone el proyecto es la severidad para el proyecto. Un «bajo» en curl puede ser un «alto» en tu montaje concreto, con tus opciones y tu superficie expuesta. Esa traducción la has hecho siempre tú, solo que hasta ahora no se notaba.
Qué no cambia
Stenberg es honesto con los límites, y conviene repetirlos. Tratar un informe en público no reduce el trabajo por informe: lo reparte, y hace que las conclusiones y la documentación sean más fáciles de encontrar después. En teoría. Él mismo lo dice así.
La pega gorda es la otra: publicar antes de que exista el parche le da al atacante una ventana. Por eso la medida se limita a lo que está por debajo de grave —son problemas que, en sus palabras, al menos no son terribles—. Es un peaje asumido, no un detalle que se les haya pasado.
Tampoco es el fin del mundo del software libre ni «la IA ha roto curl». Muchísimos proyectos llevan toda la vida discutiendo sus fallos menores en abierto; curl era de los raros por llevar prácticamente todo por canal privado. Lo que ha cambiado no es el modelo, es el volumen.
Nuestra lectura
Me parece bien, y además me parece tarde. Pero lo que celebro no es la transparencia: es el cambio de incentivos.
Mandar un informe flojo a un buzón privado no te cuesta nada. Tu nombre no sale, tu fallo no se ve, y si cuela te llevas la mención. Mandarlo a una incidencia pública sí tiene precio: queda escrito, con tu usuario al lado, y cualquiera puede leer que lo que has traído es un caso de laboratorio que no le pasa a nadie. Eso filtra. No por censura, por vergüenza —que es el mecanismo que ha sostenido al software libre desde el principio—.
Donde creo que esto envejece mal es en el reparto. La promesa de «más ojos» se cumple cuando hay comunidad que mira, y curl la tiene. En un proyecto de dos personas, abrir el triaje no reparte nada: solo te añade la gestión del hilo público encima del trabajo que ya tenías. Si la avalancha sigue —y Stenberg dice que no ve el final—, el siguiente paso no va a ser más transparencia, va a ser poner una barrera de entrada: reputación previa, depósito, invitación. Apuesto a que lo veremos en algún proyecto grande antes de un año, y se va a montar un escándalo del que luego nadie se acordará.
Y una cosa más, para quien dirige equipos y no mantiene nada abierto: esto ya está llegando a tu buzón de seguridad corporativo. Informes correctísimos de forma, generados en bloque, sobre cosas que no te afectan. La respuesta no es contratar a alguien para leerlos todos; es decidir de antemano qué te importa y escribir en qué casos ni contestas.
Nosotros, cuando montamos vigilancia de vulnerabilidades para un cliente, el trabajo nunca está en recibir el aviso: está en decidir si le afecta de verdad con la versión y la configuración que tiene puestas. Ese paso no lo automatiza nadie todavía, y es el que te come las horas.
La noticia original, en The Register.
Cualquier duda me dices y lo vemos.
Un saludo, Vicente.