La campaña de seguridad de IA de Bitcoin encontró 6,700 problemas en 55 horas, pero nadie sabe cuántos son reales

La campaña de seguridad asistida por IA centrada en el ecosistema de Bitcoin, Bitcoin Red Team, informó que generó 6,700 hallazgos en 425 proyectos durante sus primeras 55 horas. La campaña etiquetó 1,029 de ellos como altos o críticos.

La actualización del 6 de agosto mide cuánto material ingresó a un pipeline de triaje de seguridad, y su efecto en la seguridad del software aún no se ha reportado.

El hilo recuperado omitió definiciones listas para auditoría y denominadores para los conteos de severidad, así como resultados a nivel de casos, una tasa de falsos positivos agregada y una tasa de corrección.

Esos campos faltantes impiden calcular cuántas alertas se convirtieron en vulnerabilidades confirmadas, cuántos mantenedores rechazaron o degradaron, y cuántas llevaron a parches.

Las primeras 55 horas aún revelan una capacidad significativa, señalando cómo los sistemas de IA pueden llenar rápidamente un pipeline de revisión a escala de ecosistema. La solicitud experta, la reproducción, la divulgación y la respuesta de los mantenedores siguieron siendo necesarias en cada etapa posterior.

Lo que miden los números de la campaña

La campaña publicó dos instantáneas a medida que su lista y carga de trabajo se expandieron:

La actualización de 27.5 horas cubrió 390 proyectos y 4,962 hallazgos. Para el punto de las 55 horas, el número de proyectos había aumentado en 35 y el número de hallazgos en 1,738. El hilo posterior colocó los hallazgos altos o críticos en el 15.4% del total y aclaró que tres de los 24 participantes reportados eran bots.

La publicación anterior separó hallazgos críticos y altos, mientras que la posterior los combinó, con ambos conjuntos de cifras reflejando las evaluaciones de la campaña. La confirmación de la explotabilidad y los resultados de remediación confirmados por los mantenedores requieren evidencia separada.

Bitcoin Red Team escaneó 425 proyectos y reportó 6,700 hallazgos, incluidos 1,029 problemas altos o críticos, mientras que las tasas de validación pública permanecen no publicadas.

Rob Hamilton describió a Kimi K3 como el encargado del análisis pesado, con GPT Sol, Fable/Opus y GLM 5.2 apoyando la documentación. Dijo que el Cyber Harness de OpenAI cubría componentes seleccionados que consideraba estructurales.

Un día después, Hamilton escribió que los expertos en la materia podían cambiar una evaluación con una o dos oraciones de contexto o un pequeño bloque de código. En los ejemplos que describió, esa entrada empujó preocupaciones medianas a territorio alto o crítico. También identificó operaciones, entrega de divulgación y triaje como cuellos de botella.

En el relato de Hamilton, los modelos buscaron ampliamente mientras los especialistas moldearon solicitudes, interpretaron salidas, intentaron reproducciones y decidieron qué informes estaban listos para la divulgación. Esa división del trabajo convierte a la campaña en un sistema de revisión humano-IA.

El desarrollador conocido como Calle dijo que la mayoría de los informes críticos fueron verificados rápidamente por los propietarios de los proyectos. La publicación no proporcionó denominador, conteo de informes verificados, conteo de rechazos o estado de parches, dejando la amplitud y el resultado de esa verificación sin resolver.

La divulgación y los resultados definen el valor de seguridad

En la actualización de 55 horas, Bitcoin Red Team informó que el 19.5% de los proyectos escaneados tenían un archivo SECURITY.md y el 13.1% tenía un correo electrónico allí. El hilo recuperado omitió el corpus del proyecto, la interpretación del denominador y el método de medición, por lo que los porcentajes solo describen el escaneo de la campaña.

El 3 de agosto, Hamilton dijo que el esfuerzo había gastado más de $10,000 escaneando más de 100 repositorios y había divulgado inmediatamente hallazgos críticos cuando una prueba de concepto demostró la explotabilidad. El 4 de agosto, reportó alrededor de $20,000 en gastos, más de una docena de divulgaciones y 150 repositorios escaneados.

El escaneo continuó expandiéndose, mientras que la campaña describió la divulgación, la entrega y el triaje como restricciones operativas activas. Las instantáneas publicadas no ofrecen un denominador de divulgación comparable a las 55 horas, por lo que no pueden establecer la velocidad relativa de escaneo y resolución.

Hamilton identificó más tarde el incidente separado de Coldcard como un catalizador para la campaña más amplia. El registro de la campaña no atribuye el descubrimiento del fallo de Coldcard a este sprint.

Un informe público útil separaría los hallazgos que fueron reproducidos, reconocidos, degradados, rechazados y corregidos, con definiciones y denominadores para cada tasa. Ese desglose mostraría cuánto del volumen de la campaña se convirtió en trabajo de seguridad accionable.

Un crítico público, JW Weatherman, argumentó que la campaña no podía triar su producción. Su publicación no identificó ningún problema, parche o aviso vinculado a la campaña, por lo que proporciona críticas sin una tasa de fallo medible. La falta de datos de disposición de la campaña deja la pregunta subyacente abierta.

Por ahora, 6,700 representa hallazgos etiquetados por la campaña y candidatos de triaje. El sprint demostró la velocidad de la revisión asistida por máquina. Su valor de seguridad duradero depende de la parte que los expertos puedan validar, divulgar y convertir en correcciones.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.