ISGroup Consultoría de Ciberseguridad

Devin de Cognition: cómo verificar la seguridad del código producido por agentes de IA

[Callforaction-WAPT]

Devin de Cognition y la ingeniería de software autónoma: cómo verificar el código producido por agentes end-to-end

Devin eleva el nivel de la IA en la programación más allá de los asistentes clásicos. No se limita a completar código o sugerir cambios en un archivo: puede hacerse cargo de tareas de ingeniería completas, trabajar en un entorno en la nube dedicado, utilizar terminales, navegadores y sistemas de archivos, instalar dependencias, ejecutar pruebas, corregir errores y preparar solicitudes de extracción (pull requests).

Para CTOs, gerentes de ingeniería y empresas de software, la pregunta relevante no es solo si Devin produce código funcional. Es entender cómo verificar un resultado generado por un agente que ha atravesado todo el ciclo de la tarea: tickets, repositorios, entornos, comandos, pruebas, registros, integraciones y pull requests. Antes de fusionar (merge) o desplegar (deploy), el punto es concreto: ¿qué ha cambiado Devin en el código, las pruebas, las dependencias, los secretos, las configuraciones, las API y el comportamiento de la aplicación?

Por qué la ingeniería de software autónoma cambia la revisión

Con un asistente tradicional, el revisor suele ver una sugerencia limitada. Con Devin, el resultado puede ser una PR completa: el agente ha planificado, explorado la base de código, ejecutado comandos, modificado archivos, actualizado pruebas, instalado paquetes y verificado su propio trabajo. Esto hace que la revisión sea estructuralmente más difícil, porque el diff final no siempre cuenta toda la historia: no muestra los comandos ejecutados, los errores encontrados, los registros leídos, los datos vistos en el navegador, los paquetes probados y descartados, ni las suposiciones hechas para que la suite de pruebas pase.

Una PR puede parecer lista porque las pruebas son verdes, pero contener una regresión de autorización, una dependencia no aprobada o un mecanismo de respaldo permisivo. El riesgo principal no es que Devin se equivoque en el código: es aceptar un ciclo autónomo como si fuera equivalente a una revisión humana completa. El equipo debe poder reconstruir qué sucedió entre el ticket y la PR.

Espacio de trabajo en la nube, terminal y navegador

Devin trabaja como un agente autónomo en un entorno dedicado. La documentación oficial describe su capacidad para escribir, ejecutar y probar código; la versión empresarial habla de espacios de trabajo con shell, navegador y editor de código, y de modelos de despliegue con componentes en la nube y devboxes. Esta arquitectura es útil porque el agente puede continuar el trabajo incluso cuando el desarrollador no está presente, pero también es una superficie que debe gobernarse con cuidado.

Un comando de shell puede instalar paquetes, leer variables de entorno, modificar archivos, lanzar migraciones, ejecutar pruebas, iniciar servicios o interactuar con CLI en la nube. El navegador puede ver paneles, pantallas internas, datos de prueba, herramientas de monitoreo y flujos de aplicaciones. Antes de usar Devin en repositorios corporativos, se debe decidir explícitamente a qué entornos puede acceder. Cuentas de prueba, datos sintéticos, repositorios en listas blancas y secretos limitados reducen el riesgo; los secretos de producción, los paneles con datos reales, las API en vivo y los entornos en la nube sensibles no deberían estar disponibles por defecto.

PRs agénticas: la prueba verde no es suficiente

Devin puede generar PRs que resuelven tickets, errores o tareas de backlog. La PR es el punto donde el equipo retoma el control, y si ese control se limita a verificar que el código compile y las pruebas pasen, el valor de la autonomía se convierte también en su punto débil.

Las áreas que deben verificarse manualmente incluyen autenticación, autorizaciones, aislamiento de inquilinos (tenant isolation), API, middleware, validación de entrada, manejo de errores, registro (logging), secretos, dependencias, tuberías (pipelines) y configuraciones de despliegue. Una modificación que corrige un error de inicio de sesión puede desplazar un control al frontend; un arreglo en una API puede aceptar un parámetro del lado del cliente que antes se derivaba del servidor; una prueba generada junto con el código puede confirmar el nuevo comportamiento en lugar de desafiarlo. Cada PR generada por Devin en áreas sensibles debe tener revisores explícitos, protección de ramas, pruebas negativas y una lectura del diff por conjunto de cambios. Si la modificación expone una aplicación web o una API, el comportamiento real debe probarse con un enfoque WAPT, no solo con pruebas unitarias.

