Análisis en profundidad · Unos 8 min de lectura
El estudio de Claude sobre 123 bibliotecas delimita las garantías del software, sin hacerlas universales
Anthropic y Theorem presentan pruebas para 239 puntos de entrada de fuzzing en 123 bibliotecas, con supuestos explícitos sobre la máquina y límites sobre lo que demuestran los resultados.
- Publicado aquí
- Fecha de la fuente
- Fuente revisada
En un artículo de investigación del 22 de octubre, Anthropic describe su trabajo con Theorem para generar mediante Claude pruebas de software que comprueba una máquina. El resultado útil es una garantía sobre programas ejecutables seleccionados bajo un modelo definido, no un certificado de que toda una biblioteca o cualquier despliegue sean seguros.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- Los investigadores afirman haber demostrado la ausencia de fallos que provoquen una terminación anómala en 239 puntos de entrada de 123 bibliotecas de OSS-Fuzz, tras corregir los errores encontrados cuando fue necesario, para entradas inferiores a 64 MB y bajo los supuestos indicados.
- El experimento principal trata de programas RISC-V de un solo hilo, enlazados estáticamente con musl, y del comportamiento modelado de Linux. No abarca automáticamente los despliegues habituales en x86 o ARM.
- Otros experimentos con tareas pequeñas comparan los tokens necesarios según el modelo y el uso compartido de pruebas. Los ahorros comunicados corresponden a esos experimentos, no constituyen una garantía general de precio o rendimiento.
Una prueba abarca un punto de entrada en una máquina definida
La unidad de cobertura importa. Un punto de entrada de OSS-Fuzz es una vía que proporciona el desarrollador para introducir datos en un programa y señalar fallos. Anthropic afirma haber completado, en varias semanas, pruebas para 239 de esos puntos de entrada en 123 bibliotecas. Eso no equivale a 239 bibliotecas verificadas por completo ni a todas las rutas posibles de las 123 bibliotecas. El proyecto produjo unos 180 millones de líneas de código de prueba en Rocq; una prueba típica tenía unas 600.000 líneas, mientras que los binarios contenían una mediana de 18.000 instrucciones RISC-V.
La afirmación queda limitada por la ejecución modelada: entradas menores de 64 MB, un presupuesto fijo de memoria, un solo hilo, un ejecutable RISC-V estático enlazado con musl y determinadas respuestas de Linux y distribuciones de memoria. Esas condiciones definen el enunciado matemático. Según nuestra lectura en AISubHub, el denominador de la cobertura y la configuración de compilación son más útiles para evaluar el resultado que la impresionante cifra total de líneas de prueba por sí sola.
El fuzzing se convierte en una afirmación que comprueba un pequeño núcleo
El fuzzing ensaya muchas entradas generadas y puede descubrir un contraejemplo, pero superar esos ensayos no agota el espacio de entradas. Aquí, los investigadores convierten una prueba de fuzzing existente y su ejecutable compilado en una especificación formal. Claude construye un argumento de que la prueba seleccionada no puede terminar de forma anómala con ninguna entrada permitida. Las aserciones ya presentes en una prueba también pueden expresar propiedades relevantes, como recuperar los datos originales después de comprimirlos y descomprimirlos.
El modelo no decide por sí mismo que su prueba sea correcta. Rocq la comprueba frente al enunciado. Por tanto, la confianza se desplaza hacia el enunciado exacto, la semántica de RISC-V y Linux y el comprobador, incluido el hardware y el software subyacentes. Es un objetivo de revisión más reducido que leer millones de líneas generadas, pero sigue siendo una dependencia real. Una prueba válida no puede establecer que un modelo de máquina inexacto describa fielmente un sistema de producción.
Por qué un intento de prueba fallido puede producir una corrección útil
Según los investigadores, los intentos de prueba revelaron errores, entre ellos un problema en un descompresor que requería una entrada de unos 20 MB con una disposición poco habitual, y un fallo en un decodificador de imágenes que necesitaba una entrada de 64 MB y más de 2 GB de memoria. Estos ejemplos explican por qué una búsqueda dominada por entradas pequeñas puede pasar por alto comportamientos relevantes. Son hallazgos comunicados por la fuente, no vulnerabilidades reproducidas de manera independiente por AISubHub.
El proceso podía corregir un programa, regenerar su especificación y después demostrar propiedades del artefacto corregido. La prueba de ese nuevo artefacto no debe presentarse como prueba de la versión original sin modificar. También existe el riesgo de un atajo: un agente podría eliminar comportamientos útiles para facilitar el enunciado de ausencia de fallos. Los autores describen penalizaciones a los parches, incentivos para caracterizar las entradas cuyo comportamiento cambia y auditorías de los parches. Esas salvaguardas abordan una modalidad de fallo; no eliminan la necesidad de revisar si una corrección conserva el comportamiento previsto.
Los ahorros de tokens proceden de dos experimentos distintos
En un conjunto separado de 36 tareas pequeñas de verificación, el artículo afirma que Opus 5.5 demuestra la mitad de las tareas con aproximadamente un 40% menos de tokens que Opus 5. Cada tarea recibió tres intentos independientes de un solo agente, con un presupuesto de cinco millones de tokens por intento, y el gráfico la contabilizaba cuando concluía el primer intento que lograba demostrarla. Es una comparación de un conjunto de tareas y unos presupuestos concretos. El artículo no identifica todos los modelos utilizados en el trabajo más amplio de las 123 bibliotecas, de modo que no debe atribuirse ese trabajo íntegramente a Opus 5.5.
Un experimento con un espacio de trabajo compartido permitió a los agentes reutilizar las pruebas de otros y comunicó un 17% menos de tokens que el trabajo aislado. Su gráfico de 36 pruebas muestra un uso menor de tokens en 30 de las 34 comparaciones con trabajo individual completado; los agentes aislados no terminaron dos tareas. Reutilizar pruebas de inicialización del entorno de ejecución y del detector de errores de memoria ofrece un mecanismo concreto de ahorro. Ninguno de los porcentajes proporciona un coste universal en dólares, una mejora del tiempo transcurrido ni un beneficio de despliegue medido de manera independiente.
Los demás casos estudian distintos tipos de corrección
El artículo también describe un experimento con zlib frente a una especificación derivada de un RFC y utilizando semántica de x86. Es un caso separado, no una prueba de que los resultados principales en RISC-V ya sean aplicables a todo el software x86. Un intérprete en Rust para un subconjunto amplio de Python se comprobó mediante Verus frente a una semántica modelada de CPython, y después se comparó empíricamente con CPython usando más de 1,7 millones de programas generados aleatoriamente.
El 99,95% de comportamientos coincidentes comunicado pertenece a esa comparación empírica. No es una prueba de compatibilidad con cualquier programa Python. La diferencia importa: una prueba demuestra un enunciado formal concreto, mientras que un porcentaje de pruebas describe un experimento sobre una muestra. Combinar estos resultados en una puntuación general de precisión del modelo borraría las diferencias entre especificaciones, herramientas y casos límite pendientes.
La aportación de ingeniería es delimitar mejor la garantía
Los autores reconocen expresamente las lagunas. AddressSanitizer no detecta algunos errores de memoria; el proyecto no cubrió todos los puntos de entrada; ni siquiera todos los puntos de entrada de fuzzing abarcarían todo el comportamiento de una biblioteca o su código muerto. Un programa que llama a la biblioteca también puede utilizarla incorrectamente fuera de los supuestos verificados. Los despliegues comunes usan enlace dinámico, glibc, x86 o ARM, que difieren del experimento principal. Se retienen algunas pruebas para no revelar errores todavía sin corregir, y la hoja de ruta para un ecosistema más amplio sigue siendo una propuesta.
Análisis de AISubHub: un siguiente paso práctico consiste en vincular cada garantía declarada con una compilación exacta, un punto de entrada de prueba, un límite de entrada y un modelo de máquina de confianza, y reevaluarla cuando cambien esos elementos. Esto puede complementar las pruebas y la revisión, no justificar que se eliminen de todo un proyecto. Leímos el artículo y sus figuras necesarias, pero no volvimos a ejecutar las pruebas formales, no auditamos el apéndice externo ni los repositorios publicados, no validamos la seguridad de los parches ni reprodujimos los ahorros de tokens. Los resultados y las expectativas futuras siguen atribuidos a los investigadores.
Por qué importa
Análisis de AISubHub: las pruebas generadas podrían abaratar el establecimiento y la reutilización de una propiedad de software acotada y revisable. El resultado útil es el artefacto verificado y su enunciado exactos, con sus supuestos, no una afirmación general de que la IA haya dejado el software libre de errores.
Límites y disponibilidad
Este texto analiza el relato publicado por los investigadores; no es una auditoría de seguridad ni una reproducción independiente. Siguen siendo esenciales los límites del experimento principal sobre entrada, arquitectura, enlace, memoria y puntos de entrada; no se auditaron el apéndice externo ni el contenido de los repositorios.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.