Remediation: del hallazgo verificado al cambio revisado

“Detectar no es corregir”: qué es un cambio revisable y por qué tu equipo conserva el control de la fusión

Un hallazgo te dice que algo está mal. No cambia ni una línea de tu código. Entre una cosa y otra hay un trabajo que los escáneres no hacen. Alguien tiene que escribir la corrección y comprobar que elimina la causa raíz sin romper nada. Después, el cambio tiene que superar la revisión de tu equipo.

Remediation es el paso Remediar de Proof-Driven AppSec. AI Swarm Pentest valida lo que es explotable (módulo 6) y Deep Code Analysis explica cómo afecta una debilidad a tu aplicación (módulo 5). Remediation convierte ese conocimiento en un cambio que tu equipo puede revisar. Empieza por hallazgos que ya hayan pasado por el triage (módulo 4), idealmente respaldados por evidencia, como un hallazgo de pentest confirmado o una ruta de código alcanzable, para que el tiempo de revisión se dedique a riesgos reales.

Qué contiene un cambio revisable

En Plexicus, una remediación de código es un cambio propuesto para uno o varios hallazgos. No es un commit en tu rama principal ni un simple ticket de “por favor, corrígelo”. Tiene cuatro partes:

• Un diff. Las líneas exactas que se añaden y se eliminan, archivo por archivo.
• Una explicación y un título. Los escribe la IA para quien revisa y cuentan qué ha cambiado y por qué. Se convierten en la descripción y el título del pull request.
• Una insignia de verificación. Te dice si la corrección se ha probado y con qué resultado.
• Un destino. El cambio va a una rama nueva de tu repositorio, con un pull request contra tu rama base. En GitLab es un merge request.

Pongamos una inyección SQL en un handler de login, donde el handler concatena la dirección de correo enviada en una cadena de consulta. Un cambio revisable sustituye la concatenación por una consulta parametrizada en ese handler y explica por qué. Llega como un pull request que tus revisores pueden leer junto a la evidencia del hallazgo. No reescribe tu capa de acceso a datos, y nada llega a tu rama principal hasta que alguien de tu equipo lo fusiona.

Por qué tu equipo conserva el control de la fusión

Plexicus nunca fusiona un pull request de remediación. La fusión ocurre en tu SCM, bajo tus protecciones de rama, tus revisiones obligatorias y tu CI, y la hacen personas de tu equipo. Hay tres motivos.

• El código escrito por IA puede ser incorrecto o incompleto. La pantalla de revisión incluye un descargo de responsabilidad que te pide validar la sugerencia frente al contexto y los requisitos de tu proyecto.
• El contexto lo tiene tu equipo. Pongamos un IDOR en una API de facturas, donde cualquier cliente con sesión iniciada puede leer la factura de otro cliente cambiando el ID. Una corrección podría añadir una comprobación de propiedad. Solo tu equipo sabe si el personal de soporte debe seguir pudiendo abrir cualquier factura.
• Rendición de cuentas. La descripción del pull request nombra al usuario que lo abrió, y tu SCM registra quién lo aprobó y quién lo fusionó. Plexicus escribe las solicitudes de remediación en el Registro de Auditoría de la organización, y la sección Actividad de cada hallazgo muestra cuándo se generó una remediación y cuándo se creó su pull request.

Qué hallazgos se pueden corregir en el código

Plexicus solo puede parchear algo que vive en un repositorio. Lo que ofrece el panel de detalle depende de dónde viene el hallazgo.

Hallazgo	Qué ofrece el panel de detalle
Un hallazgo que apunta a un archivo de un repositorio conectado	Crear AI Remediation
Un hallazgo de registro de contenedores cuya imagen está vinculada a un repositorio de código fuente	Remediar en el repo
Un hallazgo cuyo tipo de remediación es Issue, por ejemplo cuando no hay una línea de código fuente que cambiar	Crear Issue
Un hallazgo de AI Pentest	No hay corrección de código salvo que el pentest tenga un repositorio de código fuente vinculado; confirma con Plexicus que las correcciones de pentest están disponibles en tu versión
Una mala configuración cloud, un hallazgo de postura del SCM o una imagen de registro no vinculada a un repositorio	Ninguna acción de remediación

Si un AI Pentest no tiene repositorio vinculado, Plexicus te indica que la remediación requiere un repositorio de código fuente vinculado y que puedes configurarlo en los ajustes del pentest.

