Fundamentos de Proof-Driven AppSec

Por qué el volumen de alertas no es seguridad

La mayoría de los programas de seguridad de aplicaciones pueden decirte cuántas alertas tienen. Muchos menos pueden decirte cuáles de esas alertas puede aprovechar de verdad un atacante, a qué afecta cada una y si la corrección llegó a desplegarse. Este curso empieza por esa brecha, porque el resto de la plataforma está diseñado para cerrarla.

Un recuento de alertas mide cuántas herramientas ejecutas y cuántas reglas aplican. No mide el riesgo. Cuatro problemas explican la diferencia.

Proliferación de herramientas

Los equipos suelen añadir herramientas de categoría en categoría: un analizador estático para el código, un comprobador de dependencias, un escáner de secretos, un validador de infraestructura como código, un escáner de imágenes de contenedor. Cada una tiene su propia consola, su propia escala de severidad y su propio formato de salida. La misma dependencia vulnerable puede aparecer en dos o tres de ellas con nombres y severidades distintos, y nadie se hace cargo de la vista unificada. Los ingenieros acaban conciliando exportaciones en lugar de corregir código.

Plexicus unifica la salida de los escáneres en un único formato de hallazgo y la deduplica, y el hallazgo que se conserva mantiene la severidad más alta de sus duplicados. También puedes importar resultados de escáneres de terceros compatibles (por ejemplo, en formato SARIF) en el mismo flujo de trabajo. El módulo 3 trata los motores, la cobertura y la regla exacta de deduplicación.

Ruido

Piensa en un resultado de análisis estático titulado “posible inyección SQL en el handler de login”. Puede ser un fallo real y explotable en el formulario de inicio de sesión, donde el nombre de usuario llega directamente a una cadena de consulta. También puede ser una consulta construida a partir de una constante en un helper de pruebas al que ninguna entrada de usuario puede llegar nunca. Ambos llegan con la misma etiqueta y, a menudo, con la misma severidad.

Cuando la mayoría de las alertas resultan ser del segundo tipo, los desarrolladores aprenden a leer la lista por encima, y las alertas reales también se leen por encima. Lo que separa ambos casos es la evidencia: si existe un camino desde una entrada controlada por el atacante hasta el código vulnerable, si ese código es siquiera alcanzable y si una segunda comprobación independiente confirma el resultado.

El cuello de botella de la remediación

Detectar no es corregir. Cada hallazgo abierto es trabajo pendiente para tu equipo. Encontrar un problema nuevo es barato. Corregirlo requiere un desarrollador que entienda el código, un cambio que no rompa nada, una revisión y una fusión. Si la cola crece más rápido de lo que el equipo puede cerrarla, detectar más solo agranda el backlog sin hacer la aplicación más segura. El verdadero cuello de botella está en el contexto y en los cambios revisables, no en la falta de alertas.

Postura a ciegas

Intenta responder a estas preguntas a partir de una lista de alertas sin procesar. ¿Qué tres repositorios concentran más riesgo explotable? ¿Cierras hallazgos más rápido de lo que los generas? ¿Cuánto tiempo permanece abierto un hallazgo crítico? Una pila creciente de alertas no puede responder a ninguna de ellas. La dirección ve una cifra que no deja de subir, y la siguiente auditoría vuelve a encontrar los mismos problemas.

Escanear con más frecuencia tiene el mismo límite. Un escaneo nocturno que informa de la misma inyección SQL sin corregir durante un mes mide actividad, no progreso. La frecuencia de escaneo te dice cada cuánto has mirado, no si algo se ha vuelto más seguro.

El Panel de control de Plexicus sigue la misma idea: sus totales solo cuentan el trabajo abierto (módulo 2). La pestaña CISO muestra Puntuación de Postura de Riesgo, Nuevos vs Corregidos y Repositorios de Mayor Riesgo. La pestaña DevSecOps añade la alcanzabilidad, la antigüedad de los hallazgos y la velocidad de remediación.

El ciclo Proof-Driven: Validar, Entender, Remediar

