Defending Code Reference Harness - framework open source de Anthropic para descubrir y corregir vulnerabilidades con IA
(github.com/anthropics)- Defending Code Reference Harness es una implementación de referencia para realizar descubrimiento y corrección autónoma de vulnerabilidades con Claude, y es un proyecto construido a partir de aprendizajes obtenidos al colaborar con equipos de seguridad de varias organizaciones
- Este repositorio no es un producto, sino una implementación de referencia; actualmente no recibe mantenimiento ni acepta contribuciones
- Anthropic ofrece como alternativa administrada Claude Security, que puede encontrar y corregir vulnerabilidades en el código fuente de varios proyectos y gestionar el ciclo de vida de triage, validación de correcciones y generación rápida de fixes
- Las skills para Claude Code ofrecen
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customize, y permiten definir el alcance de forma interactiva, hacer escaneos, triage y aplicar parches harness/es un pipeline autónomo de referencia con el flujo recon → find → verify → report → patch, y está orientado a la exploración de vulnerabilidades de memoria en C/C++ usando Docker y ASAN- La estructura general del pipeline de referencia, los prompts y el método de sandboxing se pueden reutilizar, pero no funcionan de inmediato en cualquier codebase; es necesario portarlos con
/customizesegún el lenguaje, detector y tipo de vulnerabilidad /quickstart,/threat-model,/vuln-scan,/triagey/patchpara resultados estáticos solo realizan lectura y escritura de archivos, por lo que pueden ejecutarse sin sandbox en Claude Code si se revisa y aprueba el uso de cada herramienta- El pipeline autónomo de referencia y
/patchsobre los resultados del pipeline ejecutan el código objetivo, por lo que se niegan a correr fuera del sandbox de gVisor a menos que se eluda explícitamente esa restricción - Para ejecutar el pipeline, es necesario preparar gVisor y la imagen del agente con
scripts/setup_sandbox.sh, y se requieren Docker y las variables de entornoANTHROPIC_API_KEYoCLAUDE_CODE_OAUTH_TOKEN - Las etapas de ejecución se dividen en build, recon, find, verify, dedupe, report y patch; el agente de find crea entradas malformadas en un contenedor aislado y sigue explorando hasta que el binario con ASAN se cae 3 de 3 veces
- En la etapa de verify, un agente grader separado recibe solo la proof of concept en un contenedor nuevo para reproducir el crash, y en la etapa de dedupe se determina si es un bug nuevo, un mejor ejemplo de uno existente o un duplicado
- En la etapa de report se redacta un análisis estructurado de exploitability que incluye primitive class, reachability, escalation path y severity, y en la etapa de patch se genera una corrección y luego se verifica el build, que la proof of concept original ya no provoque crash, que pasen las pruebas y que no sea fácil encontrar una vía de evasión
- El flujo de uso inicial consiste en crear el threat model y el escaneo estático, triage y candidate patch el Día 1; generar findings validados en ejecución en una librería C/C++ el Día 2; y crear
targets/<your-service>/para tu propio objetivo entre los Días 3 y 5 - Al portarlo a tu propio stack, es necesario definir la señal del finding, la forma de la proof of concept y la forma de build y ejecución; la referencia para C/C++ toma como base la firma de crash de ASAN, el archivo de entrada que provoca el crash y un Dockerfile basado en clang+ASAN
- El triage autónomo y el patching siguen siendo problemas abiertos; aunque la estrategia de validación de
/patcheleva el estándar, la severity y la prioridad dependen de cada entorno, y un parche validado no siempre puede enviarse upstream
1 comentarios
Comentarios de Hacker News
Esto se parece más a un jig de taller. Si quieres, puedes comprar un trineo de corte transversal, pero la mayoría de los carpinteros se lo hacen ellos mismos
Hace 2 años la situación era distinta porque el costo de construir tu propio harness era alto, pero ahora parece mejor ver esto como una fuente de ideas y hacer el tuyo ajustado a tu propia forma de trabajar, interfaz, objetivos y definición del esfuerzo, y forma de notificación
Antes de la IA, hacer software para resolver tu propio problema requería mucho esfuerzo humano, así que uno hacía el trabajo extra de generalizarlo para que otras personas también pudieran reutilizarlo. Ahora casi no cuesta esfuerzo, así que el software se queda sin generalizar
Hoy en día casi no comparto lo que hago[0], porque es poco probable que le sirva a alguien más, y si otra persona necesita algo parecido, puede hacer algo que le quede exactamente a medida en lugar de extender o corregir lo mío. Como un jig
0: https://redfloatplane.lol/blog/17-why-share/ y textos relacionados
En nuestras vidas hay muchas veces en que conviene más construir herramientas de propósito específico, y cada vez que sale un modelo nuevo también aumenta la complejidad de esas herramientas
Estas son herramientas realmente personales. Resuelven problemas que otras personas también podrían tener, pero están tan atadas a la forma de trabajar de cada quien que es difícil explicarlas o adaptarlas para otros. Por eso son jigs de taller
Yo también tendré unas 10 de estas secuencias de comandos y programas hechos a medida, y no sentía algo así desde la universidad. En ese entonces tenía tiempo para personalizar la configuración a gusto, y ahora tenemos agentes
Quisiera enseñárselas a mis amigos, pero cuando trato de recorrer mentalmente cómo explicarlas, siento que no entenderían varias rarezas. Porque son mis rarezas. Son piezas tecnológicas bastante complejas que resuelven muy bien mis problemas, y esos problemas son variaciones personales de problemas más amplios, y al menos por ahora no tengo intención de darles soporte
Es demasiado obvio que vamos en esta dirección, y aun así mucha gente sigue creyendo que el código es cosa de una élite. El código para productos puede serlo, pero fuera de eso, pronto hasta la computadora de nuestros padres va a ejecutar código escrito específicamente para ellos. En seguridad da miedo, pero como idea es fascinante
Además, incluso haciéndolo uno mismo, mis flujos de trabajo de IA que pulí durante meses quedaron obsoletos de inmediato por culpa de ultracode
Creo que en muchas organizaciones cada vez menos usuarios están acudiendo a los equipos encargados de ese tipo de trabajo
El costo de hacer lo propio ya es demasiado barato, y el costo de quedarse atrapado en bloques base de otros es demasiado caro
Pero anclar la codificación con IA a herramientas existentes es increíblemente poderoso
Tengo curiosidad por cuánto cuesta ejecutar esto
Según https://github.com/anthropics/defending-code-reference-harne...:
Quizá hasta por un factor de una cifra
Esta calculadora es bastante impactante: una empresa con 100 desarrolladores podría llegar a unos 2.5 millones de dólares al año en costos de tokens
https://ai-cost-calculator.arnica.io
Pero si lo corres por API, parece que el costo crecería rápido
Es una estimación, así que puede estar equivocada, pero da un rango aproximado basado en nuestra experiencia. Me gustaría recibir comentarios
Pero incluso usando una cifra más alta, podría seguir siendo alrededor de una décima parte del costo de un contrato formal de seguridad para el tipo de hallazgos que buscan estas herramientas. No son resultados que salgan solo de una revisión de PR o de
/security-review; se necesitan expertos que guíen el trabajo previo sobre un framework open source. Ni siquiera estoy contando el tiempo y la demora de averiguar cómo avanzar con uno de esos contratosDicho sin rodeos, si es importante, incluso si un solo escaneo cuesta el presupuesto de un mes de vibe coding, sigue siendo baratísimo en términos de “centavos por dólar”
Al mismo tiempo, esos resultados siguen requiriendo expertos. Las sugerencias pueden ayudar o pueden ser activamente dañinas, y dependen de la calidad del trabajo previo
A un director de TI le recomendaría gastar unos miles de dólares en correr esto, usar la página de resultados aterradora para conseguir presupuesto y luego construir una relación con un red team que pueda encontrar y clasificar vulnerabilidades, ayudar a corregirlas si hace falta y entrenar al equipo interno para que tenga una orientación centrada en la seguridad
“Este repositorio no recibe mantenimiento ni acepta contribuciones.”
Mmm :)
https://github.com/space-bacon/SRT
Podría mejorar mucho todos los modelos frontier de la noche a la mañana. Vamos
Nuestra experiencia es que, sin un buen harness, no se le saca mucho a codex/claude. Y además hay que gastar tiempo y energía en averiguar por qué los agentes de código no pueden encontrar bugs que sí encuentra una persona
Como auditor, cada semana veo bugs que nuestro harness (https://zkao.io/) no detecta, y hay que descubrir técnicas bastante interesantes para hacer que la herramienta sí los encuentre. De lo que se habla aquí es sobre todo de vulnerabilidades criptográficas, no de simples bugs de webapp
Por eso parece razonable que las empresas también tengan su propio harness y paguen por servicios enfocados en construir buenos harnesses a partir de la experiencia. Es probable que las firmas de auditoría que ven muchos bugs y pueden dedicar tiempo a “enseñárselos” a sus harnesses sean las que mejor hagan esto
Por otro lado, la clasificación también necesita técnicas igual de buenas. Si no, aparece lo que yo llamo una auditoría por vibes automatizada, que solo genera suficientes falsos positivos como para cansar todavía más a desarrolladores que ya están hartos de las malas submissions de IA en bug bounty y de las herramientas de IA que revisan todos los PR
Al final, si el harness no devuelve ningún bug, uno termina preguntándose: “¿entonces eso significa que no hay bugs?”. Al final esto vuelve a ser un juego de reputación: elegir la mejor herramienta o el mejor equipo, o sea, el equipo que sabe cuál es la mejor herramienta, y averiguar quiénes son
La seguridad definitivamente es un gran caso de uso de AI/LLM. Porque gran parte del trabajo consiste en hacer coincidir patrones conocidos de problemas de seguridad con texto de lenguaje de programación que es el objeto de análisis, y hacerlo con muchísima precisión
Lo que llama la atención es que, en los casos de uso más potentes, las empresas de IA quieren vender esa técnica como servicio en lugar de vender salidas en bruto. Cuando el valor del output es bajo, venden tokens
Si los tokens de IA fueran de verdad algo casi mágico para crear nuevo valor en el desarrollo de aplicaciones de software en general, no los venderían directamente. Los acumularían y los usarían para dominar el software SaaS de cualquier industria que quisieran
Es parecido a cuando alguien vende cursos caros sobre el mercado bursátil: eso te indica que les conviene más vender el curso que ganar dinero directamente en la bolsa con su propio conocimiento
Para crear productos con tokens de IA tendrían que construir y vender un producto completo, algo en lo que tienen menos experiencia, y además competirían con sus propios clientes. No es una buena posición para un proveedor de IA que todavía se está consolidando. Ya tienen suficiente con su negocio actual; sería una gran distracción y estratégicamente tampoco aporta tanto valor
He operado y vendido un SaaS con un éxito decente, y las partes agotadoras y frustrantes son cosas en las que un LLM no puede ayudar. Escribir el producto no es el cuello de botella ni garantiza el éxito
Incluso si sus tokens fueran realmente mágicos y pudieran entrar en industrias existentes, desplazar a los incumbentes y crecer 100% anual dentro de esas industrias, igual seguiría siendo mejor priorizar la venta de tokens. Porque eso ya es un negocio excelente por sí solo
Lo que esta lógica sí muestra es que hay límites. Los tokens no son tan poderosos como para generar dinero infinito de inmediato en todas las áreas del software. Y eso parece cierto
Al principio muchas empresas prohibían que sus empleados pegaran código fuente en LLM remotos por preocupaciones de seguridad. Ahora muchas empiezan a creer que, por preocupaciones de seguridad, hay que analizar todo el código fuente con LLM remotos
Si se normaliza confiar en Anthropic, podrán vender más servicios que requieren acceso al código fuente
Cambiando un poco de tema, parece que alguien está matando todos los buenos links de GitHub en este post con dead/flag, y no entiendo por qué
Encontrar un solo agujero siempre es más fácil que tapar todos los agujeros. Los hackers también tienen las mismas herramientas, así que esto es una carrera armamentista imposible de ganar
La asimetría que mencionas ya era una propiedad del software incluso antes de los LLM
Bastante interesante. Llevo tiempo construyendo y usando una herramienta parecida:
https://github.com/bobinson/vulture
He sufrido por los falsos positivos, y he estado usando Claude + MCP como una especie de herramienta de auditoría para pobres. En los últimos días he obtenido mejores resultados con modelos hospedados por Nvidia
Hasta saber si Claude usa los tokens de forma eficiente con este harness, puede que no sea tan útil como suena
Está claro que Anthropic ahora está construyendo y productizando harnesses para casos de uso específicos
Vendría a ser el equivalente a Claude Design para seguridad
El harness es distinto, el empaquetado es distinto y la persona objetivo es distinta, así que naturalmente la forma de distribución también cambia
Lo interesante es que, si ves los posts de empresas sobre Mythos, todas están construyendo su propio harness. Cisco incluso publicó la especificación de uno de ellos
Pero quien descubrió cómo empaquetar y distribuir esto fue Anthropic. Es una excelente estrategia de entrada al mercado