Crear una remediación con IA: comprobaciones, estrategias de corrección y progreso en vivo

Las comprobaciones que Plexicus hace primero

Plexicus confirma que el trabajo puede completarse con éxito.

1. Conexión de IA. Prueba la conexión de IA de tu organización, ya sea la predeterminada de Plexicus o la tuya propia (lección 5).
2. Conexión del SCM. Valida tu token de control de código fuente. Si el token ya no es válido, Plexicus te pide que vuelvas a conectar tu control de código fuente.
3. Acceso al repositorio. Confirma que se puede acceder al repositorio.
4. Veredicto de falso positivo. Un hallazgo pendiente de revisión de falso positivo, o uno que la pasada de IA marcó como falso positivo, no se puede remediar. El tooltip lo indica, y el servidor también lo impone. Revertir la marca de falso positivo de la IA (módulo 4) levanta el bloqueo.
5. Una persona cada vez. Si un compañero ya está remediando el hallazgo, el botón se desactiva con “Another user is working on this finding”.

Los repositorios de demostración del sandbox se saltan las comprobaciones del SCM y pueden generar correcciones, pero no abrir pull requests ni issues. Si tu cuota mensual de uso de IA se ha agotado, el botón se desactiva (lección 5).

Cómo elige Plexicus la estrategia de corrección

Tú no eliges la estrategia. Plexicus la elige a partir del hallazgo.

Situación	Estrategia	Cómo se produce el cambio
Una persona marcó el hallazgo como falso positivo	Comentario de supresión	Un comentario en línea que silencia esa regla en esa ubicación
Un hallazgo de dependencia con una versión corregida conocida en la misma versión mayor	Subida de versión de la dependencia	Una edición determinista del manifiesto, sin que ninguna IA escriba código
Todo lo demás, incluidas las actualizaciones de dependencias que cruzan una versión mayor	Agente de corrección con IA	Un cambio de código escrito por el agente

El comentario de supresión sigue a una decisión humana. Cuando alguien marca un hallazgo como falso positivo (módulo 4), Plexicus solicita un cambio que añade este comentario. Según tu proveedor de control de código fuente, llega como un pull request para que tu equipo lo revise, sin coste para tu cuota de uso de IA.

La subida de versión de la dependencia cubre los manifiestos habituales, como npm, Composer, requirements.txt, Gemfile, archivos TOML, go.mod, Gradle y .csproj. La versión propuesta se comprueba contra el registro de paquetes; si no se puede verificar, la remediación lleva el aviso “review before merging”. Un salto de versión mayor puede cambiar la API de la librería, así que pasa al agente de corrección con IA. Ninguna IA escribe la subida de versión, pero aun así cuenta para tu cuota de uso de IA.

Qué hace y qué no hace el agente de corrección con IA

El agente trabaja sobre un clon recién creado de la rama configurada del repositorio. Su alcance es deliberadamente estrecho:

• Corrige solo el problema notificado, en el archivo y la línea notificados.
• Toca otro archivo solo cuando la corrección lo necesita, como un helper compartido.
• Tiene instrucciones de no refactorizar, no corregir otros problemas que detecte, no editar archivos de test y no hacer commits. Plexicus captura el resultado como un git diff.

Las instrucciones no son garantías, así que revisa el diff por si incluye algo más allá del hallazgo.

Para las clases de vulnerabilidad habituales, el agente recibe el patrón de código seguro para el lenguaje del archivo: inyección SQL (CWE-89), cross-site scripting (CWE-79), inyección de comandos del sistema operativo (CWE-78), path traversal (CWE-22) y archivos temporales inseguros (CWE-377). Así se orienta hacia una consulta parametrizada en lugar de un filtro por lista de bloqueo. Si se trata de un secreto expuesto, el agente mueve el valor a una variable de entorno, y la revisión añade la recomendación de configurar una solución de gestión de secretos.

Cuando una remediación cubre varios hallazgos, se agrupan por archivo, unos pocos por sesión de IA, y los grupos se ejecutan uno tras otro. Los grupos terminados se entregan aunque un grupo posterior agote el tiempo.

Seguir el progreso

El terminal en vivo transmite cada paso: desde el clonado del repositorio, pasando por “Generating fix…” y una línea por cada grupo de archivos, hasta “Fix captured” y un resultado final. Cuando la corrección está lista, el modal de revisión se abre automáticamente. Ver corrección de IA lo vuelve a abrir más adelante.

