KOMPLIANCE: la auditoría que se ve mientras ocurre y la plataforma que se queda después

Por Kike Gandia · IA y Seguridad · 18 min de lectura

Cuando contratáis una auditoría con nosotros no recibís un PDF tres semanas después. Recibís un acceso. Desde el primer día veis el alcance tal cual se va a ejecutar; durante la ejecución veis cada hallazgo el día que aparece, con su evidencia; el informe se genera desde ahí en lugar de redactarse de cero; y cuando el proyecto termina, la plataforma no se apaga: se queda como vuestra herramienta de gestión de seguridad y cumplimiento, con todo el trabajo de la auditoría ya dentro.

Esa plataforma es KOMPLIANCE, el módulo de gestión de vulnerabilidades y cumplimiento de 0data. Nace de una necesidad nuestra —entregar auditorías sin que el resultado muera en un adjunto— y acaba resolviendo la del cliente, que es la misma un año después: saber qué está abierto, de quién es y si se cerró de verdad.

Primero es la sala de control de vuestra auditoría

La diferencia empieza antes de la primera prueba. El alcance se carga en la plataforma y queda visible para las dos partes, así que si algo sobra o falta se discute el primer día y no en la reunión de resultados. A partir de ahí, cada hallazgo entra conforme se encuentra.

Las seis fases de una auditoría en KOMPLIANCE y qué ve el cliente en cada una mientras ocurre. 01 Alcance y arranque: se carga el alcance acordado con activos, exclusiones y ventanas de ejecución, y el cliente puede objetarlo el primer día; hito, reglas de enfrentamiento firmadas y visibles para ambas partes. 02 Ejecución, en vivo: los hallazgos entran conforme aparecen con su evidencia y pasos de reproducción, y el cliente ve el crítico el día que se encuentra; hito, aviso inmediato de todo lo crítico antes de cualquier entregable. 03 Informe: se genera desde los hallazgos que ya están dentro, y el cliente descarga informe técnico, ejecutivo, carta de atestación y SBOM cuando los necesita; hito, entregables reproducibles. 04 Corrección: acceso directo al analista que encontró cada cosa, con tareas con dueño y plazo, en Jira si se usa; hito, responsable nominal y SLA corriendo. 05 Reprueba: se verifica lo corregido y queda la evidencia del intento fallido junto a la del que funcionaba antes; hito, cierre solo con verificación. 06 A partir de aquí se queda: la auditoría termina pero la plataforma no, los agentes siguen vigilando y los módulos de cumplimiento toman el relevo; hito, de entregable puntual a gestión continua sin migrar nada. La trazabilidad va en las dos direcciones: queda registrado quién vio qué y cuándo, también por nuestra parte.

Lo que cambia con esto no es la calidad técnica del trabajo, que es la misma: es que desaparece la opacidad de las tres semanas intermedias. Un crítico se avisa el día que sale, no cuando se maqueta el informe. Y si hay que parar algo o mitigarlo de urgencia, se sabe en horas.

Una auditoría que solo se puede ver cuando ya ha terminado obliga al cliente a confiar. Una que se ve mientras ocurre le permite comprobar.

El informe deja de escribirse y empieza a generarse

Un informe de auditoría escrito a mano en un procesador de textos tiene dos problemas: se tarda, y no es reproducible. Si tres semanas después alguien pregunta por qué un hallazgo figura como alto, la respuesta está en la cabeza de quien lo redactó. Aquí el documento es una vista de los datos, así que sale siempre igual y siempre trazable hasta la evidencia original.

Qué se genera desde el mismo sitio

• Informe técnico con hallazgos, evidencias y pasos de reproducción, para el equipo que va a corregir.
• Informe ejecutivo con el riesgo en términos de negocio, para quien decide el presupuesto.
• Carta de atestación con alcance y fechas, que es lo que suelen pedir los clientes y las licitaciones.
• SBOM en CycloneDX o SPDX, por producto y versión.
• Expedientes de cumplimiento para ISO 27001, CRA o ENS, con la evidencia ya fechada.

Y se generan cuando hacen falta. El caso típico es el cuestionario de un cliente que llega un martes pidiendo la última auditoría: no hay que buscar el fichero ni preguntar quién tiene la versión buena.

Auditoría agéntica: los agentes no empiezan en blanco

La parte automatizada de nuestras auditorías no es un escáner programado. Antes de decidir qué probar, los agentes leen lo que ya sabe 0data: el modelo de amenazas vivo de CyberPanorama —más de seiscientas fuentes cruzadas en tiempo real—, los perfiles de threat hunting que ya han dado resultado en entornos parecidos, el modelado de amenazas sobre MITRE ATT&CK y el histórico de vuestras campañas anteriores.

Eso cambia el orden de todo lo demás. Un barrido sin contexto lanza el catálogo completo y ordena por CVSS; uno con el modelo de amenazas detrás prueba primero por donde están entrando ahora mismo en empresas como la vuestra.