Plexicus llama a su enfoque Proof-Driven AppSec: saber qué es real, entender a qué afecta y corregirlo con evidencia. El enfoque tiene tres pasos, y cada paso es un producto.

Paso	Producto	Pregunta que responde	Qué obtienes
Validar	AI Swarm Pentest	¿Se puede explotar realmente dentro del alcance autorizado?	Hallazgos verificados con evidencia reproducible, una prioridad y un handover documentado
Entender	Deep Code Analysis	¿A qué código, datos y flujo de negocio afecta, y puede alcanzarlo un atacante?	El flujo afectado, su alcanzabilidad y su exposición, una clase de debilidad CWE y una prioridad
Remediar	Remediation	¿Qué cambio lo cierra y ha funcionado ese cambio?	Un cambio listo para revisión con la evidencia adjunta, entregado a través de tu flujo de pull requests, además de re-tests de verificación donde estén configurados

Validar con AI Swarm Pentest

AI Swarm Pentest es un ejercicio acotado y autorizado sobre una aplicación, una API, código fuente o un entorno de pruebas. Comprobaciones de IA coordinadas mapean la superficie de ataque, formulan hipótesis y prueban rutas, y una segunda pasada confirma cada hallazgo de forma independiente antes de marcarlo como verificado. No es un escáner de firmas ni un chatbot de seguridad. En el producto aparece como AI Pentest en la sección App Pentest. El módulo 6 lo trata en profundidad.

Entender con Deep Code Analysis

Una regla de análisis estático puede señalar un patrón, y un modelo de lenguaje puede explicar código. Ninguno de los dos establece cómo afecta una debilidad a tu aplicación. Deep Code Analysis conecta un hallazgo con el código, el flujo de datos y el impacto en el negocio. Para cada hallazgo obtienes el flujo afectado (fuente, propagación y sumidero), si un atacante puede alcanzarlo y desde dónde (alcanzabilidad y exposición a internet) y una clase de debilidad mapeada a CWE y OWASP. El módulo 5 lo trata.

Remediar con Remediation

Una vez verificado un hallazgo, Remediation prepara el contexto y un cambio sugerido en forma de diff listo para revisión. Tu equipo lo revisa y decide si lo fusiona. Cuando se fusiona el pull request, Plexicus marca el hallazgo como Corregido. Según tu plan y tu configuración, una prueba de verificación puede comprobar la corrección antes de que se abra el pull request y, en el caso de un hallazgo de pentest, puedes reescanear la evaluación para comprobar que la ruta está cerrada. El módulo 7 explica el flujo de trabajo.

Dónde encajan XBOM y Plexicus Automation

Dos productos trabajan junto al ciclo en lugar de formar parte de un paso concreto:

• XBOM es un único inventario de componentes de software (SBOM), activos criptográficos (CBOM) y modelos de IA (AIBOM), con declaraciones VEX que registran si una vulnerabilidad conocida te afecta. Responde a preguntas como “¿dónde distribuimos la versión vulnerable de esta librería?” y genera evidencia para auditorías. El módulo 8 lo trata.
• Plexicus Automation dirige los hallazgos hacia correcciones, tickets, aprobaciones y notificaciones, por ejemplo cuando un hallazgo se crea, se enriquece o se reabre. Solo los administradores pueden activar un flujo. El módulo 9 lo trata.

SAST, SCA, las comprobaciones de infraestructura como código, la detección de secretos y los resultados importados de escáneres aportan cobertura de apoyo. Suministran señales que alimentan el ciclo. No lo sustituyen.

El estándar de evidencia y sus salvaguardas

La regla que hay detrás de cada entregable de Plexicus cabe en una línea: sin prueba reproducible, no hay hallazgo verificado. Esta lección explica qué cuenta como prueba, cómo una señal se convierte en un hallazgo verificado y cuáles son las cuatro salvaguardas que mantienen un ejercicio dentro de los límites acordados.

Prueba reproducible

