Pentesting continuo

Por qué el pentesting puntual ya no basta: el ritmo de los despliegues continuos

Las empresas de hoy desarrollan y despliegan software a un ritmo que hace pocos años era impensable. Metodologías ágiles, integración y despliegue continuos y equipos de desarrollo distribuidos hacen que una misma aplicación cambie decenas de veces al año. Cada cambio —una funcionalidad nueva, una actualización de librería, una migración de servidor— modifica la superficie de ataque, y lo que era seguro en enero puede dejar de serlo en marzo.

La nube y la infraestructura como código han acelerado este fenómeno: recursos que antes tomaban semanas de aprovisionamiento hoy se crean y destruyen en minutos mediante scripts. Esa agilidad es una ventaja de negocio, pero también significa que la configuración de seguridad vive y muere con cada plantilla, y un error de configuración puede replicarse automáticamente en todo un entorno.

A este escenario se suma la dependencia creciente de APIs, microservicios y componentes de terceros. Las aplicaciones modernas son ecosistemas: se conectan con proveedores de pago, servicios de identidad, plataformas de análisis y bibliotecas de código abierto. La seguridad de la aplicación final es tan sólida como la de cada una de esas piezas y de las integraciones que las unen.

El pentesting puntual, realizado una vez al año o solo antes de un lanzamiento importante, captura una fotografía: válida en el momento, desactualizada al siguiente cambio. El pentesting continuo responde a esta realidad con un modelo de evaluación acorde al ciclo de vida del software, donde las pruebas se repiten de forma sistemática y se alinean con la velocidad de los despliegues.

Lo que dicen los datos: la ventana de exposición no se cierra sola

Hay cifras que conviene mirar de frente antes de decidir cada cuánto evaluar la seguridad de una empresa:

• Según la telemetría regional de ESET para el primer semestre de 2026, más del 81% de los intentos de explotación en América Latina apuntó a dos fallas de Microsoft Office de 2017 (CVE-2017-0199 y CVE-2017-11882). El parche existe desde hace años; lo que falta es aplicarlo y verificarlo (Techtocio / ESET Latinoamérica).
• El Data Breach Investigations Report 2025 de Verizon confirma que cerca del 60% de las brechas involucra el factor humano y que la participación de terceros en los incidentes se duplicó hasta el 30% (Revista Estrategia & Negocios). La superficie que hay que evaluar ya no termina en el perímetro propio.
• El Informe Global de Brecha de Habilidades de Fortinet 2025 encontró que el 86% de las organizaciones de América Latina y el Caribe sufrió al menos una intrusión cibernética en 2024 (ITSitio). Con ese nivel de presión, un informe anual nace desactualizado.

La lectura es clara: las vulnerabilidades no esperan al próximo ciclo de auditoría, y los atacantes tampoco. Un programa continuo acorta la ventana entre el momento en que aparece una debilidad y el momento en que alguien la encuentra y la corrige.

Errores típicos que vemos cuando el pentesting es un evento anual

En nuestra experiencia evaluando empresas de distintos sectores, estos son los patrones que más se repiten cuando el pentesting se contrata una vez al año y se archiva:

• Alcance congelado: se evalúa la aplicación de enero, no la de noviembre. Todo lo que se desplegó después —nuevos módulos, integraciones, APIs— nunca pasó por manos de un atacante controlado.
• Hallazgos que caducan antes de corregirse: el informe final llega cuando el código ya cambió varias veces. Corregir sobre una versión vieja es trabajar a ciegas.
• Re-tests que nunca ocurren: nadie verifica con evidencia que la corrección funcionó. Es frecuente encontrar hallazgos marcados como «corregidos» que siguen siendo explotables cuando se vuelven a probar.
• Informes que nadie acciona: listados técnicos sin traducción a riesgo de negocio. La dirección no sabe qué corregir primero y el equipo técnico no tiene criterios de priorización.
• Pruebas desconectadas del desarrollo: seguridad evalúa tarde, desarrollo lo percibe como un freno y el resultado es fricción en lugar de mejora continua.

Cada uno de estos errores tiene el mismo origen: tratar la seguridad como un hito del calendario en lugar de un proceso pegado a la operación.

Cómo debe funcionar un programa de pentesting continuo

Un programa serio de pentesting continuo combina ciclos planificados con disparadores por evento. Los ciclos —trimestrales o semestrales según la criticidad— mantienen una línea base; los disparadores —cada release mayor, un cambio de infraestructura, la incorporación de un proveedor crítico, un incidente de seguridad— contribuyen a que lo nuevo se evalúe cuando nace, no meses después.

Qué debe incluir el alcance mínimo

Si va a evaluar una propuesta de pentesting continuo, verifique que el alcance cubra como mínimo:

• aplicaciones web y móviles críticas para el negocio, con sus APIs expuestas.
• Infraestructura en la nube y plantillas de infraestructura como código.
• Red externa e interna, incluidos accesos remotos y VPN.
• Ingeniería social y phishing controlado, porque el factor humano es parte de la superficie.
• Re-test con evidencia de cada hallazgo corregido, no una simple declaración del proveedor.

Métricas que importan

Un programa continuo se gobierna con números, no con sensaciones: tiempo medio de remediación por severidad, porcentaje de hallazgos críticos que se reabren en el re-test y ventana de exposición por activo (días entre la aparición de una debilidad y su corrección verificada). Si su proveedor no le entrega estas métricas, no tiene un programa continuo: tiene pentests sueltos con otro nombre.

Integración con el ciclo de desarrollo

El programa debe vivir dentro del flujo del equipo —resultados accionables, priorizados por riesgo de negocio y entregados a tiempo para el siguiente sprint— sin convertirse en un peaje que frene los despliegues. La seguridad que retrasa el negocio termina siendo evadida por el negocio.

Cómo trabaja DragonJAR el pentesting continuo

DragonJAR nació como comunidad de seguridad informática en 2001 y opera como empresa desde 2012; cada año organiza la DragonJAR Security Conference. Esa trayectoria se refleja en la forma de ejecutar un programa continuo: pruebas de penetración autorizadas, realizadas por un equipo ético y transparente, con informes redactados para aportar valor al negocio y comprensibles para todas las áreas, no solo para el equipo técnico.

Cada ciclo del programa incluye re-tests para verificar con evidencia que las correcciones recomendadas fueron aplicadas de manera efectiva, cerrando el ciclo de mejora en lugar de dejarlo abierto hasta el año siguiente. Los reportes se entregan con hallazgos validados manualmente, priorizados por impacto real, para que la dirección sepa qué corregir primero y por qué.

Puede conocer el punto de partida del programa en nuestro servicio de pentesting, del que somos referentes en seguridad informática de habla hispana, y revisar el detalle de los servicios de seguridad informática de DragonJAR.