Bitcoin Core ha revisado su política de divulgación de seguridad para agilizar las correcciones de vulnerabilidades que los modelos de lenguaje de gran escala pueden descubrir con mínimo esfuerzo, eliminando los embargos de meses que esos errores solían tener.

Los mantenedores fusionaron el cambio en la política de seguridad del proyecto el jueves. Antoine Poinsot, desarrollador de Chaincode Labs y autor de la propuesta, lo anunció el mismo día en un mensaje a la lista de correo de desarrollo de Bitcoin.

"Recientemente experimentamos un aumento en la cantidad de reportes de vulnerabilidades de seguridad que pueden ser (re)descubiertas con facilidad", escribió Poinsot. "Esto se debe en gran parte a que los LLM han reducido drásticamente la barrera para encontrar ciertas clases de problemas o identificar correcciones encubiertas".

La revisión convierte la facilidad de descubrimiento, y no solo la gravedad, en un factor para determinar qué tan rápido el software que ejecuta la mayoría de los nodos de Bitcoin recibe una corrección pública.

Cómo funcionaba la política antes

Bajo el marco anterior, Bitcoin Core —el software que se ejecuta en la mayoría de los nodos de la red de Bitcoin— clasificaba cada vulnerabilidad reportada según su gravedad y ajustaba el momento de su divulgación en consecuencia. Los fallos de gravedad baja se hacían públicos dos semanas después del lanzamiento de la siguiente versión principal.

Los problemas de gravedad media y alta permanecían bajo embargo hasta dos semanas después de que la última versión afectada llegara al fin de su ciclo de vida, un período que podía extenderse hasta un año.

Los plazos prolongados estaban diseñados para dar a los operadores de nodos, muchos de los cuales actualizan a un ritmo lento, tiempo para migrar al software corregido antes de que los detalles se hicieran públicos. En la práctica, esto significaba que las correcciones no se publicaban para las versiones antiguas mantenidas y llegaban solo con la siguiente versión principal.

Poinsot argumentó que este compromiso no funciona para errores fáciles de redescubrir. "El período de embargo logra poco pero retrasa la disponibilidad de una versión corregida", señala la política.

Qué cambia

Durante la evaluación, Bitcoin Core ahora puede marcar una vulnerabilidad como "fácilmente descubrible", una categoría que la política define como problemas que se pueden encontrar "con mínimo esfuerzo, como mediante un simple prompt de LLM". La etiqueta también aplica a fallos encontrados por otros medios.

Para esos problemas, el proyecto aplicará la corrección retroactivamente a cada versión principal mantenida, lanzará versiones puntuales lo antes posible y publicará un aviso de seguridad con algunos detalles al mismo tiempo que el software corregido. Poinsot reconoció que dichas correcciones tendrán menos tiempo de prueba antes de llegar a los usuarios. Para los operadores de versiones antiguas mantenidas, esto significa que los parches ahora llegan como versiones puntuales en lugar de esperar la siguiente versión principal, con los detalles publicados en el momento en que se lanza la corrección.

Las vulnerabilidades fuera de esa categoría conservan el cronograma existente basado en la gravedad. Los errores críticos —los que podrían permitir el robo de monedas a nivel de protocolo, inflar la oferta o causar una división permanente de la cadena— permanecen fuera de la política estándar y se manejarán caso por caso.

El desarrollador Antoine Riard propuso una opción para publicar una corrección sin aviso de seguridad y retener los detalles caso por caso. Poinsot rechazó la idea, escribiendo que alertar a los sin detalles "podría crear más riesgo innecesariamente" al impulsar una migración apresurada entre usuarios que de otro modo no se verían afectados.

Un verano de reportes impulsados por IA

El cambio de política se produce tras meses de mayor presión sobre los proyectos de código abierto de Bitcoin. A fines de julio, un grupo voluntario de 16 desarrolladores conocido como Bitcoin Red Team ejecutó modelos de IA en 390 repositorios de bitcoin en aproximadamente un día y registró 4,962 hallazgos, incluidos 85 calificados como críticos.

Días después, un fallo de BTCPay Server que el grupo había reportado de forma privada fue explotado en servidores comerciales en producción, drenando nodos de Lightning.

En agosto, los desarrolladores de Core Lightning pidieron a los operadores actualizar o desconectarse después de que los reportes generados por IA al proyecto resultaran precisos.

El esfuerzo del Red Team siguió a un exploit de la billetera de hardware Coldcard en el que los atacantes drenaron 594 BTC en 25 minutos el 30 de julio. Las pérdidas a lo largo de cuatro barridos rondaron los 114 millones de dólares.

La frecuencia con que se aplique la etiqueta de "fácilmente descubrible" —y qué tan rápido lleguen las correcciones— se verá en los avisos y versiones puntuales de Bitcoin Core de aquí en adelante.

Fuente: Bitcoin Magazine | Escrito por Micah Zimmerman