OSS Scanner: 88% de los hallazgos críticos pasaron la validación de los pentesters

El 8 de octubre de 2026, Anthropic lanzó el OSS Scanner, un servicio gratuito de escaneo de vulnerabilidades para repositorios de código abierto. En la versión inicial, 85 de 97 hallazgos críticos y altos pasaron el estándar de la divulgación coordinada de vulnerabilidades (CVD) de la empresa, lo que da 88%. La muestra la eligió la propia Anthropic, y la revisión quedó en manos de sus pentesters.

Validación independiente no existe aquí, y la salvedad acompaña al número hasta el final de este texto.

El dato interesa porque reordena la lista, no porque la sustituya. La due diligence ya pregunta si el proveedor escanea el código que entrega, y eso sigue valiendo. Lo que agrega la versión inicial, con 88% de los 97 hallazgos críticos y altos pasando el estándar del CVD, es un eje anterior: quién absorbe el triaje de lo que produce el escaneo, y en cuánto tiempo el crítico se convierte en parche.

Anthropic responde a eso sin rodeos. En los seis meses anteriores al anuncio, revisó cerca de 6.000 de los más de 29.000 hallazgos candidatos que produjo el escáner. Casi 5.000 salieron en crudo, para mantenedores que pidieron recibir todo. El triaje que falta de su lado lo absorbe el mantenedor del proyecto abierto, y el comprador de software hereda esa deuda sin verla. Ese puente es lectura de este texto, no lo que la fuente mide: ninguna de las tres fuentes trata de comprador ni de cuestionario de proveedor, y la adopción por proveedores no está medida.

Qué es el OSS Scanner y qué abrió Anthropic

El OSS Scanner es un servicio opt-in que escanea repositorios de código abierto en busca de vulnerabilidades. Los proyectos aceptados reciben escaneos periódicos de los modelos más fuertes de Anthropic, sin costo. Toda la salida la genera un modelo, sin revisión ni triaje humano, y la empresa avisa que los informes pueden estar incorrectos.

El servicio nació de la experiencia de Anthropic con Claude encontrando vulnerabilidades en Project Glasswing, y los modelos incluyen Claude Mythos. La inscripción es un pull request en el repositorio anthropics/oss-scanner, que agrega projects/<proyecto>/project.yaml con el repositorio, el contacto primario y un Dockerfile que prepara el entorno para que un agente offline conduzca la auditoría.

La elegibilidad sigue criterios parecidos a los del OSS-Fuzz: impacto crítico en infraestructura y seguridad, exposición a ataque remoto, dependientes, OpenSSF criticality score, licencia, estrellas y forks. Los proyectos nuevos normalmente no entran. Los forks tampoco, salvo que sean distintos del original y elegibles por cuenta propia.

El filtro es conservador a propósito.

El OSS Scanner no es Claude Security, la oferta comercial que lleva Claude Mythos al ciclo de desarrollo de empresas. El servicio abierto cubre el costo completo del proyecto y aplica harnesses adicionales, más caros en tokens y experimentales, para llegar a bugs más profundos.

Anthropic también ofrece Claude for OSS, con suscripciones Claude Max 20x gratuitas para mantenimiento de proyectos.

88%: la tasa de acierto del OSS Scanner medida por el CVD de Anthropic

Anthropic sometió 97 hallazgos críticos y altos del escáner, de 48 proyectos, a los pentesters que ya revisan el CVD de la empresa. De esos, 85 alcanzaron el estándar del proceso. De los 12 restantes, 11 eran reales pero duplicados y apenas uno era inválido. La fuente no informa con qué criterio se eligieron los 97 dentro de lo que produjo el escáner. Sin ese criterio, el 88% mide la precisión de un conjunto elegido, no la de la salida cruda que llega al mantenedor.

La distinción importa más que el porcentaje. Los 11 no son alucinación: la fuente los describe como reales, pero duplicados de problemas ya conocidos o de otro hallazgo del mismo escaneo. Y parte de esa redundancia es configurable: el threat_model.md opcional acepta instrucción sobre el grado de granularidad de la deduplicación, y sin él el escáner hace suposiciones. Una parte de los duplicados es decisión de quien recibe, no ruido inevitable del modelo. Un solo inválido en 97 hallazgos críticos y altos es un resultado fuerte, y la fuente lo compara con el trabajo anterior de la propia empresa, sin serie de denominador igual.

La curva que envuelve el anuncio viene de afuera. En CyberGym, benchmark académico de descubrimiento de vulnerabilidades, los modelos de lenguaje pasaron de menos de 20% a comienzos del año pasado a más de 85% este año, y la empresa cita esa curva al explicar la calidad de los informes.

La salvedad está en la misma fuente. Algunos mantenedores dijeron que la clasificación de severidad puede estar inflada, o que el escáner entendió mal el modelo de amenaza. Una severidad inflada cambia la fila de corrección, no el hecho de que el bug exista.

Es la misma disciplina de lectura de la investigación de seguridad con modelos de frontera: el número mide lo que el laboratorio eligió medir.