Autorizaciones y lógica de negocio

Muchas vulnerabilidades introducidas por agentes autónomos no rompen la funcionalidad: la aplicación sigue haciendo lo que el ticket pedía, pero pierde una restricción. Un usuario puede leer datos de otro inquilino, un rol puede llamar a una ruta no prevista, un flujo de trabajo puede saltarse un estado, una validación del lado del servidor puede considerarse duplicada y eliminarse.

Por esto, la revisión de una PR de Devin debe incluir casos de abuso. Una cuenta con privilegios bajos debe intentar llamar a endpoints administrativos; un usuario de otro inquilino debe intentar leer o modificar registros que no le pertenecen; una invitación caducada debe intentar reutilizarse; una solicitud fuera de secuencia debe intentar alterar el estado de un pedido, un trámite o un flujo de trabajo. La lógica de negocio no siempre es visible para los escáneres automáticos: se requiere una lectura del dominio. ¿Qué operaciones requieren aprobación? ¿Qué datos están separados por cliente, rol, grupo o país? ¿Qué condiciones no deben ser controlables por el cliente?

Secretos en el flujo de trabajo autónomo

Cuando un agente trabaja end-to-end, los secretos pueden aparecer en varios puntos: repositorios, archivos .env, historial de shell, registros de pruebas, salidas de compilación, prompts, comentarios de código, descripción de la PR, artefactos de CI/CD, navegador y herramientas de monitoreo. La documentación empresarial de Devin indica el uso de una función de Secretos para compartir credenciales cuando sea necesario, pero esto no elimina el riesgo de la aplicación: el código generado puede imprimir un valor, pasarlo al frontend, incluirlo en una prueba o copiarlo en un archivo de ejemplo.

Antes de la fusión, se requiere un escaneo de secretos en el diff y en el historial relevante. Si una clave ha terminado en un prompt, registro, artefacto o PR, debe rotarse. Los accesos concedidos a Devin deben limitarse a la tarea: tokens de desarrollo, alcances mínimos, repositorios y entornos separados, sin secretos de producción a menos que sea estrictamente necesario y esté aprobado.

Dependencias, scripts y cadena de suministro

Un agente autónomo que quiere cerrar un ticket puede agregar librerías, actualizar archivos de bloqueo (lockfiles), cambiar scripts de compilación o instalar herramientas para reproducir un error. Esto puede ser correcto desde el punto de vista funcional, pero arriesgado desde el punto de vista de la cadena de suministro. Cada modificación en package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, lockfiles o scripts postinstall debe revisarse: es necesario entender por qué se introdujo la dependencia, si se mantiene, qué licencia tiene, qué dependencias transitivas trae, si existen vulnerabilidades conocidas y si los scripts ejecutan código no previsto.

La revisión de dependencias es especialmente importante cuando Devin resuelve errores de compilación o pruebas, porque en esos casos el agente puede elegir el camino más rápido: reemplazar una librería, bajar una versión, deshabilitar un control o agregar un paquete auxiliar. El equipo debe decidir si esa elección es aceptable para el producto, no solo si resuelve el problema inmediato.

Integraciones: GitHub, Slack, Linear, Datadog, AWS

Devin puede insertarse en el flujo de trabajo del equipo a través de herramientas de tickets, repositorios, chat y monitoreo, haciendo natural delegar tareas desde Linear o Jira, comentar en Slack, abrir PRs en GitHub o GitLab, consultar registros e intervenir en problemas reales. Cada integración, sin embargo, amplía el contexto y los permisos disponibles para el agente.

Una integración de GitHub demasiado amplia puede dar acceso a repositorios innecesarios; un hilo de Slack puede contener datos de clientes o tokens; una herramienta de observabilidad puede mostrar payloads sensibles, seguimientos de pila (stack traces), encabezados, consultas o endpoints internos; un acceso a AWS puede permitir modificaciones en recursos no relacionados con el ticket. La configuración de las integraciones debe seguir el principio de menor privilegio. Repositorios en listas blancas, canales dedicados, permisos de solo lectura donde sea suficiente, tokens separados por entorno y control periódico de accesos reducen el riesgo significativamente.

