CSPM vs pentesting cloud: qué detecta cada uno y cuándo necesitas cada cual

Por Kike Gandia · Co-Fundador y CEO, OSCP

Un CSPM (Cloud Security Posture Management) revisa de forma continua la configuración de tus cuentas cloud contra un conjunto de reglas y te dice qué se desvía. Un pentesting cloud pone a un equipo humano a intentar lo que haría un atacante con lo que encuentre y te dice hasta dónde llega. Se confunden porque los dos producen una lista de problemas de seguridad en AWS, Azure o Google Cloud, pero responden a preguntas distintas y ninguno sustituye al otro. En esta guía verás qué hace bien cada uno, qué se le escapa, qué significan las siglas que lo rodean (CIEM, CWPP, KSPM, CNAPP), qué piden las normas y en qué orden conviene ponerlos en marcha según tu madurez.

Qué es un CSPM y qué hace exactamente

Un CSPM es una herramienta que se conecta a tus cuentas, suscripciones o proyectos cloud con permisos de solo lectura, inventaría los recursos a través de las APIs del proveedor y compara su configuración, de forma continua, con un conjunto de reglas: los CIS Benchmarks, el marco de referencia del propio proveedor —como el Microsoft Cloud Security Benchmark— o los controles de normas como ISO 27001 o PCI DSS. Lo que devuelve es una lista de recomendaciones ordenadas por severidad y, casi siempre, una puntuación de postura que permite ver la evolución.

Ejemplos típicos de lo que detecta:

Un bucket o contenedor de almacenamiento con acceso público.
La cuenta raíz o un administrador sin MFA.
El registro de actividad (CloudTrail, el registro de actividad de Azure, los Cloud Audit Logs) desactivado en alguna región o proyecto.
Un grupo de seguridad que abre SSH o RDP a todo internet.
Claves de acceso de larga duración que nadie ha rotado en meses.
Bases de datos o discos sin cifrar, o instancias que todavía aceptan la versión antigua del servicio de metadatos.

Las opciones se agrupan en tres familias:

Familia	Ejemplos	Qué tener en cuenta
Nativas del proveedor	AWS Security Hub CSPM, Microsoft Defender for Cloud, Google Security Command Center	Se activan en minutos; Defender for Cloud incluye un nivel gratuito, Foundational CSPM, que también evalúa cuentas de AWS y proyectos de GCP conectados
Código abierto	Prowler	Multicloud, se ejecuta bajo demanda o programado y exporta los resultados; requiere que alguien lo opere
Plataformas comerciales (CNAPP)	Varios fabricantes	Añaden contexto: análisis de rutas de ataque, datos sensibles, vulnerabilidades de las cargas de trabajo y Kubernetes

En todos los casos el principio es el mismo: la herramienta lee la configuración y la evalúa contra reglas. No intenta explotar nada.

Qué es un pentesting cloud y qué pregunta responde

Un pentesting cloud es un ejercicio puntual, con alcance y reglas acordadas por escrito, en el que un equipo humano parte de un supuesto realista e intenta llegar lo más lejos posible. Los supuestos más habituales son:

Atacante externo: solo con lo que se ve desde internet, como endpoints, buckets, funciones expuestas o subdominios que apuntan a recursos que ya no existen.
Credencial filtrada: una clave de acceso de un desarrollador publicada en un repositorio o robada de un portátil.
Carga de trabajo comprometida: una aplicación con una vulnerabilidad que da ejecución de código o lectura de ficheros en una máquina, un contenedor o una función serverless.
Identidad de bajo privilegio: un usuario o rol con permisos limitados, para medir si puede escalar.

La pregunta que responde no es «qué está mal configurado», sino «qué puede conseguir un atacante con lo que hay»: leer datos de clientes, obtener credenciales de producción, moverse a otras cuentas de la organización o tomar el control de la cuenta entera. El resultado son cadenas de ataque demostradas con evidencias y un plan de corrección priorizado por impacto real.

La diferencia de fondo cabe en una frase: el CSPM evalúa cada recurso contra una regla; el pentest evalúa lo que permiten los recursos combinados.

CSPM vs pentesting cloud: comparativa