Esquema de la auditoría agéntica de KOMPLIANCE y de dónde saca su contexto. Fuentes: CyberPanorama, más de 600 fuentes cruzadas en tiempo real, que aporta el modelo de amenazas vivo (si el 90 por ciento de las señales del mes son phishing, el ejercicio de personas sube de prioridad); perfiles de threat hunting, hipótesis de caza reutilizables que ya han dado resultado en entornos parecidos; modelado de amenazas con 889 técnicas MITRE ATT&CK observadas, donde sigilo, persistencia y escalada concentran las técnicas y todas son posteriores a la intrusión; explotación conocida con cruce continuo de KEV y EPSS; e histórico del cliente con las campañas anteriores, que permite distinguir una regresión de un hallazgo nuevo. Con eso el orquestador decide por dónde empezar, qué técnicas ATT&CK probar, qué herramienta lanzar para cada comprobación y cuándo escalar a un analista lo que no encaja en ningún patrón conocido. El contraste: un barrido sin contexto lanza el catálogo completo a todo, ordena por CVSS, devuelve miles de líneas con la severidad del fabricante y llama nuevo a lo que ya se encontró el año pasado; un barrido con el modelo de amenazas detrás prueba primero por donde están entrando ahora, ordena por exposición real y criticidad, devuelve hallazgos contextualizados y deduplicados, y distingue una regresión de un hallazgo de primera vez. Agéntico no significa autónomo sin control: quien firma un hallazgo crítico sigue siendo una persona.

Los agentes trabajan además contra las herramientas conectadas directamente, no contra sus informes exportados. La consecuencia práctica es que la fase de reconocimiento de una campaña deja de consumir dos semanas: el inventario ya existe y está al día antes de que empiece el trabajo manual.

Quién ve qué: multiempresa, multiproducto y dos roles

Dos preguntas aparecen en toda evaluación seria de una plataforma así, y casi nunca se contestan en una página de producto. La primera: si somos un grupo con filiales y varios productos, ¿puedo separarlos y tener a la vez el consolidado? La segunda: ¿va a ver el director financiero el mismo panel que el desarrollador?

Modelo de acceso de KOMPLIANCE. Jerarquía multiempresa y multiproducto: una organización (por ejemplo un grupo industrial) contiene empresas o filiales, y cada filial contiene productos. Con rol técnico, la organización solo muestra las empresas donde el usuario tiene asignación, la filial muestra sus hallazgos y activos, y cada producto muestra firmware, SBOM, CVE por componente y pasos de reproducción; una filial sin asignación explícita no se ve. Con rol administrativo, la organización muestra el consolidado del grupo con riesgo agregado y estado de cumplimiento, la filial muestra indicadores y SLA incumplidos, y cada producto muestra el estado del expediente y los críticos abiertos con su antigüedad. El rol técnico (desarrollo, sistemas, seguridad) puede ver la evidencia completa, cambiar el estado de un hallazgo, pedir reprueba, preguntar al analista dentro del hallazgo y descargar el SBOM, pero no puede aceptar un riesgo en nombre de la organización ni ver otras empresas sin asignación. El rol administrativo (dirección, cumplimiento, compras) puede ver indicadores y cumplimiento consolidado, aceptar formalmente un riesgo con justificación firmada, exportar informes y atestaciones y gestionar usuarios y permisos, pero no ve la evidencia técnica explotable ni puede cerrar un hallazgo sin reprueba. Modelos de despliegue: SaaS gestionado, con puesta en marcha en días; on-premise, la plataforma completa en la infraestructura del cliente sin que ningún hallazgo salga de su red, para banca, defensa, sanidad o quien lo tenga exigido por contrato; e híbrido, con los datos sensibles dentro y la inteligencia de amenazas desde fuera.

La separación de roles no es cosmética. Que el rol administrativo no vea la evidencia explotable de cada hallazgo es deliberado: un informe de intrusión reproducible paso a paso no tiene por qué circular por toda la organización. Y al revés, que solo el rol administrativo pueda aceptar formalmente un riesgo —con justificación y firma— es lo que convierte esa decisión en algo defendible ante un auditor.

Sobre el despliegue, la respuesta corta es que existe on-premise. Lo normal es el SaaS gestionado, pero en banca, defensa, sanidad o cuando el pliego lo exige, la plataforma entera se instala en vuestra infraestructura y ningún hallazgo sale de vuestra red. Eso incluye el modo híbrido, para cuando lo que hay que aislar es el dato pero no la inteligencia de amenazas.

Y cuando la auditoría acaba, la plataforma se queda

Aquí empieza la segunda mitad, y es donde el producto deja de ser nuestra forma de entregar para convertirse en vuestra herramienta de gestión. El motivo es simple: el problema que resuelve la auditoría es puntual, pero el que resuelve la plataforma es permanente.