Si una corrección sigue en marcha después de 15 minutos, Plexicus muestra “Esta remediación está tomando más tiempo de lo esperado.” y ofrece Crear Remediación de nuevo. Si la generación falla, ves “No se pudo crear la corrección.” y un botón Intentar de nuevo. Un intento fallido nunca bloquea un reintento.

Revisar la corrección y abrir el pull request

El modal de revisión es donde entra tu criterio. Léelo como leerías el pull request de un compañero, con la evidencia del hallazgo al lado.

Qué muestra el modal de revisión

• El título del hallazgo y una insignia de verificación.
• Un resumen del cambio: líneas añadidas, líneas eliminadas y número de archivos.
• Un diff unificado por cada archivo. Cualquier línea generada que parezca corrupta aparece tachada y marcada con “Línea generada posiblemente corrupta — revísala antes de aplicarla.”
• Una sección desplegable, Por qué esta corrección — razonamiento y verificación, con la explicación escrita por la IA.
• El descargo de responsabilidad sobre la IA, y la rama de origen y la rama de destino que usará el pull request.

La explicación se escribe en el Idioma de escaneo e informes de tu organización, que un Administrador configura en Configuración Platform .

Cómo leer la insignia de verificación

La verificación de la corrección es opcional. Tu organización la activa con el interruptor Verificación de corrección en Configuración Platform , y su disponibilidad depende de tu plan. Cuando está activada, una segunda sesión de IA se ejecuta en una copia aislada y desechable del repositorio. Escribe un test de seguridad específico para el hallazgo y lo ejecuta contra el código corregido.

Insignia	Qué significa
Fix verificado	El test aislado se ejecutó y pasó contra el código corregido
Fix sin probar	No se ejecutó ningún test de verificación para esta corrección
Fix sin verificar	La corrección se aplicó, pero el test agotó el tiempo, así que no está demostrada
Verificación fallida	El test comprobó que la vulnerabilidad sigue siendo explotable
Error de verificación	No se pudo ejecutar el test

La verificación solo añade una anotación a la corrección. Nunca cambia el diff que revisas.

Qué comprobar antes de abrir el pull request

• Causa raíz, no síntoma. En el handler de login, la corrección es una consulta parametrizada. Escapar las comillas del campo de correo electrónico no lo es.
• Comportamiento. En el IDOR de facturas, confirma que la nueva comprobación de propiedad coincide con tus reglas de autorización reales.
• Dependencias. Lee el changelog de la nueva versión y comprueba si hay que regenerar tu lockfile.
• Secretos. Mover un secreto a una variable de entorno detiene la fuga en el código, pero el valor antiguo sigue comprometido. Rótalo.

Editar y después abrir el pull request

Con los roles por defecto, los usuarios Administrador y Operador de Ciberseguridad pueden editar el código generado antes de que exista un pull request. Usa Editar PR, o Editar y después Guardar en cada archivo de una corrección de varios archivos. En cuanto existe un pull request o un issue, la edición se bloquea con “Ya se ha creado una pull request; la edición está bloqueada.” A partir de ahí, cambias el código en la rama de tu SCM.

Cuando el cambio está listo, un Administrador o un Desarrollador hace clic en Pull Request (Merge Request en GitLab) en la parte inferior del modal. Plexicus clona la rama configurada y crea una rama nueva cuyo nombre empieza por Plexicus-AI-Remediation-. Aplica el diff, hace push y abre un pull request contra la rama base. Su título y su descripción salen de la remediación, y la descripción termina con “Created by:” y la dirección de correo electrónico del usuario que lo abrió. Un banner confirma “Pull request creada” con un enlace Ver PR, y el botón del hallazgo también pasa a ser Ver PR.

Los pull requests de remediación funcionan en GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea y Forgejo. Azure TFVC no tiene pull requests. Si el push falla, Plexicus te dice por qué: el repositorio es un mirror de solo lectura, el token necesita permisos de escritura o el token no es válido.

Para los hallazgos que se remedian como issue, el modal ofrece Crear Issue, además de Enviar Webhook si hay un webhook de issues configurado. Si hay una integración de ticketing configurada para seguir los pull requests, el ticket también se actualiza (módulo 9).

Estado	Qué significa aquí
Lista para corregir	Se ha generado una remediación y está esperando revisión
Fix enviado	Se abrió un pull request o un merge request
Emitido	Se abrió un issue en lugar de un pull request
Corregido	Tu SCM informó de que el pull request se fusionó o de que el issue vinculado se cerró

