Post actualizado el día octubre 27, 2026 by DeiviSanzPlay
El sector del pentesting atraviesa un momento incómodo: las herramientas están mejorando más rápido que las metodologías. Durante años, el entregable estándar de una prueba de penetración fue un PDF con hallazgos clasificados por CVSS. En 2026, ese formato empieza a quedarse corto frente a infraestructuras que cambian cada hora y frente a clientes que ya no preguntan solo «¿qué falla?» sino «¿qué fue explotado realmente?».
De la foto fija al pentesting continuo
La tendencia más visible, y la que más está transformando el trabajo diario, es el desplazamiento desde la auditoría puntual (una o dos veces al año) hacia modelos de validación continua. Plataformas de pentesting como servicio automatizan reconocimiento y explotación de vulnerabilidades conocidas, mientras el trabajo humano se concentra en lógica de negocio, encadenamiento de fallos y escenarios que ningún escáner cubre.
Esto no significa que el pentesting tradicional haya muerto. En entornos regulados (PCI DSS, ENS, DORA en el ámbito financiero europeo), las pruebas con alcance cerrado y fecha siguen siendo requisito. Pero cada vez más organizaciones combinan ambas capas: escaneo continuo para lo conocido y ejercicios manuales periódicos para lo que requiere criterio humano.
Lo que la automatización no resuelve
Un ejemplo concreto que ilustra la limitación: una aplicación con autenticación multifactor correctamente implementada, WAF activo y sin vulnerabilidades críticas según el escáner puede seguir siendo comprometible mediante un flujo de recuperación de contraseña mal diseñado que filtra información por diferencias de tiempo de respuesta. Ningún escáner comercial detecta eso de forma fiable. Requiere que alguien se siente a leer el código del flujo o a cronometrar respuestas con un script propio.
IA ofensiva: expectativas frente a realidad operativa
Los modelos de lenguaje se han incorporado al pentesting en tareas concretas: generación de payloads, análisis de código fuente para detectar patrones inseguros, redacción de informes y triaje de falsos positivos. Según documentación de proveedores del sector, el ahorro de tiempo en tareas repetitivas es real, pero acotado.
Donde la IA falla más de lo que se admite públicamente es en la explotación de cadenas complejas. Un modelo puede sugerir un vector plausible, pero rara vez entiende el contexto de red, las restricciones de un entorno concreto o el estado de un servicio que se reinició a mitad del ejercicio. El pentester sigue siendo quien valida, adapta y descarta.
Un error habitual con herramientas asistidas por IA
Un fallo frecuente que veo en equipos que empiezan a usar asistentes de IA para reconocimiento: aceptar resultados sin verificar el estado real del objetivo. Los modelos alucinan versiones de servicios y CVEs asociados. Si el informe se redacta a partir de esas salidas sin contrastar con la evidencia del escaneo, se entregan hallazgos inexistentes y se pierde credibilidad ante el cliente técnico. La regla práctica: la IA propone, la herramienta verifica, la persona decide.
Superficie de ataque en la nube y en APIs
Las pruebas de penetración de infraestructura clásica han perdido peso relativo frente a dos frentes: configuraciones de cloud (IAM mal definido, buckets expuestos, roles con privilegios excesivos) y APIs, que en muchas organizaciones superan en número a las aplicaciones web tradicionales. El OWASP API Security Top 10 se ha consolidado como referencia, pero la brecha práctica está en los objetos y propiedades a nivel de objeto (BOLA/BOPLA), donde la autorización se implementa mal con frecuencia.
Un matiz importante: auditar una API sin documentación actualizada ni acceso al equipo de desarrollo consume buena parte del presupuesto en reconstruir el contrato. Cuando el cliente no puede aportar especificación OpenAPI fiable, conviene renegociar el alcance antes de empezar, no después.
Red teaming y simulación de adversarios: cuándo tiene sentido
Los ejercicios de red team (simulación de un atacante con objetivos y TTPs definidos) se han popularizado, pero no son adecuados para todas las organizaciones. Requieren madurez previa: si la higiene básica de parcheo y segmentación no existe, un red team solo confirma lo que un pentesting estándar habría detectado por una fracción del coste.
La decisión práctica suele ser: pentesting para identificar y corregir; red team cuando ya hay controles y se quiere medir la capacidad real de detección y respuesta (SOC, EDR, procedimientos). Mezclar ambos objetivos en un mismo encargo produce informes confusos y expectativas mal gestionadas.
Regulación y presión de cumplimiento
Marcos como NIS2 en la Unión Europea y requisitos sectoriales están empujando a más empresas a contratar pruebas de penetración con periodicidad definida. Esto tiene un efecto secundario: presión sobre el mercado de proveedores, con más actores ofreciendo servicios y calidad muy desigual. Verificar metodología (PTES, OWASP, OSSTMM), alcance por escrito y quién ejecuta realmente las pruebas es más necesario que nunca.
Qué esperar y qué no
Ninguna prueba de penetración garantiza que un sistema sea seguro. Detecta lo que se buscó, con el alcance y el tiempo acordados. Un informe limpio no equivale a ausencia de vulnerabilidades; significa que en ese periodo, con esos recursos, no se encontraron explotables dentro del alcance. Reconocer esa limitación —y dejarla por escrito en el propio informe— es parte del trabajo bien hecho, no una cláusula de descargo.
Perfiles verificables: Sitio web
Publicado el 27 de October de 2026. Última revisión: 27 de October de 2026.