Para quien nos tiene en seguridad gestionada esto es, además, el sitio donde se acumula todo. Cada ejercicio se vuelca al mismo inventario: el pentest de enero, la simulación de phishing de marzo, la revisión de la nube de junio, el threat hunting continuo y cada reprueba. En lugar de un histórico repartido en doce informes de doce fechas distintas, hay una sola línea temporal por activo — que es la única forma de contestar si vamos mejor o peor que el año pasado sin que la respuesta sea una impresión.

Haz esta prueba en tu empresa. Pregunta por el último hallazgo crítico: ¿está cerrado? Lo normal es que la respuesta tarde dos días y llegue en forma de cadena de correos. Alguien busca el PDF del pentest, alguien mira el Excel de seguimiento, alguien pregunta al desarrollador que lo tocó y que ya está en otro proyecto. Al final se responde «creemos que sí», que en seguridad significa «no».

Y no es por falta de herramientas. Es exactamente por lo contrario.

El problema no es tener pocas herramientas: es que ninguna se habla con otra

Una empresa de tamaño medio que se toma la seguridad en serio tiene, casi siempre, todo esto funcionando a la vez. Y todo esto viviendo en sitios distintos.

Dónde vive hoy vuestra seguridad

• El escaneo de infraestructura, en un PDF mensual que descarga una persona.
• El análisis de dependencias, en la salida del CI que nadie lee salvo cuando rompe el build.
• El pentest anual, en un informe por correo con su Excel de seguimiento anexo.
• El SAST, en la pestaña del repositorio con doscientas alertas abiertas desde 2024.
• La revisión de la nube, en una captura que alguien pegó en un documento.
• La declaración de aplicabilidad de la ISO, en una hoja de cálculo que se actualiza dos semanas antes de la auditoría.
• El SBOM, en ningún sitio, hasta que un cliente o el CRA lo piden por escrito.

Cada pieza, por separado, está bien. El conjunto no existe. Nadie tiene el inventario completo de lo que está abierto, nadie sabe cuánto lleva abierto, y la pregunta de si algo se corrigió de verdad se responde por confianza y no por evidencia. El coste de eso no se ve en la factura de las herramientas: se ve en las horas que se van en coordinar, y en los hallazgos que se quedan abiertos porque no eran de nadie.

Una vulnerabilidad sin responsable, sin plazo y sin verificación no es un hallazgo gestionado. Es una nota.

Todo entra por el mismo sitio, sin copiar y pegar salidas

La primera pregunta de cualquier equipo técnico es si tendrá que cambiar de herramientas. No. Lo que ya usáis sigue usándose: cambia dónde acaba su salida. Nessus, Nuclei, Burp Suite, Nmap, Black Duck y GitHub se conectan directamente, y con ellos el resto del ecosistema habitual.

Catálogo de 69 conectores de KOMPLIANCE, agrupado en catorce familias. Infraestructura y red: Nessus, OpenVAS, Nmap, Masscan, Greenbone. Web, API y aplicación: Burp Suite, Nuclei, OWASP ZAP, httpx, ffuf. Código fuente: Semgrep, SonarQube, CodeQL, Bandit, gosec. Dependencias, SBOM y licencias: Black Duck, Trivy, Syft, Grype, Dependency-Track, OSV. Repositorio y construcción: GitHub, GitLab, Bitbucket, Jenkins, GitHub Actions. Superficie y reconocimiento: Amass, subfinder, Shodan, crt.sh, dnsx. Nube y contenedores, configuración revisada en continuo: AWS, Azure, Google Cloud, Kubernetes, Terraform. Ofimática y colaboración: Microsoft 365, Google Workspace, Entra ID, Exchange, Drive. Detección y respuesta: Wazuh, EDR, SIEM, Sysmon. Vigilancia externa OSINT: filtraciones, credenciales expuestas, menciones de marca, dominios similares, certificados, repositorios públicos. Móvil, firmware y hardware: MobSF, apktool, Binwalk, Ghidra, radare2. Inteligencia de explotación: CISA KEV, EPSS, NVD, Exploit-DB, CyberPanorama. Salidas: Jira, Slack, Telegram, Teams, Wazuh, Splunk, Elastic y webhooks. Lo que no está en la lista entra por la API.

Lo importante de esa lista no son los nombres, es lo que pasa después de la ingesta: la salida de nueve herramientas con nueve escalas de severidad distintas se convierte en un único inventario comparable. Sin eso, tener diez integraciones solo significa tener diez informes en la misma pantalla, que es el mismo problema con mejor diseño.

Auditoría continua de lo que ya usáis, sin proyecto aparte

Hay una parte del cumplimiento que no se resuelve con un pentest anual, porque no va de vulnerabilidades: va de configuración. Y la configuración de las herramientas donde trabaja la plantilla cambia todas las semanas, casi siempre sin que nadie lo apunte.

Lo que se revisa solo, en continuo

