¿CON QUÉ IA?A quién le sirve. Equipos de desarrollo con una aplicación propia, como una tienda online, un SaaS o una herramienta interna, que quieren revisar su código en busca de fallos de lógica y de autenticación.
Qué hicieron
Agentes en paralelo cogen cada uno un tramo del código y razonan entre archivos para buscar fallos de lógica de negocio, saltos de autenticación encadenados y vías de ataque entre servicios. Devin junta después los hallazgos en rutas de ataque completas y reproduce cada una en un entorno aislado. Cuando una vulnerabilidad queda confirmada, escribe el parche y abre una pull request (propuesta de cambio) para revisión. Los perfiles de análisis se pueden generar a partir de documentos de modelado de amenazas que ya existan.
Cómo salió
En la prueba propia de Cognition, con 50 vulnerabilidades, Devin Security logró un 72 % de recuperación a 90,23 $ por ejecución, frente al 68 % de Claude Security a 131,87 $. Es una prueba del proveedor, no independiente.
Conviene saber
El primer análisis completo marca la base. Los siguientes solo revisan el código cambiado, así que el coste baja con el tiempo, y el tamaño del lote por perfil controla la profundidad y el coste.
Qué necesitas
- Acceso a Devin con su función de seguridad (Devin Security), que es de pago
- Un repositorio de código (la carpeta del proyecto con su historial) que quieras revisar y permiso para conectarlo
- Un entorno aislado de pruebas donde confirmar los fallos, nunca producción
- Documentos de modelado de amenazas, si los tienes, porque sirven para generar los perfiles de análisis
- Un desarrollador o responsable de seguridad que revise los hallazgos y las propuestas de arreglo
Cómo hacerlo tú, paso a paso
- Prepara un entorno de pruebas aislado, separado de producción, con una copia del código y datos falsos.
- Conecta el repositorio a la herramienta y, si tienes documentos de modelado de amenazas, úsalos para generar los perfiles de análisis.
- Pega el prompt de la ficha con el nombre del repositorio.
- Deja que la herramienta divida el código en tramos, busque fallos de lógica y de autenticación y junte los hallazgos en rutas de ataque.
- Mira qué hallazgos ha confirmado en el entorno aislado y lee la reproducción de cada uno.
- Revisa cada pull request de arreglo (una propuesta de cambio) antes de aceptarla. Que un desarrollador compruebe que el parche resuelve el problema sin romper otra cosa.
- En las siguientes ejecuciones solo se revisa el código cambiado. Ajusta el tamaño del lote según la profundidad y el coste que quieras.
Revisa mi código [nombre del repositorio] en busca de fallos de lógica de negocio y de saltos de autenticación o autorización. Divídelo en partes y examina cada una. Intenta confirmar cada sospecha en un entorno aislado, nunca en producción. Habrás terminado con una lista ordenada de hallazgos confirmados y una pull request en borrador con un arreglo para cada uno. No fusiones nada ni toques sistemas en funcionamiento.
Consejos
- No ejecutes nada en producción. El prompt exige un entorno aislado para confirmar fallos y no tocar sistemas en funcionamiento.
- Los datos de rendimiento son del propio proveedor y no son independientes. Compara con tus propias pruebas.
- Empieza por los hallazgos confirmados y más graves.
Preguntas frecuentes
¿Puede romper mi aplicación?
No debería, porque confirma los fallos en un entorno aislado y solo abre una propuesta de arreglo que alguien revisa. Aun así, no le des acceso a producción.
¿Es mejor que un escáner de seguridad normal?
Hace otra cosa: razona sobre la lógica del negocio entre archivos y servicios, y confirma los fallos. Los escáneres clásicos siguen siendo útiles, y la comparación que da el proveedor no es independiente.
Fuentes
En el directorio desde el 3 de octubre de 2026.
@prpatel05 en DEV