Cada hallazgo de un entregable de AI Swarm Pentest incluye evidencia que otra persona puede reproducir: la petición, la respuesta, los pasos y el impacto demostrado. “Lo dice el escáner” no es una prueba. Los hallazgos de pentest del producto pueden incluir una prueba de concepto de replay, como un comando cURL, un script de shell o una captura HAR. Se muestra exactamente tal como se registró y no se vuelve a ejecutar desde tu navegador.

Verificación independiente

Una señal no se convierte en un hallazgo verificado porque lo diga una sola comprobación. Una segunda pasada tiene que confirmar de forma independiente el comportamiento observado.

Fase	Qué significa	Qué pasa después
Hallazgo candidato	Una hipótesis produjo una señal con contexto técnico	Pasa a la verificación independiente
Hallazgo verificado	Una segunda pasada reprodujo el resultado	Entra en el entregable con su impacto y su prioridad
No confirmado	La segunda pasada no pudo reproducirlo	Se marca como no verificado o se descarta, y nunca se notifica como verificado

Aplica la misma disciplina cuando hagas el triage de los resultados de los escáneres. La vista de detalle del hallazgo muestra la severidad del escáner junto a la severidad validada por IA (“Severidad — escáner vs IA”). También etiqueta cada paso de una traza de flujo de datos según su origen, como “Flujo de datos del escáner” o “Verificado por IA”. Trata cualquier paso marcado como “Inferido por IA (sin verificar)” como una pista que hay que comprobar, no como una prueba (el módulo 5 explica cómo se verifican las trazas).

Las cuatro salvaguardas

En un ejercicio de AI Swarm Pentest, el estándar de evidencia se apoya en cuatro salvaguardas. Son las mismas cuatro que verás en la página pública de AI Swarm Pentest, y el módulo 6 las aplica en profundidad.

Salvaguarda	Qué significa para ti
Alcance acordado por escrito	El objetivo (una aplicación, una API, código fuente o un entorno de pruebas), los accesos de prueba y las reglas de actuación se confirman antes de empezar. Plexicus no actúa fuera de ese alcance.
Evidencia trazable	La evidencia de respaldo permanece vinculada al hallazgo que explica.
Límites del ejercicio	El tiempo, los recursos y el acceso están acotados, de modo que cada ejecución se mantiene bajo control.
Decisión humana	Tu equipo conserva la aprobación final y el control de cada cambio. Plexicus no realiza cambios automáticos en producción.

Cómo aplica el producto el alcance

No puedes lanzar un AI Pentest hasta demostrar que eres el propietario del objetivo. Para una aplicación concreta, lo demuestras con un token en una metaetiqueta HTML o en un archivo bajo /.well-known/. Para un dominio completo, lo demuestras con un registro DNS TXT. Aceptar los términos del servicio no cuenta como prueba. En una evaluación nueva, “Acciones destructivas” aparece preseleccionado como fuera de alcance, y el asistente recomienda probar en staging y no en producción.

Decisión humana y control de la fusión

La IA automatiza el trabajo repetitivo de exploración, correlación y reproducción. Tu equipo conserva el contexto, la supervisión y la decisión final. En el producto, cuando una persona elige “Marcar como falso positivo”, esa decisión prevalece y las pasadas posteriores de la IA no la anulan. Las correcciones preparadas por IA incluyen una nota que pide al revisor que valide el cambio.

Plexicus nunca modifica producción. Solo entrega propuestas revisables, en forma de pull requests o de archivos de parche independientes. El agente de corrección con IA edita un clon aislado de tu repositorio. Plexicus sube el cambio únicamente a una rama nueva y abre un pull request contra tu rama base, y nunca fusiona ese pull request. La fusión es siempre decisión de tu equipo, en tu propio sistema de control de versiones.

Un mapa de la plataforma y de quién la usa

La barra lateral principal te lleva a Panel de control, Activos, App Pentest, Hallazgos, XBOM, la página Automatizaciones y Configuración. Documentación y Soporte están en la parte inferior. Pulsa ⌘K (Ctrl+K en Windows y Linux) para abrir la paleta de comandos e ir directamente a cualquier sección.

