Cómo funciona
De un enlace a un repositorio a hallazgos verificados
El proceso reproduce el que Anthropic describió para su OSS Scanner: modelo de amenazas, auditoría, doble comprobación, causa raíz y parche, con modelos Claude de vanguardia disponibles a través de una API pública.
- 1
Clonación segura
Obtenemos la rama que has solicitado mediante un git clone superficial, con filtrado de blobs y a través de HTTPS. Los hooks de Git están desactivados, los enlaces simbólicos se extraen como archivos normales y se rechaza cualquier transporte que no sea HTTPS. Se bloquean las direcciones de redes privadas, por lo que no se puede dirigir el escáner a hosts internos.
Nunca se ejecuta nada del repositorio: ni compilaciones, ni instalaciones de paquetes, ni pruebas. El checkout se elimina cuando termina el análisis.
- 2
Inventario y clasificación de riesgos
Se enumera cada archivo de código fuente de texto junto con su lenguaje y tamaño. Se omiten el código incluido de terceros, los archivos generados, los paquetes minificados y los archivos de bloqueo. Cada archivo recibe una puntuación de riesgo según los puntos de uso peligrosos —copias de memoria, ejecución del shell, deserialización, construcción de SQL, renderizado de plantillas, unión de rutas, código criptográfico y de autenticación— y las rutas críticas, como analizadores, controladores de protocolo y enrutamiento de solicitudes.
- 3
Modelo de amenazas
Si el repositorio contiene .oss-scanner/threat_model.md (el mismo archivo que lee el escáner de Anthropic), SECURITY.md o un modelo de amenazas que hayas proporcionado al inscribirte, el escáner lo sigue. De lo contrario, un modelo lee el README, la estructura de directorios y los archivos de mayor riesgo, y redacta uno: qué es el proyecto, dónde entra la entrada no confiable y qué queda fuera del alcance.
El modelo de amenazas también selecciona los archivos prioritarios, para que la auditoría dedique sus recursos al código al que un atacante puede acceder realmente.
- 4
Auditoría
Los archivos de mayor riesgo se agrupan en lotes grandes con números de línea y se envían a un modelo de razonamiento junto con el modelo de amenazas. Busca problemas que un auditor humano meticuloso señalaría:
- seguridad de memoria: desbordamientos, uso después de liberar, truncamiento de enteros
- inyección: SQL, comandos, plantillas, recorrido de rutas, SSRF
- lógica de autenticación, autorización y gestión de sesiones
- deserialización insegura y confusión del analizador
- uso indebido de la criptografía y gestión de secretos
Los análisis rápidos usan Claude Haiku con un presupuesto moderado. Los análisis profundos de proyectos inscritos usan Claude Sonnet y leen hasta cuatro veces más código.
- 5
Verificación independiente
Cada hallazgo candidato se envía a un agente verificador independiente con contexto nuevo. Su tarea es refutar el hallazgo: rastrear el flujo de datos, buscar validaciones en otras partes y comprobar si la entrada está realmente bajo el control de un atacante según el modelo de amenazas. Solo se mantienen los hallazgos que confirma o considera probables; el resto se contabiliza como rechazado.
Para los hallazgos que se mantienen, el verificador redacta la causa raíz, un caso de reproducción y un parche candidato mínimo como diff unificado.
- 6
Commit que introdujo el problema e informe
Los duplicados que comparten una causa raíz se agrupan. git blame en las líneas vulnerables identifica el commit más reciente que las modificó —por lo general, el que introdujo el error— para que puedas añadir una etiqueta Fixes: y determinar qué versiones están afectadas.
El informe se guarda con un ID aleatorio e imposible de adivinar. Puedes exportarlo como Markdown para un aviso de seguridad, JSON para herramientas o SARIF 2.1.0 para el análisis de código de GitHub.
Qué no hace el escáner
- No ejecuta tu código, no lo compila ni descarga dependencias.
- No publica hallazgos, no crea incidencias ni contacta con nadie, excepto con los mantenedores inscritos.
- No conserva una copia de tu código fuente después del análisis. Los informes contienen fragmentos breves de las líneas afectadas.
- No garantiza nada: los modelos pasan por alto errores y a veces señalan problemas inexistentes. Un informe limpio no es una certificación de seguridad.
Por qué se bloquean los casos de reproducción
Cualquiera puede pegar el enlace de un repositorio público, aunque no sea su mantenedor. La causa raíz y el parche ayudan a los defensores; una prueba de concepto funcional ayuda sobre todo a los atacantes. Por eso, los casos de reproducción permanecen ocultos hasta que alguien incorpora un archivo de token al repositorio mediante un commit: así demuestra que puede enviar una corrección. Esto sigue las directrices del kernel de Linux, que indican que las pruebas de reproducción de errores encontrados por IA deben compartirse a petición del mantenedor.
En qué se diferencia del OSS Scanner de Anthropic
Anthropic ejecuta su escáner dentro de entornos aislados sin conexión y compila el proyecto con un Dockerfile, lo que permite a los agentes compilar y ejecutar código para confirmar errores de forma dinámica. Usa sus modelos más potentes, incluido Claude Mythos, que no está disponible públicamente. Nosotros analizamos el código de forma estática con modelos Claude disponibles públicamente. A cambio, cualquiera puede usar ossscanner.org en cuestión de minutos, sin solicitar acceso ni necesitar un Dockerfile.