• Microsoft 365 y Google Workspace: permisos heredados, buzones con delegación, ficheros compartidos con enlace público, reglas de reenvío, cuentas sin doble factor y administradores de más.
• Identidad: cuentas huérfanas, credenciales que no caducan y accesos que sobrevivieron a una baja.
• Nube: las cuentas de AWS, Azure y Google Cloud contrastadas contra las guías de referencia del proveedor y los marcos del sector, con cada hallazgo mapeado al control que incumple.
• Contenedores e infraestructura como código: lo que se va a desplegar, revisado antes de desplegarlo y no después.

La diferencia con contratar una revisión puntual de cada cosa es que el hallazgo no nace suelto: nace con el control que incumple pegado. Una carpeta compartida con enlace público no es solo una mala configuración, es evidencia que rellena un hueco del anexo A y del anexo II del ENS a la vez.

Y hacia el otro lado, lo explotable sale a donde ya vigiláis. Hay conectores con Wazuh y con varios EDR: lo que la plataforma considera aprovechable se convierte en una regla o en un aviso dentro de vuestra herramienta de detección, en lugar de quedarse en un panel más que alguien tiene que acordarse de abrir.

Lo que se ve de vosotros desde fuera

Todo lo anterior mira hacia dentro. Falta la mitad que el atacante ve primero y vosotros normalmente no: qué tenéis publicado sin saberlo, qué credenciales vuestras circulan ya en un volcado, quién está registrando dominios parecidos al vuestro y de qué se habla de vosotros en sitios donde nadie mira.

Panel de vigilancia externa de KOMPLIANCE, capa OSINT de recogida continua, con cifras de ejemplo y cuatro frentes seleccionables. Superficie expuesta, 128 activos vistos desde fuera: vigila dominios, subdominios y certificados nuevos, puertos y servicios abiertos sin pasar por nadie, paneles de administración accesibles desde internet y entornos de preproducción publicados por error; se registra sin molestar un subdominio nuevo que resuelve a un servicio ya controlado, y se avisa de un panel de administración o un entorno de preproducción alcanzable desde internet. Filtraciones y credenciales, 14 apariciones en el trimestre: vigila credenciales corporativas en volcados y mercados, claves y tokens publicados en repositorios, documentación interna en servicios de compartición abiertos y datos de clientes ofrecidos en foros; se registra una dirección corporativa en una brecha antigua ya rotada, y se avisa de una credencial válida de alguien con acceso remoto y sin doble factor. Menciones y suplantación, 6 dominios similares activos: vigila dominios parecidos y su contenido, perfiles que se hacen pasar por la empresa, menciones de marca en foros y canales de actores, y aplicaciones móviles publicadas en vuestro nombre; se registra un dominio parecido sin contenido ni correo configurado, y se avisa de uno con página de acceso copiada o con registros de correo activos. Comportamiento, 3 patrones seguidos: vigila accesos desde ubicaciones y horarios inusuales para ese usuario, cambios de permisos y reglas de reenvío de correo, descargas masivas y accesos a repositorios de documentación, y señales del EDR y del recolector de registros correlacionadas; se registra un acceso fuera de horario de quien trabaja habitualmente así, y se avisa de una regla de reenvío creada justo después de un acceso desde una ubicación nueva. El valor no está en el recuento sino en el criterio de aviso: un panel que avisa de todo se silencia en dos semanas.

Fíjate en la columna de la derecha del panel, porque es la única que importa. Contratar cuatro servicios de vigilancia distintos os deja cuatro fuentes de alertas que nadie correlaciona. Aquí el criterio es común y está conectado al inventario: una credencial filtrada de alguien con acceso remoto y sin doble factor no es la misma alerta que la misma credencial de alguien con acceso limitado, y la plataforma sabe cuál de los dos es porque tiene el inventario delante.

Eso es lo que hace la capa de comportamiento: no avisar de cada evento, sino de la combinación que importa. Un acceso desde una ubicación nueva es una línea de registro; un acceso desde una ubicación nueva seguido de la creación de una regla de reenvío de correo es una llamada. El objetivo declarado del panel no es enseñaros datos: es deciros cuándo hay que actuar.

Triaje: de cuatro mil alertas a nueve decisiones

Aquí está el trabajo de verdad. Un cliente con nueve fuentes activas genera miles de hallazgos al trimestre, y el valor no está en enseñarlos todos bonitos: está en los cortes que dejan nueve encima de la mesa. Cada corte tiene un criterio que se puede discutir, y por eso se enseña.

Embudo de triaje de KOMPLIANCE con datos de una campaña de ejemplo. Entran 4.812 hallazgos en bruto de nueve fuentes, sin normalizar y con severidades incomparables. Tras deduplicar y correlacionar quedan 1.203, una reducción del 75 por ciento, porque el mismo fallo lo ven tres herramientas distintas y es una sola corrección. Filtrando lo que aplica a la versión y configuración reales quedan 418. Priorizando por contexto (exposición real, criticidad del activo y probabilidad de explotación EPSS, con CVSS v4 como base y no como veredicto) quedan 64. Con explotación conocida, es decir presentes en el catálogo KEV de CISA o con exploit público, quedan 9. Y esas 9 pasan a tener responsable nominal, SLA por severidad y una reprueba obligatoria para cerrarse. El motor hace los cuatro primeros cortes; los dos últimos los firma un analista.

