Encuentra, clasifica y remedia vulnerabilidades de seguridad en todos tus repositorios
Security Swarm es el producto de análisis de seguridad y remediación de Devin. Crea un modelo de amenazas adaptado a tu código, investiga y valida posibles vulnerabilidades, y te ayuda a corregir hallazgos mediante pull requests. Puede identificar vulnerabilidades como ejecución remota de código (RCE), inyección SQL, path traversal, server-side request forgery (SSRF), omisiones de autorización, bugs de seguridad de memoria, vulnerabilidades de denegación de servicio y más. Incluso puede identificar cadenas de exploits que abarcan varios archivos.Security Swarm es una orquestación personalizada de Devins que llamamos Agentic MapReduce. Divide tu repo entre varios Devins en paralelo para ofrecer una cobertura amplia y una investigación profunda, a la vez que mantiene el costo bajo, lo que hace que analizar bases de código grandes sea rentable. También evaluamos Security Swarm comparándolo con un conjunto de referencia de vulnerabilidades publicadas de la GitHub Advisory Database.
Requisitos previos
Para ejecutar un análisis:
Tu organización debe tener acceso al repositorio que quieres analizar.
Debes estar autorizado para usar sesiones de Devin.
Necesitas el permiso Use code scans.
Para configurar una programación de Auto Scan, también necesitas Manage code scans y permiso para gestionar automatizaciones.
Si no ves Security en la barra lateral o no puedes iniciar un análisis, pide a un administrador que revise tu rol. Consulta Acceso y permisos para obtener más información.
Abre Security en la barra lateral izquierda y haz clic en Start scan.
En Single repo, elige un repositorio para analizar.
Asegúrate de que Interactive mode esté habilitado.
Haz clic en Run Scan.
Cuando el modelo de amenazas propuesto esté listo, revísalo y haz clic en Looks good, start scanning o envía comentarios.
A medida que aparezcan hallazgos, revisa la evidencia y atiende los hallazgos que requieran atención.
Para realizar análisis repetibles, crea un perfil que recoja tu ámbito, modelo de amenazas, criterios de gravedad, pasos de validación y restricciones de remediación.
Abre un análisis para ver sus hallazgos. La página muestra una lista de hallazgos a la izquierda, agrupados por gravedad, y a la derecha los detalles del hallazgo seleccionado.Las pestañas de estado muestran un recuento en tiempo real:
Open — requiere atención.
Reviewed — se ha revisado y ya no requiere ninguna acción.
Dismissed — se determinó que era un falso positivo o un duplicado.
Mientras se ejecuta un análisis, la página se actualiza automáticamente a medida que llegan los hallazgos.
Reviewed es un estado del flujo de trabajo, no una confirmación de que se haya integrado una corrección. Un hallazgo puede marcarse como Reviewed manualmente o cuando un análisis posterior determina que ya no está presente.
Gravedad, estado, explotabilidad, nivel de confianza y categoría.
La ruta del archivo y los fragmentos de código afectados.
Una descripción del problema y una recomendación de remediación.
Un resultado de validación del entorno de ejecución, evidencias de respaldo y artefactos de validación.
Pull requests asociados y su estado: abiertos, fusionados o cerrados.
Responsables del código y notas, cuando estén disponibles.
Considera un patrón de código riesgoso como un indicio, no como prueba de una vulnerabilidad. Verifica que el hallazgo trace una ruta alcanzable desde una entrada controlada por un atacante, tenga en cuenta los controles de validación y autorización, y explique un impacto de seguridad concreto.
Inicia una sesión de Devin para corregir el problema y abrir una pull request. La sesión y la pull request resultante quedan registradas en el hallazgo.
Envía contexto a una sesión de feedback que refina el perfil de escaneo para futuros análisis. Por ejemplo, explica que un flujo de datos reportado está protegido por una puerta de enlace interna para que los futuros análisis tengan en cuenta ese control.
Modifica la gravedad del hallazgo, con contexto opcional para Devin. Por ejemplo, reduce la gravedad cuando la explotación requiere acceso interno privilegiado e incluye esa restricción como contexto.
Marca el hallazgo como Open, Reviewed o Dismissed. Mantén un hallazgo en Open mientras requiera alguna acción, márcalo como Reviewed después del triage o descártalo cuando sea un falso positivo o un duplicado.
Un perfil de escaneo define el ámbito del análisis y proporciona orientación para cada etapa. Cada análisis puede usar un perfil. Para evaluar un repositorio con múltiples perfiles de atacante o categorías de amenazas, ejecuta análisis independientes con perfiles distintos.
Un modelo de amenazas específico es una de las formas más eficaces de mantener una cobertura coherente entre análisis. Define el atacante, los activos sensibles, los límites de confianza, los puntos de entrada importantes y las exclusiones explícitas.
Gestiona los perfiles desde la pestaña Profiles en la página Security.
Generar con Devin — describe la aplicación, las amenazas, el ámbito, las exclusiones y los criterios de gravedad en lenguaje natural. Devin redactará el perfil por ti.
Crear manualmente — completa tú mismo cada campo del perfil.
Generar con Devin es un buen punto de partida, pero revisa todos los campos generados antes de usar el perfil. Si dejas en blanco un campo opcional de indicaciones, se aplicará el comportamiento predeterminado de Security Swarm para esa etapa.
Nombre del perfil — nombra la superficie de la aplicación o la categoría de amenaza, en lugar del equipo que realiza el escaneo. Ejemplo: Autorización de API multi-tenant.
Descripción — resume el ámbito del perfil y su objetivo de seguridad. Ejemplo: Encontrar vulnerabilidades de autenticación, autorización y aislamiento entre tenants en la API pública.
Los siguientes ejemplos se combinan en un solo perfil para una API multi-tenant. Adapta los límites, los comandos y los criterios de gravedad a tu aplicación.
Describe al atacante, los activos sensibles, las fronteras de confianza, los puntos de entrada importantes y todo lo que esté explícitamente fuera del ámbito. Esta guía determina las Rules que Devin genera antes de que comience la investigación.
Assume an unauthenticated internet attacker or an authenticated user in one tenant.Focus on public HTTP handlers, OAuth callbacks, API tokens, administrative actions,and accesses to tenant-owned data. Treat internal development scripts and local-onlytools as out of scope. Prioritize authentication bypasses, cross-tenant access, tokenleakage, injection, and SSRF.
Define cómo Devin debe investigar un posible problema y qué pruebas debe recopilar. Pídele que tenga en cuenta las mitigaciones existentes y que distinga las vulnerabilidades explotables de las preocupaciones teóricas.
Trace untrusted input from the route through middleware and service layers to thesensitive operation. Check authentication, authorization, tenant scoping, validation,and escaping at every boundary. Identify the exact reachable path and cite the relevantfiles and lines. Do not report a theoretical issue when an effective mitigation blocksthe path.
Define cómo Devin debe eliminar duplicados y priorizar los hallazgos. Incluye tus criterios de gravedad para que los resultados se ajusten a los estándares de tu organización.
Agrupa los hallazgos que comparten la misma causa raíz. Trata la ejecución remota de código no autenticaday el acceso de escritura entre tenants como críticos. Trata el acceso de lectura entre tenants yla divulgación de credenciales como altos. Trata los problemas de disponibilidad de un solo usuario como medios, a menosque puedan afectar la infraestructura compartida. Etiqueta las recomendaciones de defensa en profundidad como bajas.
Activa la validación del entorno de ejecución cuando Devin pueda compilar y probar la aplicación de forma segura. Explica cómo iniciar la aplicación, crear datos de prueba, autenticarse y demostrar el perímetro de seguridad esperado.
Usa la configuración de desarrollo documentada del repositorio. Inicia la API y crea dostenants que no sean de producción con un usuario de prueba en cada uno. Intenta la solicitudsospechosa como usuario del otro tenant y verifica tanto la respuesta HTTP como los datos persistidos.No llames a servicios de producción ni modifiques datos de producción.
Una validación fallida no siempre descarta un hallazgo. Revisa el resultado de la validación y los artefactos para determinar si una mitigación eficaz bloqueó el exploit o si el Environment configurado impidió que Devin completara la prueba.
La validación del entorno de ejecución inicia una sesión independiente de Devin para cada hallazgo. Consulta Configurar la validación del entorno de ejecución para obtener orientación sobre el Environment.
Activa los informes cuando necesites un resumen como artefacto después del escaneo. Especifica el público al que va dirigido y la información que debe destacar el informe.
Redacta un resumen ejecutivo para los responsables de seguridad e ingeniería. Enumera primero los hallazgos confirmados críticosy de alta gravedad, seguidos de los hallazgos no validados. Incluye los componentes afectados,el estado de validación, el estado del pull request y un plan de remediación priorizado.
Especifica las restricciones que Devin debe seguir cuando le asignes un hallazgo para su remediación. Incluye requisitos de pruebas, de compatibilidad y prácticas que debe evitar.
Prefiere el cambio más pequeño y seguro, y preserva el comportamiento existente de la API pública. Agrega unaprueba de regresión que falle antes de la corrección y pase después. Ejecuta los comandos delint y prueba del paquete afectado. Evita actualizaciones de dependencias de gran envergadura a menos que la vulnerabilidad nopueda corregirse de forma segura sin ellas.
Abre Avanzado para controlar el ámbito de los archivos y los lotes de investigación:
Include globs — limita el análisis a los archivos que coincidan. Por ejemplo, apps/api/** y packages/auth/**.
Exclude globs — elimina los archivos irrelevantes del ámbito seleccionado. Por ejemplo, **/generated/**, **/vendor/** y **/fixtures/**.
Batch size — controla cuántos archivos con señales se agrupan en cada lote de investigación. Déjalo en su valor predeterminado, a menos que estés ajustando deliberadamente el comportamiento del análisis. El rango permitido es de 1–500; el valor predeterminado es 5.
Las exclusiones demasiado amplias pueden ocultar código vulnerable o eliminar el contexto necesario para comprender un flujo de datos. Excluye solo los archivos que tengas la certeza de que son irrelevantes en este perfil.
Los perfiles nuevos tienen ámbito de organización. Más adelante, los admins de Enterprise pueden cambiar la visibilidad de un perfil a Enterprise, para que esté disponible en todo Enterprise.Los perfiles de Enterprise solo pueden ser editados o archivados por admins de Enterprise. Otros usuarios con acceso a Security pueden verlos y usarlos, pero no pueden modificarlos.
Con Interactive mode activado, Devin genera un modelo de amenazas propuesto y se detiene antes de iniciar la investigación. La página de análisis muestra las reglas propuestas y te permite:
Se ve bien, iniciar análisis — acepta el modelo de amenazas y comienza la investigación.
Enviar comentarios sobre el modelo de amenazas — describe qué agregar, quitar o enfatizar, y luego revisa el modelo actualizado.
Usa el Interactive mode en el primer análisis de un repositorio y siempre que su superficie de riesgo o su perfil cambien significativamente. Una vez que el perfil refleje las directrices aprobadas, los análisis de rutina podrán ejecutarse sin esa pausa.
La validación del entorno de ejecución solo se ejecuta cuando el perfil seleccionado tiene habilitada la validación del entorno de ejecución y contiene instrucciones de validación. Dale a Devin suficiente información para compilar, ejecutar, cargar datos iniciales y autenticar la aplicación en su sandbox.Si el repositorio tiene configuración declarativa, Devin puede reutilizar su configuración de compilación e instalación. De lo contrario, agrega los comandos de configuración necesarios a las instrucciones de validación del perfil.
No incluyas credenciales de producción ni valores secretos directamente en las instrucciones del perfil. Usa cuentas y credenciales de prueba que no sean de producción y que ya se hayan proporcionado mediante la Configuración de Environment de tu organización.
Usa la pestaña Todos los repos en el cuadro de diálogo Nuevo análisis para poner en cola análisis de toda una organización:
Opcionalmente, introduce un Filtro de nombre del repositorio.
Opcionalmente, selecciona un perfil de análisis.
Mantén Omitir repos ya analizados habilitado para excluir los repositorios que ya se hayan analizado con el perfil seleccionado.
Haz clic en Vista previa.
Revisa los repositorios que coinciden, deselecciona los que no quieras analizar y confirma.
La vista previa es una simulación. Si cambias el filtro, el perfil o la configuración de omisión, la vista previa deja de ser válida, por lo que no puedes confirmar una lista desactualizada.
El Auto Scan analiza periódicamente los commits incorporados desde el último análisis completado. Puedes configurarlo:
Al iniciar un análisis de un solo repositorio, seleccionando una programación diaria, semanal, mensual o personalizada.
Desde un análisis existente, agregando, editando, deshabilitando o ejecutando de inmediato su programación.
El Auto Scan se implementa mediante una automatización. Para configurarlo, se requieren tanto Gestionar análisis de código como el permiso para gestionar automatizaciones. Los horarios de programación se muestran en tu zona horaria local.
Haz clic en Scan new commits en un análisis completado para investigar los commits agregados desde el último commit analizado. Auto Scan usa el mismo comportamiento incremental, por lo que los análisis posteriores resultan menos costosos que volver a analizar repetidamente todo el ámbito del repositorio.
Después de que la organización complete su primer análisis, la página Security muestra un panel de toda la organización correspondiente a los últimos 7, 30 o 90 días:
Estadísticas de pull requests — pull requests creados, fusionados, abiertos y cerrados, además de la tasa de fusión.
Hallazgos a lo largo del tiempo — hallazgos agrupados por gravedad en el período seleccionado.
El acceso a Security se controla mediante los permisos de análisis de código en el editor de roles:
Permiso
Qué permite
Roles predeterminados
View code scans
Ver análisis, perfiles, hallazgos y las sesiones de análisis asociadas.
Admin
Use code scans
Iniciar análisis, crear perfiles de organización, enviar comentarios sobre hallazgos, modificar hallazgos, cambiar el estado de los hallazgos y asignar hallazgos a Devin.
Admin
Manage code scans
Archivar o restaurar análisis y configurar las programaciones de Auto Scan.
Admin
Manage account code scans
Promover perfiles de organización al ámbito de Enterprise y editar o archivar perfiles de Enterprise.
Enterprise admin
Iniciar análisis, enviar comentarios y asignar hallazgos a Devin también requiere permiso para usar sesiones de Devin. Auto Scan además requiere permiso para gestionar automatizaciones.De forma predeterminada, los miembros no reciben permisos de análisis de código. Los propietarios tienen todos los permisos, y los administradores pueden otorgar permisos a los miembros mediante roles personalizados.
Para que la comparación sea útil, da a ambos escáneres el mismo ámbito, modelo de amenazas, criterios de gravedad y expectativas de validación. De lo contrario, las diferencias de configuración pueden ocultar las diferencias en sus capacidades subyacentes.Usa perfiles para plasmar los criterios de comparación, el modo interactivo para confirmar el modelo de amenazas generado y la validación del entorno de ejecución para aplicar el mismo estándar probatorio a los hallazgos notificados.
Security Swarm investiga posibles vulnerabilidades en el contexto de tu repositorio, en lugar de informar patrones de riesgo de forma aislada. Devin rastrea los flujos de datos relevantes, comprueba los controles de validación y autorización, y evalúa si el problema tiene un impacto de seguridad concreto.Cada hallazgo incluye un nivel de confianza y evidencia de respaldo. Revisa esa evidencia antes de actuar, especialmente cuando un hallazgo no se ha validado en tiempo de ejecución.
¿Qué evidencia debo revisar en un hallazgo?
Revisa el código afectado, el punto de entrada, el flujo de datos, las mitigaciones existentes, el impacto indicado, la confianza y la explotabilidad. Cuando la validación del entorno de ejecución está habilitada, revisa también el resultado de la validación y los artefactos que lo respaldan.Si la evidencia pasa por alto un control o afirma un impacto no respaldado, usa Feedback para proporcionar el contexto que falta en análisis futuros.
¿Qué aporta la validación del entorno de ejecución?
La validación del entorno de ejecución intenta reproducir un hallazgo compilando y poniendo a prueba la aplicación en un entorno aislado. Una validación exitosa proporciona evidencia más sólida de explotabilidad, mientras que una validación fallida puede identificar supuestos o limitaciones del entorno que requieren una revisión más exhaustiva.La validación del entorno de ejecución es opcional y requiere suficiente orientación de validación para que Devin pueda compilar, ejecutar, inicializar y autenticar la aplicación de forma segura.
¿Cómo encuentra Security Swarm vulnerabilidades que abarcan múltiples archivos?
Security Swarm analiza partes del repositorio en paralelo y combina los resultados en una visión de todo el repositorio. Esto le permite identificar relaciones entre componentes, como cuando un endpoint expone un identificador necesario para explotar otro endpoint.Cualquier hallazgo encadenado que resulte de ello debe seguir identificando las rutas de código relevantes y explicar cómo las distintas condiciones se combinan para producir un impacto concreto.
¿Por qué pueden variar los resultados entre análisis?
Security Swarm usa análisis basados en agentes, por lo que distintos análisis pueden no producir hallazgos ni redacciones idénticos. Un ámbito bien acotado, un modelo de amenazas explícito, criterios de gravedad claros y una orientación de investigación específica ayudan a mantener una cobertura consistente.Captura esos requisitos en un perfil de análisis reutilizable, usa el modo interactivo para revisar el modelo de amenazas propuesto y proporciona feedback cuando un resultado omita contexto importante.
¿Que un análisis se haya completado significa que el repositorio no tiene otras vulnerabilidades?
Ningún escáner de seguridad puede garantizar una cobertura completa. Los resultados dependen del ámbito seleccionado, de la orientación del perfil, del contexto disponible del repositorio y de si los hallazgos pueden validarse en el entorno configurado.Ejecuta análisis independientes para distintos modelos de atacante o categorías de amenazas, mantén los perfiles actualizados a medida que cambie la aplicación y usa Security Swarm junto con tus prácticas actuales de revisión de seguridad y testing.