Área	Qué haces allí	Quién la usa más
Panel de control	Seguir la postura con las pestañas CISO, DevSecOps, Compliance, Developer y Personalizado, filtradas por rango de fechas y por repositorio	Responsables de seguridad, ingenieros de seguridad, desarrolladores
Activos	Gestionar los repositorios conectados en la pestaña Repo Scan: añadir repositorios, seguir los escaneos, reescanear. Las pestañas Registry Audit y Cloud Assessment están disponibles según tu plan	Ingenieros de seguridad, responsables de la plataforma
App Pentest	Crear evaluaciones de AI Pentest, verificar la propiedad del objetivo, seguir las ejecuciones y abrir sus resultados	Ingenieros de seguridad
Hallazgos	Hacer el triage de los hallazgos en las pestañas Repo, SCM, Cloud, Registry y App Pentest. Abrir un hallazgo para revisar la evidencia, crear un ticket o iniciar la remediación	Ingenieros de seguridad, desarrolladores
XBOM	Explorar los inventarios Software (SBOM), Criptografía (CBOM) y Modelos de IA (AIBOM), definir declaraciones VEX y exportar	Ingenieros de seguridad, equipos de cumplimiento, responsables de la plataforma
Automatizaciones	Crear flujos que dirigen los hallazgos hacia correcciones, tickets y aprobaciones	Los administradores crean y activan los flujos
Configuración	Organización (equipo, roles, verificación de propiedad), Configuración (integraciones, opciones de la plataforma, facturación) y Mi Cuenta (datos de la cuenta, autenticación, tokens)	Administradores y responsables de la plataforma, y cada usuario para su propia cuenta

Tres tipos de usuarios

• Los ingenieros de seguridad (AppSec y DevSecOps) hacen el triage de los hallazgos, configuran los escaneos, ejecutan evaluaciones de AI Pentest y entregan el trabajo verificado a los desarrolladores.
• Los desarrolladores trabajan en los hallazgos que tienen asignados, revisan las correcciones preparadas por IA y abren pull requests. Muchos prefieren hacerlo desde el IDE o el terminal, algo que trata el módulo 9.
• Los responsables de la plataforma despliegan y operan Plexicus, conectan el control de versiones y los proveedores de identidad, y gestionan la configuración de la organización.

Los roles integrados, a grandes rasgos

Rol	Para qué sirve
Administrador	Administración completa de la organización: equipo, roles, configuración, integraciones, facturación y registro de auditoría. Los administradores también pueden generar remediaciones y abrir pull requests.
Operador de Ciberseguridad	El rol de operador de seguridad. Hace el triage de los hallazgos, marca falsos positivos, genera remediaciones y usa “Enviar a equipo de desarrollo” para asignar trabajo. Por defecto, no abre pull requests.
Desarrollador	Trabaja en los hallazgos que tiene asignados y abre pull requests para las correcciones en estado “Lista para corregir”.

El reparto es intencionado. Con los roles por defecto, la persona que prepara una corrección y la que la propone en la base de código pueden ser personas distintas. Un Operador de Ciberseguridad genera y revisa el cambio, y un Desarrollador abre el pull request. Según tu plan, los administradores también pueden crear roles personalizados en Configuración Roles . Los roles integrados no se pueden renombrar ni eliminar. El módulo 10 trata en detalle los roles, el SSO y el registro de auditoría.

Despliegue y confianza: lo esencial

Plexicus funciona como SaaS en la UE o autoalojado, y air-gapped es una variante del autoalojado. El producto es el mismo en todos los casos; solo cambian el alojamiento y los límites de red.