Fíjate en el cuarto corte, que es donde casi todas las plataformas se quedan cortas. El CVSS mide la gravedad técnica de una vulnerabilidad en abstracto, no su riesgo en tu empresa. Un 9.8 en un servicio interno sin salida a internet pesa menos que un 7.5 en el portal donde entran vuestros clientes. Para decidir eso hace falta cruzar tres cosas que ninguna base de datos pública conoce: qué está expuesto de verdad, qué dato toca cada activo y cuánto duele que ese activo caiga.

Lo que añade el analista y no añade el motor

• Descartar un CVE porque el módulo vulnerable no se compila en vuestra construcción, que es distinto de que no aparezca en el boletín.
• Encadenar dos hallazgos medios que juntos dan acceso completo, algo que ninguna puntuación individual refleja.
• Decidir que una severidad alta puede esperar tres semanas porque hay una mitigación real en el perímetro, y dejarlo escrito.
• Firmar que algo es crítico, que es una afirmación con consecuencias y por eso lleva nombre y apellidos.

El SBOM solo sirve si algo lo vigila todos los días

El inventario de componentes se ha convertido en obligación: el anexo I del Cyber Resilience Act lo exige a los fabricantes, y los cuestionarios de cliente lo piden desde antes. El problema es que la mayoría de los SBOM que se generan son un fichero CycloneDX que se produce para cumplir, se adjunta a un correo y envejece en el instante en que se firma.

Un SBOM vigilado es otra cosa. Es el inventario cruzado de forma continua contra tres fuentes: las vulnerabilidades conocidas, el catálogo KEV de CISA —el registro de lo que se está explotando de verdad ahí fuera— y la licencia de cada componente, que es la parte que nadie mira hasta que legal pregunta si se puede redistribuir eso dentro de un producto cerrado.

Panel de SBOM de KOMPLIANCE con datos de ejemplo sobre un inventario de 412 componentes en formato CycloneDX 1.6, cruzado de forma continua contra el catálogo KEV de CISA. Tres indicadores: 2 componentes explotándose ahora, 3 con licencia copyleft fuerte y 2 sin parche disponible upstream. La tabla lista cada componente con su versión, versión corregida, licencia, CVE asociado, puntuación EPSS, marca de explotación activa y en qué parte del producto vive. Ejemplos: log4j-core 2.14.1 con CVE-2021-44228, EPSS 0,94, en KEV, presente en el backend; spring-beans 5.3.17 con CVE-2022-22965, EPSS 0,97, en KEV, en la API pública; busybox 1.31.1 con licencia GPL-2.0 en el firmware; u-boot 2020.04 sin parche disponible en el gestor de arranque; ffmpeg 4.2.4 con licencia GPL-2.0-or-later en la app móvil. Se puede filtrar por lo que está en KEV, por riesgo de licencia y por lo que no tiene parche.

La diferencia práctica entre las dos cosas se ve en una sola pregunta: cuando aparece un CVE que se está explotando de forma masiva, ¿cuánto tardáis en saber si os afecta?

La capa agéntica: lo que pasa entre campañas

Un pentest es una foto de un momento. Vale mucho, pero la superficie de una empresa cambia todas las semanas: alguien publica un subdominio, alguien actualiza una dependencia, alguien expone un panel de administración «un rato» para depurar y se queda seis meses. Entre una campaña y la siguiente hay once meses en los que, tradicionalmente, no mira nadie.

Eso es lo que cubren los agentes, y son los mismos que trabajan durante la auditoría: el mismo contexto de 0data, la misma orquestación, solo que sin fecha de fin. Cada uno tiene una tarea acotada, una cadencia y —esto es lo que importa— un límite declarado por escrito de qué decide solo y qué escala a una persona. Un agente sin ese límite no es una ventaja, es una caja negra a la que nadie va a confiar la priorización de su riesgo.

Los seis agentes de KOMPLIANCE, cada uno con su cadencia, qué hace, qué dispara y qué escala a una persona. Agente de superficie (diario): redescubre subdominios, puertos y paneles expuestos; escala cualquier servicio de administración accesible desde internet. Agente de SBOM (en cada construcción): regenera el inventario por producto y versión y compara con el anterior; escala las licencias incompatibles con la distribución del producto. Agente de KEV y explotación (continuo): cruza el inventario contra el catálogo KEV de CISA y las puntuaciones EPSS cada vez que cambian; escala siempre y con aviso inmediato. Agente de triaje (por lote): deduplica, correlaciona con el historial y propone severidad contextual con el razonamiento a la vista; escala todo lo que proponga como crítico. Agente de evidencia (continuo): recoge y fecha revisiones de acceso, restauraciones, formación e incidentes; escala los controles obligatorios en rojo a menos de 60 días de auditoría. Agente de reprueba (al marcar corregido): relanza la comprobación automatizable y avisa si el vector sigue funcionando. Debajo, la línea humana: responde el analista que encontró el fallo y no una cuenta genérica; ningún agente acepta un riesgo, cierra un hallazgo crítico ni firma que un control cumple.