Aspecto	CSPM	Pentesting cloud
Pregunta que responde	¿Qué configuraciones se desvían de una línea base?	¿Hasta dónde llega un atacante y qué consigue?
Cómo trabaja	Reglas automáticas sobre la configuración, con permisos de lectura	Personas que combinan herramientas, análisis manual y explotación controlada
Frecuencia	Continua: detecta un cambio poco después de que ocurra	Puntual: anual, antes de un hito o tras un cambio grande
Cobertura	Todas las cuentas y recursos conectados	El alcance acordado, en profundidad
Contexto de negocio	Limitado: no sabe qué guarda cada recurso salvo que se lo indiques	Central: se prioriza por lo que el atacante obtiene
Explotación	No: señala el riesgo	Sí: lo demuestra, con límites pactados
Capa de aplicación	Fuera de su alcance	Puede incluir las APIs, funciones y aplicaciones desplegadas
Ruido	Muchos hallazgos sin impacto real en tu contexto	Pocos: cada hallazgo se confirma antes de reportarlo
Detección y respuesta	No las pone a prueba	Comprueba si tus alertas saltan cuando alguien actúa
Modelo de coste	Suscripción o consumo continuo	Proyecto con alcance cerrado

Leída por columnas, la tabla explica por qué las dos cosas conviven: el CSPM da cobertura y continuidad; el pentest da profundidad y contexto.

Lo que un CSPM hace mejor que cualquier pentest

Sería un error presentar el pentest como la versión «buena» y el CSPM como la «barata». Hay cosas que una herramienta de postura hace mejor y que ningún ejercicio puntual puede igualar:

Detectar la deriva. El pentest es una foto; la configuración cambia en cada despliegue. Si alguien abre un puerto a internet un viernes para depurar un problema y se olvida de cerrarlo, el CSPM lo verá en cuanto lo evalúe; el pentest del año pasado, nunca.
Cubrirlo todo. Decenas de cuentas, todas las regiones y los proyectos que nadie recuerda haber creado. Un pentest siempre se acota.
Generar evidencias de cumplimiento. Un informe continuo contra un marco de control es lo que pide un auditor de ISO 27001 o del ENS para demostrar que la configuración se vigila, no solo que se revisó una vez.
Dar inventario. Saber qué recursos existen es el primer control. Muchas organizaciones descubren con el CSPM servicios que no sabían que tenían.
Encontrar lo obvio a bajo coste. No tiene sentido pagar horas de un pentester para descubrir que la cuenta raíz no tiene MFA o que el registro de actividad está apagado.

Por eso, si hoy no tienes nada, el orden lógico es activar el CSPM nativo o pasar Prowler, corregir lo crítico y, después, contratar el pentest. Así el pentest dedica su tiempo a lo que solo encuentra una persona.

Lo que un CSPM no ve y un pentest sí

Las limitaciones de un CSPM no son defectos de un producto concreto: vienen de su forma de trabajar, que es leer configuración y aplicar reglas.

Cadenas de ataque. Tres hallazgos de severidad media pueden sumar uno crítico. Por ejemplo: una aplicación con una vulnerabilidad SSRF, una instancia que todavía acepta la versión 1 del servicio de metadatos y un rol asociado con lectura sobre todos los buckets. El CSPM marca los dos últimos entre cientos de recomendaciones; el SSRF ni lo ve, porque está en el código. Juntos, permiten a un atacante en internet descargar los datos.
Escalada de privilegios en IAM. Hay permisos que solo son peligrosos combinados. Quien puede crear una función, asignarle un rol (iam:PassRole) e invocarla, puede ejecutar código con los privilegios de ese rol aunque su propio usuario parezca limitado. Las plataformas más avanzadas modelan estas rutas en un grafo, pero lo infieren de la configuración que leen; el pentest comprueba si la ruta es explotable de verdad, teniendo en cuenta políticas de la organización, límites de permisos y condiciones.
Lo que corre encima de la infraestructura. SSRF, inyecciones, autorización rota en la API o deserialización insegura en una función: el CSPM sabe que la función existe, no lo que hace.
Secretos fuera de los recursos conectados. Claves en el historial de Git, en variables del pipeline de CI/CD, en imágenes de contenedor publicadas o en logs. Algunas plataformas escanean parte de esto, pero solo donde llegan.
Lo que no está conectado. Cuentas de pruebas creadas fuera de la organización, el entorno de un proveedor que accede a tu cuenta o el interior de un clúster de Kubernetes —RBAC, pods, secretos— si la herramienta no evalúa Kubernetes.
Confianzas mal definidas. Roles que se pueden asumir desde otra cuenta sin un identificador externo, o federaciones de identidad —como el acceso desde GitHub Actions por OIDC— cuya condición permite que cualquier repositorio obtenga credenciales.
Tu capacidad de detección. Un pentest comprueba si GuardDuty, Defender for Cloud o tu SOC alertan cuando alguien enumera permisos, crea claves o descarga datos. Un CSPM puede decirte que el servicio de detección está activado, no si alguien mira las alertas.