Opción	Dónde se ejecuta	Cuándo elegirla
SaaS en la UE (por defecto)	Alojado por Plexicus en app.plexicus.ai, operado con un compromiso de residencia de datos en la UE (consulta trust.plexicus.ai)	La mayoría de los equipos. Sin infraestructura que gestionar y con actualizaciones automáticas
Autoalojado	Tu propio clúster de Kubernetes, en tus instalaciones o en una cuenta cloud que controlas, instalado con el Helm chart oficial	Requisitos estrictos de residencia de datos, de cumplimiento o de aislamiento de red
Air-gapped (variante autoalojada)	La instalación autoalojada con Helm, con las imágenes replicadas en un registro interno y tu propio emisor interno de certificados	Clústeres sin acceso público a internet o con controles estrictos del tráfico de salida

Qué significa “autoalojado”

Autoalojado y on-premise son el mismo producto, el mismo chart y la misma licencia, y un despliegue autoalojado no envía telemetría, analítica ni datos de feedback fuera de tu clúster. Las funciones que dependen de los servicios comerciales de Plexicus, como la facturación, están desactivadas, y solo las integraciones que configuras tú, como tu control de versiones y tu proveedor de IA, se comunican con sistemas externos. El módulo 10 trata Helm, las instalaciones air-gapped y las copias de seguridad.

Tu código y la IA

• El código de los clientes no se usa para entrenar modelos de IA.
• Plexicus SaaS se opera con un compromiso de residencia de datos en la UE (consulta trust.plexicus.ai). La entidad legal, PLEXICUS, S.L., tiene su sede en Bilbao (España), bajo jurisdicción de la UE.
• Las funciones de IA envían el contexto de código relevante al endpoint del modelo configurado. Por defecto son modelos gestionados por Plexicus o, según tu plan, el endpoint de tu propio proveedor de IA, que se configura en Configuración BYOAI .

Confianza y evidencia

Plexicus cuenta con la certificación SOC 2 Type II. Una firma independiente hace cada año un pentest de la plataforma. El informe SOC 2, una plantilla de DPA, el resumen de la prueba de penetración y las respuestas a cuestionarios de seguridad están disponibles en autoservicio en el portal de confianza, trust.plexicus.ai. Para notificar una vulnerabilidad en el propio Plexicus, escribe a info@plexicus.ai.

Usa un lenguaje preciso cuando hables de cumplimiento. Plexicus no hace que tu organización cumpla NIS2, el artículo 28 de DORA, el CRA o el EU AI Act. Mapea los hallazgos a los marcos que selecciones, como NIS2, DORA y el CRA, en la pestaña Compliance del Panel de control, y las atestaciones de XBOM se pueden puntuar frente a perfiles como el EU CRA y el EU AI Act. Después, tus auditores evalúan esa evidencia. El módulo 8 lo trata en detalle.

Puntos clave

• El volumen de alertas mide la salida de las herramientas, no el riesgo. La proliferación de herramientas, el ruido, el cuello de botella de la remediación y la falta de visibilidad sobre la postura mantienen ocupados a los equipos sin hacerlos más seguros.
• Proof-Driven AppSec es un ciclo: Validar con AI Swarm Pentest, Entender con Deep Code Analysis y Remediar con Remediation. XBOM y Plexicus Automation trabajan junto a él.
• Sin prueba reproducible, no hay hallazgo verificado. Un resultado que una segunda pasada no puede reproducir se marca como no verificado o se descarta.
• En un ejercicio de AI Swarm Pentest se aplican cuatro salvaguardas: alcance acordado por escrito, evidencia trazable, límites del ejercicio y decisión humana. Plexicus no realiza cambios automáticos en producción, y tu equipo conserva siempre el control de la fusión.
• La barra lateral te lleva a Panel de control, Activos, App Pentest, Hallazgos, XBOM, la página Automatizaciones y Configuración. Los tres roles integrados, Administrador, Operador de Ciberseguridad y Desarrollador, se reparten las responsabilidades.
• SaaS en la UE es la opción por defecto, y las instalaciones autoalojadas con Helm y las air-gapped ejecutan el mismo producto. El código de los clientes no se usa para entrenar la IA, y Plexicus tiene la certificación SOC 2 Type II y genera evidencia, no cumplimiento, para tus marcos.