Despliegue, tuberías y configuraciones

Devin puede usarse para arreglar CI, actualizar Dockerfiles, corregir configuraciones, modificar tuberías o preparar despliegues. Estas modificaciones no son neutrales: cambian cómo llega el código a producción. Una PR que “arregla la tubería” puede ampliar permisos, exponer secretos en los registros, deshabilitar pasos de seguridad, cambiar la protección de ramas, hacer más permisivo un Dockerfile, modificar variables de entorno o saltarse pruebas. Un arreglo en el despliegue puede introducir modo de depuración, CORS abierto, errores detallados o falta de límites de tasa (rate limit).

Las modificaciones a CI/CD, contenedores, IaC, configuración de la nube, variables de entorno, secretos, indicadores de funciones (feature flags) y scripts de despliegue deben tener una revisión separada. Si la tarea toca la nube, la red, IAM, buckets, bases de datos o tuberías, el perímetro sale de la simple revisión de código y puede requerir una Evaluación de Seguridad en la Nube o una Revisión de Arquitectura Segura.

Pista de auditoría: reconstruir el porqué, no solo el qué

En la ingeniería de software autónoma, el diff final no es suficiente. Se necesita una pista de auditoría que conecte tickets, prompts, sesiones, comandos, pruebas, registros, errores, PRs y aprobaciones: sin esta cadena, es difícil entender por qué el agente eligió una solución y qué alternativas descartó. La pista de auditoría también es útil para la respuesta ante incidentes: si una vulnerabilidad llega a producción, el equipo debe poder entender qué tarea la introdujo, qué controles pasaron, quién aprobó la PR, qué pruebas faltaban y qué datos o secretos estaban disponibles para el agente.

Conservar registros y trayectorias no significa acumular datos sensibles. Significa definir qué registrar, cómo redactar los secretos, quién puede acceder a los registros de auditoría, cuánto tiempo mantenerlos y cómo usarlos para mejorar las políticas con el tiempo.

Lista de verificación antes de la fusión

PR, diff y pruebas

  • Revisa la PR por conjuntos de cambios pequeños y verificables.
  • Controla las pruebas agregadas o modificadas y verifica que incluyan casos negativos, no solo el camino feliz.
  • Si el agente ha actualizado instantáneas (snapshots), mocks o pruebas para que la suite pase, lee esas modificaciones con atención.

Comandos y entorno

  • Controla los comandos de shell ejecutados, los paquetes instalados, los scripts lanzados, las migraciones, las compilaciones y las pruebas.
  • Verifica que el entorno no tuviera secretos de producción o accesos a sistemas reales no necesarios.
  • Si se han usado navegadores o paneles, asegúrate de que no se hayan expuesto datos sensibles.

Autenticación, datos y API

  • Prueba autorizaciones del lado del servidor, roles, aislamiento de inquilinos, IDOR/BOLA, endpoints no visibles en la interfaz, tokens caducados, entradas maliciosas y abuso de lógica de negocio.
  • Las áreas modificadas por Devin no deben aceptarse solo porque el ticket aparece como cerrado.

Secretos y dependencias

  • Ejecuta escaneo de secretos en el diff, registros, artefactos y el historial relevante.
  • Rota lo que haya sido expuesto.
  • Revisa nuevas dependencias, lockfiles, scripts de instalación/compilación/prueba, licencias y vulnerabilidades conocidas.

Tuberías y despliegue

  • Controla Dockerfiles, CI/CD, protección de ramas, secretos en tuberías, variables de entorno, feature flags, IaC, configuración de la nube y scripts de despliegue.
  • Cada modificación que incida en el camino hacia producción debe tener un propietario y una aprobación dedicada.

Cuándo basta una revisión interna y cuándo se necesita una verificación independiente

Una revisión interna puede bastar si Devin ha trabajado en tareas no expuestas, sin datos reales, sin autenticación, sin dependencias nuevas, sin tuberías y sin integraciones operativas. Incluso en ese caso, el equipo debería conservar el diff, las pruebas y los comandos principales.

