Bitcoin Core acierta: si una IA encuentra el fallo, el secreto es puro teatro

¿De qué sirve un secreto que cualquier chatbot puede regenerar con una sola instrucción? Esa es, en esencia, la pregunta que Bitcoin Core acaba de responder, y creemos que lo ha hecho bien.

El jueves 22 de octubre, el proyecto incorporó un cambio en su política de seguridad, redactado por Antoine Poinsot, desarrollador de Chaincode Labs. Hasta ahora, Core clasificaba cada vulnerabilidad según su gravedad y programaba la divulgación en consecuencia. Los fallos de gravedad baja se revelaban dos semanas después de que saliera la siguiente versión mayor. Los de gravedad media y alta podían permanecer ocultos hasta dos semanas después de que la última versión afectada llegara al final de su vida útil, una espera que puede alargarse hasta casi un año. Ahora los responsables de mantenimiento pueden etiquetar un fallo como «fácilmente detectable» durante la clasificación. Esa etiqueta cubre un fallo que puede encontrarse con una simple instrucción a un LLM. Para un fallo así se aplica la corrección a todas las versiones que se mantienen, se publica cuanto antes una versión de mantenimiento y se emite un aviso de seguridad con algunos detalles. Los fallos críticos quedan fuera de la política estándar y se tratan caso por caso.

El embargo era una apuesta por la dificultad, y las probabilidades han cambiado

Un embargo largo solo funciona si es poco probable que los atacantes encuentren el agujero por su cuenta. Parchear en silencio da tiempo a los operadores de nodos para actualizar antes de que nadie sepa dónde está la debilidad. El propio diagnóstico de Poinsot, según lo recoge CoinDesk, es que los LLM han reducido «drásticamente» el listón para encontrar ciertas clases de problemas o para identificar correcciones encubiertas. Esa segunda parte es la más infravalorada. Un parche silencioso es en sí mismo una pista, y un modelo sabe leer un diff.

Así que, para este tipo de fallo, el embargo no protege a nadie salvo al atacante, que ya lo conoce. Mientras tanto, los usuarios honestos se quedan con versiones antiguas sin corregir a la espera de una versión mayor. La política lo dice sin rodeos: «El periodo de embargo logra poco, pero retrasa la disponibilidad de una versión corregida».

Las pruebas dicen que esto no es hipotético

Pensemos en lo ocurrido este verano. Un grupo voluntario de 16 desarrolladores, el Bitcoin Red Team, ejecutó modelos de IA sobre 390 proyectos de Bitcoin en aproximadamente un día y registró 4.962 hallazgos, 85 de ellos críticos, según CoinDesk. No todos esos hallazgos se reprodujeron (un informe indica que solo alrededor de una quinta parte en ese momento), así que la cifra debe leerse con esa salvedad. Aun así, a los pocos días se estaba explotando en servidores reales de comercios un fallo de BTCPay Server que el grupo había comunicado en privado. La notificación privada no se adelantó a los atacantes.

El panorama general apunta en la misma dirección. Una nota de investigación de la Cloud Security Alliance sostiene que el modelo clásico de divulgación coordinada, con su ventana habitual de 90 días, se diseñó para investigadores humanos que trabajan a ritmo humano. Vemos la decisión de Bitcoin como un caso concreto de ese argumento.

La transparencia tiene un precio, y merece la pena pagarlo

El cambio no sale gratis. Poinsot admite que las correcciones más rápidas tienen menos «tiempo de maduración» en las pruebas. Es un riesgo real, porque un parche apresurado en un software que protege una red enorme puede salir mal. La alternativa propuesta por el desarrollador Antoine Riard, publicar correcciones sin aviso en algunos casos, fue rechazada, y compartimos el rechazo. Poinsot argumentó que avisar a los usuarios sin dar detalles podría provocar migraciones precipitadas de personas que ni siquiera estarían afectadas. El secretismo a medias te da el pánico sin la información.

También hay una preocupación legítima sobre la propia línea divisoria. Todavía no se ha marcado ningún fallo con la nueva regla, así que, como señala Crypto Briefing, la incógnita es con qué coherencia decidirán los responsables qué es «fácilmente detectable». Una etiqueta vaga podría convertirse en una vía de escape en cualquier dirección. Nuestra opinión es que el criterio es honesto, porque depende de lo fácil que sea encontrar un fallo y no de qué herramienta lo encontró.

Qué deberían aprender otros proyectos

La lección no es «divulgarlo todo de inmediato». Los fallos difíciles de encontrar siguen mereciendo tiempo, y Core mantiene para ellos su calendario según la gravedad. La lección es que la hipótesis de partida se ha invertido. Los proyectos deberían preguntarse ahora si un fallo puede redescubrirse a bajo coste y, de ser así, priorizar la rapidez del parche sobre la discreción. Los proyectos críticos de código abierto con una cultura lenta de actualización son los que más tienen que ganar, porque son los que más pierden con una ventana de exposición larga.

Nuestro veredicto: Bitcoin Core ha dado un paso pragmático y algo incómodo, y es el correcto. Los operadores deben estar atentos a las versiones de mantenimiento y a los avisos, y estar listos para actualizar rápido. Todos los demás que mantengan código muy extendido deberían revisar sus reglas de embargo y preguntarse cuáles siguen protegiendo a los usuarios y cuáles solo protegen la costumbre.