El efecto acumulado es el que se nota en la factura del año siguiente: la campaña de pentest deja de empezar con dos semanas de descubrimiento, porque el inventario ya está y está al día. Y los hallazgos fáciles —el panel expuesto, la dependencia con CVE público— se cierran cuando aparecen, no once meses después y en un informe de cien páginas.

Cumplimiento en tiempo real: ISO 27001, CRA y ENS sobre la misma evidencia

Aquí está la parte que casi nadie junta, y es la que más horas ahorra. Las tres normas que se cruzan en una empresa española —la ISO 27001 porque lo pide un cliente, el CRA porque fabricáis producto conectado, el ENS porque vendéis a la Administración— piden pruebas de las mismas cosas con palabras distintas.

El mismo trabajo, tres expedientes

• Gestión de vulnerabilidades técnicas: control A.8.8 de la ISO, anexo I parte II del CRA, medidas de operación del ENS.
• Inventario de activos y componentes: A.5.9 de la ISO, SBOM obligatorio en el CRA, marco operacional del ENS.
• Registro y notificación de incidentes: A.5.24 y siguientes, el reloj del artículo 14 del CRA, y la notificación al CCN-CERT.
• Continuidad y copias probadas: A.5.29 y A.8.13, disponibilidad en el ENS, resiliencia en el CRA.
• Control de proveedores: A.5.19 a A.5.22, cadena de suministro en el CRA, terceros en el ENS.

Cuando esas evidencias viven en la misma plataforma, una revisión de accesos hecha una vez cuenta para los tres expedientes a la vez. Y el porcentaje de cumplimiento deja de ser una estimación que alguien teclea el viernes: se deduce de si la evidencia de cada control está fresca dentro de su propia periodicidad.

Los tres módulos de cumplimiento de KOMPLIANCE en pestañas, con porcentajes de ejemplo de controles con evidencia viva. Módulo ISO 27001 (ISO/IEC 27001:2022, cláusulas 4 a 10 y anexo A con 93 controles), 78 por ciento: vigila la declaración de aplicabilidad viva, el control A.8.8 de vulnerabilidades técnicas alimentado desde el gestor de hallazgos, el ciclo de auditoría interna (9.2) y revisión por la dirección (9.3), y el control de proveedores; recoge sola la evidencia de revisiones de acceso, restauraciones de copia probadas, formación con asistencia y registro de incidentes; exporta SoA, informe para el auditor y plan de tratamiento de riesgos; próxima auditoría de seguimiento en 74 días. Módulo CRA (Reglamento UE 2024/2847, anexo I partes I y II), 61 por ciento: vigila el SBOM por producto y versión, el reloj del artículo 14 con sus 24 horas de alerta temprana, 72 de notificación y 14 días para el informe final, el periodo de soporte declarado y la política de divulgación coordinada; exporta SBOM en CycloneDX o SPDX, documentación técnica y borrador de notificación. Módulo ENS (Real Decreto 311/2022, anexo II), 84 por ciento: vigila las medidas por categoría básica, media o alta, el análisis de riesgos con MAGERIT, el perfil de cumplimiento y las pruebas de penetración periódicas que exige la categoría alta; exporta declaración de conformidad, perfil de cumplimiento e informe de auditoría.

Un matiz importante, porque es donde el software se vende de más: esto no os certifica. El certificado de la ISO y del ENS lo emite una entidad acreditada e independiente, y el marcado CE del CRA sigue su propia ruta de evaluación de conformidad. Lo que hace la plataforma es tener listo, y con fecha, todo lo que esa auditoría va a pedir — que es justo la parte que se hace a última hora y mal.

El cerebro documental: preguntar en lugar de buscar

Cualquier sistema de gestión genera una montaña de documentos, y el problema nunca es escribirlos: es que a los seis meses nadie sabe qué versión está aprobada, qué decía el contrato de aquel proveedor sobre notificación de brechas, ni qué le prometimos a aquel cliente en un cuestionario de sesenta preguntas. Cientos de ficheros haciendo de pisapapeles.

La plataforma indexa toda esa documentación —políticas, contratos, actas, informes, expedientes, la normativa aplicable— en un RAG con modelo local y la conecta al agente. Deja de ser una carpeta compartida y pasa a ser algo a lo que se pregunta.