Remediación masiva sobre muchos hallazgos

Corregir los hallazgos de uno en uno no da abasto cuando un escaneo informa de 40 paquetes vulnerables en un servicio. La remediación masiva aplica el mismo flujo a una selección y sigue toda la ejecución en un solo sitio. La disponibilidad de la remediación masiva depende de tu plan.

Iniciar una ejecución masiva

En Hallazgos , marca al menos dos hallazgos, abre las acciones masivas y elige Remediar. Una solicitud acepta hasta 100 hallazgos. Las acciones masivas que ves dependen de tu rol (módulo 4); con los roles integrados, los Desarrolladores solo pueden usar Crear Pull Request en hallazgos cuya remediación ya se ha generado.

Plexicus agrupa la selección por repositorio y después por estrategia de corrección, igual que con un solo hallazgo (lección 2). En cada repositorio, los comentarios de supresión, las subidas de versión de dependencias y las correcciones con IA se convierten cada uno en su propia remediación, y solo las correcciones con IA pasan por los grupos de archivos del agente de corrección con IA. Los hallazgos que se remedian como issue reciben cada uno su propio issue escrito por la IA. El modal tiene dos opciones:

• Crear pull requests automáticamente. Activada por defecto. Si la desactivas, las correcciones se quedan en Lista para corregir y no se hace push de nada.
• Modo de pull request se aplica a las correcciones con IA. En ambos casos, cada repositorio recibe un pull request para ellas. PR único registra cada grupo de remediación como un commit propio, para que los revisores puedan recorrer el cambio archivo por archivo, y deja fuera los grupos que fallaron o no cambiaron nada. Un PR por remediación, el predeterminado, entrega las mismas correcciones en un único commit. Las subidas de versión de dependencias y los comentarios de supresión siempre reciben su propio pull request.

Haz clic en Remediar para empezar. Los hallazgos que ya tienen una remediación se omiten. Los hallazgos pendientes de revisión de falso positivo, o marcados como falsos positivos por la pasada de IA, se bloquean, igual que cuando los remedias de uno en uno.

Seguir la ejecución

El botón de la barra de herramientas Hallazgos Estado de remediación masiva abre el panel Progreso de remediación masiva. Cada ejecución pasa por cuatro fases: En cola, Generando fixes, Creando pull request y Completado. Una ejecución aparece como En curso, Completado o Incompleto.

Cada grupo de remediación, formado por unos pocos hallazgos del mismo archivo, muestra su propio estado. Estos son los que verás con más frecuencia:

Estado del grupo	Significado
En cola	Esperando al motor de remediación
Procesando (con un porcentaje)	El agente de corrección con IA está trabajando en este grupo
Correcto	El grupo produjo un cambio
Fallido	La sesión de IA tuvo un error o agotó el tiempo
Omitido (sin cambios)	El grupo no produjo ningún cambio, y sus hallazgos se quedan como estaban

Cada grupo tiene su propio terminal en vivo, y Ver Pull Request te lleva al resultado. El panel se mantiene aunque recargues la página y todo el equipo puede verlo. Un compañero puede seguir una ejecución que iniciaste tú sin tener que preguntarte cómo va. En el modo PR único, los hallazgos de un grupo que falló o no produjo cambios conservan su estado.

Diseñar un lote que tus revisores puedan asumir

Una ejecución masiva vale lo que valen los pull requests que produce. Agrupa los lotes por repositorio, por equipo responsable y por clase de problema. Por ejemplo, selecciona los 25 hallazgos de dependencias vulnerables del servicio de pagos en lugar de 25 hallazgos sin relación de seis repositorios. Un lote enfocado le da a un equipo un pull request que reconoce y puede revisar de una sentada. Un lote mezclado produce pull requests de los que nadie se siente responsable.

Configuración y uso de la IA: cuota, trae tu propia IA y lo que nunca ocurre automáticamente

Tu cuota de uso de IA

Las acciones de IA consumen una única cuota mensual de tu organización. Eso incluye las correcciones con IA, las subidas de versión de dependencias, los issues escritos por la IA y el análisis de falsos positivos con IA. Ejecutar escaneos de repositorios no la consume, pero el análisis con IA sí puede hacerlo, así que mira el medidor antes de un escaneo de IA grande. La cuota se restablece el día 1 de cada mes natural (UTC), no en tu fecha de facturación. Las sesiones de AI Pentest (módulo 6) y las conversiones de filtro con IA tienen sus propios contadores. El tamaño de tu cuota depende de tu plan.

