Cognition lanza Devin Security 2.0 y reparte créditos por cientos de millones

Cognition ha lanzado Devin Security 2.0, un producto que acompaña a una vulnerabilidad desde su detección hasta un pull request verificado. Se apoya en el escaneo guiado con Claude Mythos y otros modelos frontier para ciberseguridad, en la priorización según el modelo de amenazas de cada empresa y en correcciones autónomas. Junto con el lanzamiento, Cognition promete créditos de Devin por cientos de millones de dólares: escaneos gratuitos para los clientes corporativos actuales y futuros, y créditos para que los nuevos clientes reparen sus fallos más críticos.

Por qué la cola de vulnerabilidades importa más que las vulnerabilidades

La compañía justifica el lanzamiento con un episodio reciente. La semana pasada, los proyectos PHP y Node.js revelaron vulnerabilidades de ejecución remota de código, y todas las empresas que usan esos stacks quedaron en la misma situación: una vía de explotación pública, atacantes que leen el mismo advisory y parches que hay que desplegar en imágenes de contenedores, paquetes del sistema operativo, pipelines de CI y configuraciones de infraestructura repartidos en decenas de repositorios.

Por separado, Cognition analiza el exploit PHP2Shell. Los indicios de uno de los problemas de fondo se detectaron ya en 2024, pero los mantenedores no encontraron una vía concreta hacia el RCE. La corrección se atascó por compromisos de compatibilidad, falta de recursos y discusiones sobre el enfoque, y se dio prioridad a bugs más evidentes. Según Wiz, los modelos frontier ayudaron a los investigadores a montar y adaptar en cuestión de horas exploits funcionales para varias aplicaciones. La conclusión es incómoda: en los backlogs puede haber muchos bugs aplazados que la IA ha vuelto prácticos para un ataque.

Por otro lado, la IA también engorda el flujo de entrada. Daniel Stenberg, mantenedor de curl, lo describió como «alto volumen con alta calidad». Según los datos del proyecto a 22 de octubre de 2026, ya hay 356 reportes, frente a 181 en todo 2025. Como comparación, en 2024 llegaron 86 y en 2023, 102.

Cómo funciona el pipeline de Devin Security

El escaneo se basa en la arquitectura Agentic MapReduce, independiente del modelo. Para los repositorios más críticos se conectan modelos frontier; para el resto se puede elegir una opción más barata. El proceso consta de cinco pasos:

• Plan: el agente cruza el repositorio con el modelo de amenazas y escribe reglas para el código sensible: rutas, límites de autorización, acceso a datos, deserialización y llamadas peligrosas a APIs. • Shard: el código seleccionado se divide en grupos. • Map: agentes independientes investigan los grupos en paralelo. • Reduce: se agregan los resultados, se eliminan duplicados y se enlazan los hallazgos que, combinados, forman una cadena de ataque más grave. • Verify: los casos prioritarios se comprueban en un sandbox sobre una instancia en ejecución de la aplicación.

Después, los hallazgos se pueden asignar a Devin de uno en uno o por lotes. Devin los contrasta con el código actual, agrupa los que se resuelven con una misma corrección y lanza sesiones independientes, cada una con su propia máquina virtual. Allí levanta servicios reales, reproduce el problema, escribe un fix puntual, ejecuta el test de reproducción y los tests existentes, y abre un PR con los resultados de la investigación.

El hallazgo sigue abierto hasta que el PR se fusiona y Devin comprueba que la vía de ataque está cerrada. Si la corrección definitiva aún está en preparación y el acceso está configurado, el agente puede poner temporalmente una regla de WAF, cambiar un security group o cerrar el acceso público a un servicio.

Modelo de amenazas en lugar de una sola puntuación CVSS

La prioridad la determinan varias preguntas: si el código vulnerable es alcanzable desde una entrada no confiable, a través de qué límite de confianza, si hacen falta autenticación o una configuración especial y si el código está en uso. A ello se suma qué significa el daño para el negocio: leer datos ajenos, escalar a administrador de la organización o usar el producto sin pagar. Devin reúne las respuestas en un modelo de amenazas junto con el equipo: servicios, hosts, políticas de red, flujos de datos y límites de confianza.

Una parte se lee del código y de las definiciones de infraestructura; otra parte (la región del servicio, o si una herramienta interna es accesible desde internet) no, por lo que el trabajo es conjunto.

La verificación es necesaria incluso con modelos potentes. Según el informe de Anthropic Glasswing, de 1752 hallazgos evaluados inicialmente como high o critical, el 90,6% resultaron ser vulnerabilidades reales, pero solo el 62,4% se confirmó como high o critical. Encontrar un bug y evaluar bien su gravedad son tareas distintas.

El mismo proceso sirve para el material ya acumulado: Devin importa hallazgos de Snyk, Wiz, archivos CSV e informes de bug bounty, y conserva los identificadores y enlaces originales. Las sesiones paralelas los revisan de nuevo con el código actual, buscan duplicados y comprueban si el problema ya se ha resuelto. Las decisiones de cierre y reapertura se sincronizan de vuelta con las herramientas compatibles. También se pueden revisar de nuevo informes antiguos generados por modelos de IA más débiles.

Un escenario aparte es el cumplimiento normativo. Para FedRAMP, PCI DSS y las políticas internas, un hallazgo high o critical inicia la cuenta atrás del plazo de corrección, y el riesgo solo se puede rebajar con documentación. Para cada hallazgo reevaluado, Devin conserva el CVSS original y redacta una justificación en seis ejes:

• alcanzabilidad: si una entrada no confiable puede llegar hasta el código; • autenticación: qué permisos hacen falta; • datos: qué se puede revelar o modificar; • límites de confianza: qué límite habría que cruzar; • validación: qué se probó y qué se observó, incluidos los resultados no concluyentes; • fuente: de dónde procede el hallazgo.

Una persona aprueba la conclusión y la exporta a un POA&M o a un sistema GRC. Devin no reevalúa las vulnerabilidades del catálogo CISA KEV.

Por dónde empezar en un equipo de seguridad

El mínimo práctico es reunir en un solo lugar el backlog acumulado de Snyk, Wiz y bug bounty y volver a verificarlo con el código actual, sin fiarse de las evaluaciones antiguas. En paralelo conviene formalizar el modelo de amenazas: sin él, cualquier prioridad automática sigue siendo una conjetura. En los repositorios críticos tiene sentido lanzar un escaneo con un modelo potente mientras los escaneos gratuitos de Cognition sigan disponibles, y dejar todas las correcciones en manos de la revisión humana.

Cognition cree que la «primera milla» de la respuesta a incidentes pronto se recorrerá sin intervención humana. Alex Stamos, director de seguridad de la compañía, tiene previsto hablar sobre la situación de las amenazas en un encuentro el 26 de octubre a las 10:30, hora del Pacífico.