El cuello de botella es humano, y Anthropic lo dice en voz alta

En los seis meses anteriores al anuncio, Anthropic escaneó proyectos importantes, encontró más de 29.000 vulnerabilidades candidatas y revisó manualmente cerca de 6.000. La empresa declara que el cuello de botella es la capacidad humana de validar hallazgos. Casi 5.000 informes se enviaron en crudo a mantenedores que pidieron todo.

La diferencia entre 29.000 y 6.000 es lo que quedó sin revisión. La velocidad es el argumento declarado: los exploits pueden desarrollarse en minutos, así que entregar al mantenedor lo que todavía no se leyó es mejor que retener el hallazgo en la fila hasta que alguien lo abra.

No existe una ventana de 90 días del CVD sobre el hallazgo no validado. La empresa dice que no se siente cómoda obligando al mantenedor a leer cada hallazgo que ella misma todavía no leyó, y el conteo de 90 días solo empieza cuando un humano valida el informe. La política es provisional: Anthropic dice que puede imponer ventana de divulgación a algunos hallazgos de alta severidad cuando gane confianza en el desempeño del escáner, con aviso previo y opción de salida para los proyectos. El costo que la fuente nombra ahí es de atención, no de fila. Casi 5.000 informes que nadie leyó llegan a quien necesita decidir, uno por uno, si lee, sin ninguna revisión humana entre lo que escribió el modelo y la bandeja de entrada del mantenedor. Una alerta ya triada se descarta por la señal; esta llega sin señal.

El costo de la validación vive en el adjunto. Cada informe trae un reproductor autocontenido, la explicación de la falla con bisección cuando es posible y un parche candidato cuando está disponible, según el post de lanzamiento. Es el reproductor el que permite a un pentester convertir la afirmación del modelo en hecho en minutos, y eso es lo que separa lectura de verificación.

Lo que la tabla mide no es diferencia de herramienta, es la distancia entre un informe que pasó por un humano y uno que no pasó: en el crudo hay verificación automática de alcance y doble chequeo, y ningún humano; en el del CVD, el pentester leyó antes de la divulgación.

Dos productos, el mismo modelo: el gratuito gana harness extra, el pago entra en el SDLC

El OSS Scanner no sustituye al CVD, que sigue valiendo para todos, incluido el código abierto. Es una vía rápida opcional, sin revisión humana y sin costo para el proyecto. Claude Security es la oferta comercial que pone Claude Mythos en el ciclo de desarrollo de empresas.

La asimetría que sostiene la fuente es de capacidad, no de precio. La cuenta cambia de dueño. En el servicio abierto, Anthropic cubre el costo completo y aplica harnesses experimentales, más caros en tokens, para llegar a bugs más profundos. Lo que separa a los dos es quién se queda con el trabajo después de que llega el informe.

Los testimonios reunidos por Anthropic muestran que el informe en crudo sirve a quien tiene ingeniero para validar. En wolfSSL fueron 74 informes, todos menos dos válidos, y cinco se convirtieron en CVE, según Todd Ouska, mientras que en curl el escáner ayudó a encontrar una de las peores vulnerabilidades de los últimos años, según Daniel Stenberg. En PostgreSQL, una fracción inusualmente alta de los hallazgos señaló defectos, con correcciones usables casi como estaban, según Noah Misch. En OpenSSL, en cambio, el informe bruto fue tan bueno o mejor que el de personas, con exploit real adjunto, según Anton Arapov.

El número de wolfSSL no confirma ni desmiente el 88%, porque mide otra cosa. Los 74 son todos los informes que recibió la empresa, y “válido” ahí es juicio del mantenedor; el 88% es el estándar del CVD aplicado a 97 hallazgos críticos y altos elegidos por Anthropic. Son reglas distintas.

Los cuatro casos tienen algo en común, y la fuente dice por qué: el servicio es “built for projects that are already able to keep up with verified high/critical vulnerability reports and are now looking to further secure their code”. El servicio está declaradamente diseñado para quien ya logra absorber informes verificados, y la decisión de aceptar un proyecto es holística, caso por caso.

El extremo operativo sigue el mismo diseño: agentes de seguridad y respuesta a incidentes solo reducen riesgo con fila de decisión.

El otro lado: el volumen que nadie pidió

Los proyectos de código abierto vienen teniendo dificultad para seguir el aluvión de informes de bugs generados por IA. La cobertura cita a Linus Torvalds y a Google entre los afectados. Remite a una segunda nota, sobre la pausa del programa de recompensas por bugs de Google en código abierto.

La pausa es un hecho separado, y este texto también lo separa. Nada une a los dos en fuente pública. El problema descrito es de envíos de baja calidad generados por IA.

El punto que interesa es la distancia entre encontrar y corregir. Un escáner que produce más de 29.000 candidatas en seis meses no cambia el riesgo de nadie si el triaje del otro lado sigue igual.