Cerebro documental de KOMPLIANCE: la documentación de cumplimiento indexada en un RAG con modelo local y conectada al agente, con preguntas reales de ejemplo y la fuente citada en cada respuesta. Preguntas como: ¿tenemos política de teletrabajo aprobada y desde cuándo? (responde con la política vigente, el acta del comité y el registro de comunicación a la plantilla, y avisa cuando toca revisarla); ¿qué dice el contrato de este proveedor sobre notificación de brechas? (devuelve el texto literal de la cláusula, el encargo de tratamiento y la ficha del proveedor); ¿qué evidencia tenemos del control de vulnerabilidades técnicas este año? (campañas ejecutadas, informes con fechas, reprobaciones cerradas y registro de parches, ordenado por fecha); ¿este hallazgo ya estaba en el informe del año pasado? (lo marca como regresión si se cerró y ha vuelto); ¿nos obliga el CRA a declarar periodo de soporte para este producto? (cruza la ficha del producto con el reglamento y devuelve el artículo aplicable); ¿qué le prometimos a este cliente en el cuestionario de seguridad? (las respuestas enviadas con fecha y si alguna se ha desalineado de la realidad). Se indexan políticas y procedimientos con su versión y fecha de aprobación, informes de auditoría y pentest propios y de terceros, contratos y encargos de tratamiento, declaración de aplicabilidad y expedientes, actas de comité y de revisión por la dirección, normativa y guías del regulador, y cuestionarios de cliente respondidos. Sin fuente no hay respuesta: si la documentación no lo dice, el agente contesta que no lo dice. El modelo corre en la misma infraestructura que la plataforma, así que las políticas, los contratos y los informes de intrusión no se mandan a un proveedor de IA de terceros, lo que hace posible el despliegue on-premise.

Hay un matiz que decide la compra en sectores regulados: el modelo corre en vuestra infraestructura. Vuestras políticas, vuestros contratos y vuestros informes de intrusión no viajan a un proveedor de IA de terceros. Es lo que permite indexar documentación que, de otro modo, no tendría permiso para salir de vuestra red — y lo que hace que el cerebro documental siga existiendo en un despliegue on-premise.

La otra mitad del valor está en quién pregunta. El rol administrativo lo usa para preparar una auditoría o responder a un cliente; legal, para saber qué firmamos; el equipo técnico, para no repetir un trabajo que ya se hizo. Es la misma base documental contestando tres preguntas distintas.

La reprueba es la única forma de cerrar algo

Volvamos a la pregunta del principio. La razón de que «¿está cerrado?» no tenga respuesta en la mayoría de las empresas es que el ciclo termina cuando el desarrollador marca la tarea como hecha. Eso no es el cierre: es una declaración de intenciones. El cierre es que alguien vuelva a intentar el ataque y no pueda.

Y «reprobar» no significa lo mismo en todas partes, que es de donde salen casi todas las discusiones de alcance a mitad de proyecto. Verificar un fallo de firmware exige volver a extraer la imagen; verificarlo en una API es relanzar una colección de peticiones; verificarlo en hardware necesita unidades nuevas del lote corregido y logística. El plazo y la evidencia de cierre cambian por completo.

Selector de reprueba por superficie en KOMPLIANCE, con qué se comprueba, qué evidencia cierra el hallazgo, el plazo habitual y dónde suelen fallar las reprobaciones. Firmware: se vuelve a extraer la imagen publicada y se compara con la anterior, verificando que el componente subió de versión de verdad, que el arranque seguro sigue validando y que no se reintrodujeron claves; cierra la diferencia entre imágenes con hash; 3 a 5 días; si la corrección llega como parche fuente y no como imagen firmada no hay reprueba posible. Apps y web: se repite el flujo con los mismos roles, se prueban las variantes del mismo patrón en otros endpoints y se comprueba que el control se aplica en servidor y no solo en la interfaz; cierra la captura del intento fallido con la petición íntegra; 1 a 3 días; la mitad de los fallos es haber arreglado la pantalla y no la comprobación del servidor. Hardware: se repite el ensayo original sobre una unidad del lote corregido, verificando que la interfaz de depuración está cerrada y que las contramedidas declaradas resisten; 1 a 2 semanas porque la logística pesa más que el análisis; hacen falta unidades nuevas y los ensayos pueden dejarlas inservibles. Nube: se revisa la configuración vigente y no la plantilla, comprobando que el permiso excesivo desapareció en la cuenta real, que no quedan recursos huérfanos y que el cambio está en la línea base; cierra la salida del control automatizado antes y después; horas; corregir a mano en la consola y no en el código de infraestructura garantiza que el fallo vuelva. Backend y API: se revisa el endpoint corregido y sus vecinos porque el patrón nunca está en un solo sitio, comprobando la autorización en todos los métodos y que el identificador ya no da acceso a datos de otro cliente; cierra una colección de peticiones reproducible; 1 a 3 días; el aislamiento entre clientes es donde más reprobaciones se caen.

Cuando la reprueba está dentro del ciclo y no es una partida que se contrata aparte y se olvida, el indicador que aparece solo es el que de verdad mide si un programa de seguridad funciona: cuántos hallazgos críticos llevan más de treinta días abiertos. Ese número, y no el recuento total, es el que enseñáis en el comité.