CSPM, CIEM, CWPP, KSPM, DSPM y CNAPP: el glosario

Alrededor del CSPM ha crecido una sopa de siglas. Conviene conocerlas para saber qué cubre la herramienta que ya tienes o la que te ofrecen:

Siglas	Nombre	Qué mira	Ejemplo de hallazgo
CSPM	Cloud Security Posture Management	Configuración de los servicios cloud	Bucket público, registro de actividad desactivado
CIEM	Cloud Infrastructure Entitlement Management	Identidades y permisos efectivos	Rol con permisos que no ha usado en meses, usuario que puede convertirse en administrador
CWPP	Cloud Workload Protection Platform	Cargas de trabajo: máquinas, contenedores y funciones	Imagen con una vulnerabilidad crítica, proceso sospechoso en un contenedor
KSPM	Kubernetes Security Posture Management	Configuración de los clústeres de Kubernetes	Pod privilegiado, enlace a cluster-admin innecesario
DSPM	Data Security Posture Management	Dónde hay datos sensibles y quién puede leerlos	Copia de una base de datos con datos personales en un bucket de pruebas
CNAPP	Cloud-Native Application Protection Platform	Une varias de las anteriores en una sola plataforma	Ruta de ataque desde internet hasta datos sensibles

Dos matices. Primero, cada fabricante interpreta las siglas a su manera; lo que importa es qué capas cubre la herramienta y con qué profundidad, no la etiqueta. Segundo, ninguna de ellas es un pentest: todas observan configuración y estado, y ninguna intenta el ataque como lo haría un adversario.

Falsos positivos, priorización y fatiga de alertas

El problema práctico de un CSPM rara vez es que detecte poco, sino que detecta demasiado. En una organización con varias cuentas es normal que la primera evaluación devuelva cientos de recomendaciones, y muchas no tienen impacto real en ese contexto:

Un bucket público que sirve los ficheros estáticos de una web pública es intencionado.
Una clave sin rotar en una cuenta de laboratorio vacía no es lo mismo que en la cuenta de producción.
Un grupo de seguridad abierto delante de un balanceador que solo publica HTTPS es el diseño, no un error.

Cuando todo es «alto», nada lo es, y los equipos acaban ignorando el panel. Ahí es donde se complementan: el pentest identifica cuáles de esas recomendaciones forman parte de una cadena real y cuáles son ruido en tu entorno, y eso permite ajustar el CSPM con excepciones documentadas y severidades acordes con tu contexto.

La relación también funciona al revés. Cada hallazgo de un pentest debería acabar convertido en algo que impida que vuelva a ocurrir: una regla personalizada en el CSPM, una política de la organización (SCP en AWS, Azure Policy, políticas de organización en Google Cloud) o una comprobación en el pipeline de infraestructura como código. Si el informe del pentest se archiva sin eso, el mismo fallo reaparecerá en el siguiente despliegue.

Cómo combinarlos: un ciclo que funciona

En la práctica, el orden que mejor resultado da es este:

Visibilidad: CSPM nativo o Prowler en todas las cuentas, con el registro de actividad centralizado en una cuenta a la que los equipos de desarrollo no tengan acceso de escritura.
Corregir lo evidente: acceso público no intencionado, MFA en cuentas raíz y administradores, claves de larga duración, registro desactivado, metadatos sin proteger.
Pentest centrado en identidades y cadenas: con los supuestos de credencial filtrada, carga de trabajo comprometida e identidad de bajo privilegio, que es donde un CSPM se queda corto.
Convertir hallazgos en guardarraíles: políticas de organización, reglas personalizadas y comprobaciones en el código de infraestructura.
Re-test: comprobar que cada corrección cierra la cadena, no solo el hallazgo aislado.
Repetir: tras cambios grandes —nueva arquitectura, migración, nueva cuenta de producción, una adquisición— y con la periodicidad que exijan tu marco normativo o tus clientes.

Y según el punto de partida:

Situación	Qué hacer primero	Cuándo encaja el pentest
Una cuenta, sin herramienta de postura	Prowler o el CSPM nativo y corregir lo crítico	Antes de un hito: cliente enterprise, ronda de inversión, certificación
Varias cuentas y equipos desplegando a diario	CSPM continuo con un responsable por tipo de hallazgo	Anual y tras cambios de arquitectura, con foco en IAM y cadenas de ataque
Entidad regulada (ENS, NIS2, DORA, PCI DSS)	CSPM con mapeo al marco y evidencias exportables	Con la periodicidad del marco, como prueba de eficacia de los controles
Después de un incidente	Revisar por qué el CSPM y la detección no alertaron	Inmediato, reproduciendo el supuesto del incidente

Qué piden las normas y los clientes

Ninguna norma obliga a comprar un CSPM, y casi ninguna menciona el pentest cloud con ese nombre, pero varias piden las dos cosas que aportan: vigilancia continua de la configuración y verificación de que los controles funcionan.

ENS (Real Decreto 311/2022): la medida op.nub.1, «Protección de servicios en la nube», exige que, cuando se usen servicios en la nube de terceros, los sistemas que los soportan sean conformes con el ENS o cumplan una guía CCN-STIC que incluye, entre otros requisitos, una «auditoría de pruebas de penetración (pentesting)». En categoría media y alta añade la certificación del servicio y, en alta, configuraciones de seguridad conforme a las guías del CCN.
ISO/IEC 27001:2022: el control 5.23 cubre la seguridad de la información en el uso de servicios en la nube y el 8.8, la gestión de vulnerabilidades técnicas. Un CSPM es una buena evidencia de seguimiento continuo; un pentest, de que las vulnerabilidades se buscan activamente.
NIS2: el artículo 21 exige políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos. Un panel de postura demuestra que existen controles; un pentest, que funcionan.
DORA: el programa de pruebas de resiliencia operativa digital incluye expresamente las pruebas de penetración entre las pruebas que deben realizar las entidades financieras sobre sus sistemas, también los alojados en la nube.
Clientes enterprise y due diligence: los cuestionarios de seguridad suelen pedir el informe de un pentest reciente con su alcance. Una captura del panel del CSPM no lo sustituye.

FAQ

Si ya tenemos un CSPM, ¿necesitamos además un pentesting cloud?

Si tu entorno guarda datos o servicios que importan, sí. El CSPM te dice qué configuraciones se desvían de una línea base; no comprueba si un atacante puede encadenarlas, ni revisa la aplicación que corre encima, ni pone a prueba tu detección. El pentest responde justo a eso, y además ayuda a priorizar el ruido del CSPM.

¿Puede un pentest sustituir a un CSPM?

No. Un pentest es una foto de un momento y de un alcance acotado; la configuración cambia en cada despliegue. Sin una herramienta que vigile de forma continua, un error introducido la semana después del pentest puede quedarse abierto hasta el siguiente.

¿Hay algún CSPM gratuito para empezar?

Sí. Microsoft Defender for Cloud incluye Foundational CSPM sin coste, que también puede evaluar cuentas de AWS y proyectos de Google Cloud conectados, y Prowler es una herramienta de código abierto que cubre los tres proveedores. Las funciones avanzadas, como el análisis de rutas de ataque, suelen estar en los planes de pago.

Las herramientas con análisis de rutas de ataque, ¿no hacen ya lo mismo que un pentest?

Hacen algo útil y distinto: deducen posibles rutas a partir de la configuración que pueden leer, lo que ayuda mucho a priorizar. Pero no comprueban si la ruta es explotable en la práctica, no ven vulnerabilidades del código desplegado ni lo que queda fuera de las cuentas conectadas, y no miden si alguien reacciona cuando se intenta.

¿Cada cuánto conviene hacer un pentest cloud si ya tenemos CSPM?

Como referencia, una vez al año y siempre tras un cambio grande: una nueva arquitectura, una migración, una nueva cuenta de producción o la integración de otra empresa. Si te aplica un marco concreto, como PCI DSS, DORA o el ENS, o un cliente lo exige por contrato, manda esa periodicidad.

¿El pentester usa también herramientas de postura?

Sí, en un pentest de caja blanca es habitual pasar al principio una herramienta de postura como Prowler y otras de enumeración como CloudFox para tener una visión general rápida. Pero es el punto de partida, no el entregable: el valor está en lo que viene después, que es comprobar qué permite cada hallazgo combinado con los demás.