Se necesita una verificación independiente cuando Devin ha modificado autenticación, autorizaciones, API, datos, dependencias, secretos, tuberías, nube, despliegue o lógica de aplicación crítica. También es necesaria cuando las PRs agénticas entran de forma estable en el ciclo de desarrollo y el equipo debe definir políticas, protección de ramas, revisores, registro, manejo de secretos y umbrales de riesgo. El punto no es ralentizar a Devin: es separar lo que puede delegarse de lo que debe verificarse.

Cómo ISGroup puede verificar el código y el flujo de trabajo producidos por Devin

El control cambia según lo que Devin haya modificado. Si el riesgo está en la PR, en el código de la aplicación, en la lógica de autorización, en los secretos o en las dependencias, la Revisión de Código ayuda a identificar vulnerabilidades y regresiones antes de la fusión. Si el resultado es una aplicación web o API expuesta, el Test de Penetración de Aplicaciones Web verifica el comportamiento real desde el exterior.

Si Devin ha tocado… Riesgo principal Control recomendado
PR, código de aplicación, middleware, auth, roles, dependencias Vulnerabilidades o regresiones en el código Revisión de Código
Aplicación web, API, rutas públicas, flujos de usuario expuestos Comportamientos abusables desde el exterior Test de Penetración de Aplicaciones Web
Tuberías, despliegue, configuración de la nube, IaC, secretos en CI/CD Configuraciones erróneas o privilegios excesivos Evaluación de Seguridad en la Nube
Arquitectura, límites de confianza, integraciones, datos sensibles Suposiciones arquitectónicas débiles Revisión de Arquitectura Segura
Uso continuo de Devin en el ciclo de ingeniería Controles no repetibles en PRs agénticas Ciclo de Vida de Aseguramiento de Software

La elección del control depende de lo que realmente ha cambiado: código, comportamiento expuesto, tuberías, integraciones o proceso de desarrollo. Antes de la puesta en marcha (go-live), conviene delimitar ese perímetro y verificar el riesgo efectivo en la aplicación.

Evidencias a preparar antes de la revisión

Antes de involucrar a un equipo externo, conviene recopilar tickets, PRs, ramas, diffs, pruebas, comandos ejecutados, registros disponibles, dependencias agregadas, configuraciones modificadas, lista de repositorios accesibles, integraciones activas y descripción de los entornos usados por Devin. También son útiles las informaciones sobre secretos concedidos al agente, políticas de protección de ramas, revisores involucrados, CI/CD, scripts de despliegue, configuración de la nube, datos tratados, sistemas de monitoreo consultados y decisiones ya tomadas sobre riesgos aceptados o remediaciones planificadas.

Preguntas frecuentes

  • Devin prueba su propio código: ¿es suficiente para ir a producción?
  • No. Las pruebas del agente pueden confirmar que el ticket se ha resuelto, pero no demuestran por sí solas que las autorizaciones, la lógica de negocio, los secretos, las dependencias y las configuraciones sean seguros.
  • ¿Cuál es el riesgo principal de las PRs generadas por Devin?
  • Aceptar una PR porque está completa y pasa las pruebas, sin reconstruir los comandos, dependencias, decisiones e impacto en la autenticación, API, datos y tuberías.
  • ¿Puede Devin gestionar secretos de forma segura?
  • Puede ofrecer mecanismos dedicados para compartir credenciales, pero el código generado puede registrar, copiar o exponer secretos de todos modos. Es necesario controlar el uso, el alcance, la rotación y los artefactos.
  • ¿Cuándo se necesita el Ciclo de Vida de Aseguramiento de Software?
  • Cuando Devin se convierte en parte estable del ciclo de ingeniería: los tickets, PRs, revisiones, CI/CD, despliegues y remediaciones deben tener reglas repetibles, no decisiones caso por caso.
  • ¿Cuándo se necesita el Test de Penetración de Aplicaciones Web?
  • Cuando el código producido o modificado por Devin expone aplicaciones web, API o flujos alcanzables por usuarios externos, clientes, socios o empleados.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

In

, , ,