Soporte legal, de cumplimiento y de ciberseguridad

Una plataforma de seguridad recibe dos tipos de pregunta. Las técnicas —«¿por qué esto es explotable si tenemos WAF?»— y las otras, que casi siempre llegan con más urgencia: un cliente ha mandado un cuestionario de sesenta preguntas, el auditor pide una evidencia que no sabéis si tenéis, alguien del comité quiere saber en una frase si estamos peor que el año pasado.

Las dos son soporte, y las dos las contesta gente que ha estado en el otro lado: quien encontró el fallo responde la primera, y quien ha pasado por una auditoría de certificación responde la segunda. No hay primer nivel que filtre, ni cuenta genérica, ni un asistente que devuelva el manual reformulado. Esa es la parte del producto que no se puede automatizar, y el motivo de que los agentes lleven escrito dónde paran.

Y hay un tercer tipo de pregunta que casi nunca tiene a quién dirigirse: la legal. Qué firmamos en aquel anexo de seguridad, si una cláusula de notificación nos obliga a avisar en este caso concreto, qué implica un encargo de tratamiento cuando el proveedor subcontrata, si el pliego de esa licitación exige certificado o solo alineamiento. Esa línea también está cubierta, y se apoya en el cerebro documental: la respuesta llega con el documento citado al lado, no como opinión.

El valor de un panel de seguridad no está en el panel. Está en que, cuando algo se pone rojo, hay alguien al otro lado que sabe qué hacer y puede decírtelo hoy.

Qué no hace, para que nadie se lleve una sorpresa

Es la sección que falta en casi todas las páginas de producto, y la que más confianza da cuando está.

• No es un SIEM ni un EDR. No detecta al atacante en ejecución: alimenta con lo explotable al SIEM que ya tengáis. Son capas distintas del mismo problema.
• No sustituye al pentest manual. Ninguna integración encuentra una cadena lógica de negocio ni un fallo de aislamiento entre clientes. La plataforma es donde vive el hallazgo, no quien lo encuentra.
• No os certifica. La ISO 27001 y el ENS los certifica una entidad acreditada e independiente; el CRA tiene su propia ruta de conformidad.
• No acepta riesgos por vosotros. Un agente propone severidad; aceptar un riesgo es una decisión de negocio y lleva firma de persona.
• No arregla el código. Prioriza, asigna, verifica y deja constancia. Corregir sigue siendo del equipo de desarrollo, con la diferencia de que ahora sabe qué corregir primero.

Por dónde se empieza

La puerta de entrada habitual es una auditoría. Se contrata el pentest o la revisión que hacía falta de todos modos, y la plataforma llega con ella: el alcance, los hallazgos, el informe y la reprueba ya viven dentro sin coste de implantación ni migración posterior. Cuando el proyecto termina, ya tenéis el inventario y el histórico, que es justo lo que cuesta arrancar desde cero.

Si lo que queréis es empezar por la plataforma sin auditoría de por medio, el orden es el otro: primero el inventario —qué activos hay y qué componentes llevan dentro—, porque sin eso ningún triaje se sostiene, y después dos o tres herramientas que ya uséis para ver la deduplicación sobre datos vuestros. Los módulos de cumplimiento se activan según lo que os aplique, y el despliegue on-premise se decide en esta fase, no después.

Si lo que tenéis delante es una certificación o un plan director, la ficha de alcance ISO 27001 y plan director recoge en diez bloques el punto de partida, el alcance, la madurez real de vuestros controles y los entregables — y distingue si ya estáis certificados o partís de cero, porque no son el mismo trabajo. Si lo que toca es una campaña de pruebas, la ficha de alcance de pentesting hace lo propio con los activos y los límites.

Cobertura de toda vuestra infraestructura y de todos vuestros productos en un solo sitio, y sin que montarlo se convierta en otro proyecto que gestionar.

Y si preferís verlo antes de leer nada más: media hora con vuestros datos encima de la mesa aclara más que cualquier página de producto, esta incluida.

Servicio relacionado

análisis de vulnerabilidades continuo

Temas de este artículo

#Auditoría-de-seguridad #Gestión-de-vulnerabilidades #SBOM #CISA-KEV #Cumplimiento #ISO-27001 #Cyber-Resilience-Act #Agentes-autónomos

Seguir leyendo

• Un pentest mal dimensionado no sale barato: sale inútil
• ¿En qué cajón cae tu producto? Un clasificador interactivo del Cyber Resilience Act
• MCP: confianza ciega, riesgo máximo

Fuentes

• CISA — Known Exploited Vulnerabilities Catalog
• FIRST — Exploit Prediction Scoring System (EPSS)
• Reglamento (UE) 2024/2847 — Cyber Resilience Act
• Real Decreto 311/2022 — Esquema Nacional de Seguridad
• CycloneDX — especificación de SBOM (OWASP)

Ver KOMPLIANCE con vuestros datos