Vale lo mismo para el resto de la cadena de defensa: cuando los agentes de IA escapan de la contención, el costo rara vez está en la alerta que faltó.

Un hallazgo sin dueño es ruido con sello de severidad.

Cuatro preguntas para el próximo proveedor

La due diligence ya sabe preguntar si existe escaneo. Lo que todavía no pregunta es quién responde por los hallazgos. La pregunta siguiente cambia de dueño. Las cuatro preguntas de abajo sirven a cualquier proveedor que declare usar IA en el descubrimiento de vulnerabilidades; cada ítem trae la respuesta que sirve y la que no.

1. Quién hace el triaje de los hallazgos, y con qué criterio. Sirve el nombre de la función responsable, el criterio de severidad y el destino del hallazgo que nadie confirma. No sirve “el escáner prioriza automáticamente”.
2. Cuál es el historial de críticos corregidos, y en cuánto tiempo. Sirve el conteo por trimestre con fecha de corrección. No sirve el número de vulnerabilidades encontradas.
3. El escaneo corre sobre la versión que se me entregó o sobre el repositorio upstream. Sirve la respuesta que distingue el artefacto contratado del árbol público. No sirve “usamos siempre la versión más reciente”. La distinción decide: la FAQ del servicio dice que normalmente no escanea forks, salvo que sean distintos del original y elegibles por cuenta propia. Un proveedor que entrega un fork con parche backportado entrega, por la regla declarada, un árbol fuera del alcance del escaneo.
4. Qué pasa con el informe no validado. Sirve saber quién lo lee, en qué plazo y si entra en la fila. No sirve “nada se pierde”.

Para quien contrata software internacional, entran en la misma mesa de los riesgos y costos en la importación de software, porque la evaluación de proveedor y de contrato rara vez ocurren por separado.

Preguntas frecuentes

¿Qué es el OSS Scanner y para quién es? El OSS Scanner es un servicio opt-in de Anthropic que escanea repositorios de código abierto en busca de vulnerabilidades, con escaneos periódicos de los modelos más fuertes de la empresa y sin costo para el proyecto. Sirve a los mantenedores de proyectos establecidos, no a empresas que consumen software.

¿El número de 88% se validó de forma independiente? No. La muestra de 97 hallazgos críticos y altos la eligió Anthropic, y la revisión quedó en manos de los pentesters del CVD de la propia empresa. Es la tasa de acierto medida por el CVD de la propia empresa, en una muestra que ella eligió, no una auditoría externa.

¿Un informe no validado puede tratarse como vulnerabilidad confirmada? No. La salida es enteramente generada por modelo, sin revisión ni triaje humano, y Anthropic avisa que los informes pueden estar incorrectos o inválidos. La empresa también reporta mantenedores que señalan severidad inflada. Sin ventana de 90 días sobre el hallazgo crudo, el reloj del CVD solo empieza en la validación humana.

¿Cómo usar este dato en la due diligence de software? Sumando pregunta de proceso a la de volumen. Pregunte quién hace el triaje de los hallazgos, el historial de críticos corregidos y en cuánto tiempo, si el escaneo cubre la versión entregada al cliente y el destino del informe no validado.

Referencias y Lectura Complementaria

• Anthropic, An opt-in vulnerability-finding service for open-source software, 8 de octubre de 2026: anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source
• Anthropic Frontier Red Team, OSS Scanner, changelog con el lanzamiento el 8 de octubre de 2026: red.anthropic.com/oss-scanner
• The Verge, Anthropic launches free AI security scans for open-source projects, 8 de octubre de 2026: theverge.com
• Investigación de seguridad con modelos de frontera
• Agentes de seguridad y respuesta a incidentes
• Cuando los agentes de IA escapan de la contención
• Riesgos y costos en la importación de software
• Comprar software en marketplace de nube

Qué hacer con esto

La due diligence no cambia de pregunta, gana un eje. Si el proveedor escanea el código que entrega, eso sigue en la lista. Lo que este texto agrega es quién absorbe el triaje aguas arriba y en qué plazo se corrige el crítico. Las tres acciones de abajo siguen el orden en que aparece el riesgo. Ninguna depende del número publicado.

1. Pida el número de hallazgos críticos corregidos en los últimos doce meses, con fecha, y no el de encontrados.
2. Pregunte quién hace el triaje, con qué criterio y en qué plazo, y pida el nombre de la función, no el de la herramienta.
3. Trate el informe no validado como insumo interno del proveedor, nunca como evidencia entregada a usted.

Eso no dispensa el escaneo.

El límite honesto: ningún dato público dice cuántos proveedores operan así. Lo que existe es el 85 de 97 en la versión inicial del OSS Scanner y la declaración de la propia empresa, leída el 21 de octubre de 2026, de que el cuello de botella es humano.

Nexforce Marketplace reúne soluciones globales de software e IA en moneda local, con factura y compra centralizada. Organiza la contratación, no sustituye la evaluación técnica de seguridad, y las cuatro preguntas caben en la conversación de quien va a comprar software en marketplace de nube.