Cuando hay datos de uso disponibles, el menú de tu perfil muestra un medidor de uso y un enlace Gestionar facturación y uso. Según tu plan, Configuración Facturación , una página titulada Facturación y uso, muestra lo que se ha consumido este mes frente a tu límite y la fecha en que se restablece la cuota, o Ilimitado. En la página de Facturación, la barra se vuelve ámbar al 75 % y roja al 90 %, y Plexicus te avisa en ambos puntos. Si tu versión lo incluye, una página de Uso en Configuración desglosa el uso por acción, con el historial completo.

Cuando se agota la cuota, Crear AI Remediation se desactiva con un mensaje de que se ha alcanzado el límite mensual, la acción masiva Remediar se desactiva y la página Hallazgos muestra un banner con Mejorar plan. Las acciones de IA se reanudan cuando se restablece la cuota.

Trae tu propia IA (BYO-AI)

Según tu plan, puedes ejecutar la IA de Plexicus sobre tus propios endpoints de modelos en lugar de los modelos predeterminados de Plexicus.

Bloque	Para qué se usa	Qué introduces
Modelo rápido	Se ejecuta en cada hallazgo para la validación y el enriquecimiento, así que soporta un gran volumen	Clave API, URL base, Modelo
Modelo inteligente	Genera las correcciones y el análisis profundo, con menos volumen y más en juego	Clave API, URL base, Modelo
Endpoint de embeddings	Construye el índice consultable de tu código antes de cada escaneo de IA	Clave API y URL base; el modelo de embeddings es fijo y se muestra en solo lectura

Cada bloque acepta un endpoint estándar de chat completions o de embeddings de tu proveedor de IA, autenticado con una clave API, incluido un gateway autoalojado. No hay selector de proveedor. Guardar la configuración BYOAI prueba y guarda los tres bloques a la vez, y el endpoint de embeddings es obligatorio, porque una configuración parcial rompería todos los escaneos de IA. Las claves guardadas no se vuelven a mostrar nunca; deja vacío un campo de clave para conservarla. Las URL base se validan frente a server-side request forgery antes de probar la conexión. Restablecer al valor de Plexicus borra los tres bloques. Con BYO-AI, el medidor de uso muestra Ilimitado porque la inferencia se ejecuta con tu propia clave y tu propia cuenta de tu proveedor de IA.

Adónde va tu código

Las funciones de IA envían el contexto de código relevante al endpoint de modelo configurado: los modelos predeterminados de Plexicus o tu propio endpoint con BYO-AI. Cada remediación se ejecuta en un trabajo aislado de corta duración. El agente solo puede escribir en su espacio de trabajo clonado y no recibe ninguna otra credencial de la plataforma. La verificación se ejecuta en una copia desechable que se borra después. El código de los clientes no se usa para entrenar modelos de IA, y los datos SaaS se quedan en la UE por defecto.

Lo que nunca ocurre automáticamente

Puntos clave

• Una remediación es una propuesta: un diff, una explicación, una insignia de verificación y un pull request en una rama nueva. Plexicus nunca lo fusiona: lo hace tu equipo, en tu SCM.
• Antes de que empiece una corrección, Plexicus comprueba la conexión de IA, el token del SCM, el acceso al repositorio y el veredicto de falso positivo. Después elige un comentario de supresión, una subida de versión de la dependencia o el agente de corrección con IA.
• Revisa el diff y la explicación “Por qué esta corrección” como harías con cualquier pull request. Una insignia Fix verificado demuestra que pasó el test específico, no que no se haya roto nada más.
• Edita mientras la remediación siga siendo una propuesta. En cuanto existe el pull request, la edición se bloquea, y Fix enviado pasa a Corregido solo cuando tu SCM informa de la fusión.
• La remediación masiva agrupa hasta 100 hallazgos por repositorio y estrategia de corrección. Elige a conciencia los pull requests automáticos y el modo de pull request, y sigue la ejecución en el panel Progreso de remediación masiva.
• Las acciones de IA consumen una cuota mensual de uso de IA, que se muestra en Configuración Facturación y en el menú de tu perfil. Con BYO-AI, diriges los bloques Modelo rápido, Modelo inteligente y Endpoint de embeddings a los endpoints de tu propio proveedor de IA.