El informe del pentest anual llega en marzo, se corrige lo urgente en abril y en mayo el equipo publica tres versiones nuevas. En junio, ese informe describe un sistema que ya no existe. El trabajo estaba bien hecho; retrataba un momento concreto y el software siguió cambiando después. Ahí está la diferencia entre un pentest continuo y uno anual, y tiene menos que ver con la profundidad de las pruebas que con cada cuánto se hacen.
Por qué caduca un pentest anual
Unas pruebas de penetración son una fotografía. Reflejan el estado del sistema durante los días en que se ejecutaron, con el código que había desplegado y la configuración de ese momento. Todo lo que se toca después queda fuera del informe, y en un producto vivo se toca mucho:
- Cada despliegue introduce código que nadie ha probado desde el punto de vista de un atacante.
- Una dependencia nueva arrastra su propia superficie de ataque y sus vulnerabilidades conocidas.
- Un cambio de configuración en el proveedor cloud puede exponer un servicio que estaba cerrado.
- Una funcionalidad añadida deprisa antes de una demo se queda en producción sin revisión.
- Un endpoint creado para una integración concreta sobrevive a la integración que lo justificaba.
Si publicas una vez al año, un pentest anual encaja perfectamente. Si publicas cada dos semanas, el informe describe una versión que ya nadie ejecuta antes de que termines de leerlo.
El coste real no es el precio del informe
El gasto que más duele en el modelo anual aparece fuera de la factura del pentest: está en lo que cuesta arreglar lo que ese pentest encuentra. Un fallo de diseño detectado once meses después de escribirse se ha extendido: hay código construido encima, integraciones que dependen de ese comportamiento y clientes usándolo. Corregirlo deja de ser una tarea y se convierte en un proyecto.
El mismo fallo detectado la semana en que se escribió lo arregla la persona que lo escribió, que todavía recuerda por qué lo hizo así, y en un rato. Esa es la economía del pentesting frecuente: mueve el trabajo de corrección al momento en que es más barato.
Hay además un coste organizativo. Un informe anual con doscientos hallazgos llega de golpe y compite con la hoja de ruta del producto, así que se atiende lo crítico y el resto se aparca. Un flujo constante de pocos hallazgos entra en el sprint como cualquier otra tarea.
Qué cambia cuando se prueba cada despliegue
El pentest continuo mantiene la superficie expuesta bajo prueba de forma permanente, con revisión manual dirigida cuando hay cambios relevantes. En la práctica cambian tres cosas.
El alcance sigue al producto
Un subdominio nuevo, una API que se publica, un panel de administración que se separa del portal principal: todo eso entra en el alcance cuando aparece, sin esperar a la próxima contratación ni renegociar el ámbito de trabajo.
La corrección se verifica de verdad
En el modelo anual, lo habitual es que la corrección se dé por buena hasta el año siguiente. Con pruebas continuas, cada arreglo se vuelve a probar poco después de desplegarse, y ahí se descubre lo que suele fallar: parches parciales, validaciones que solo cubren el caso del informe, correcciones aplicadas en un entorno y no en producción.
El equipo aprende sobre su propio código
Recibir hallazgos sobre lo que acabas de escribir enseña más que un informe anual sobre trabajo de hace meses. Al cabo de unos ciclos, patrones enteros dejan de repetirse porque el equipo ya los reconoce mientras programa.
Lo que sigue teniendo sentido hacer una vez al año
La cadencia continua no sustituye a todo. Hay ejercicios que ganan al concentrarse:
- Una revisión profunda de arquitectura y modelo de amenazas cuando el producto cambia de forma.
- Un ejercicio de simulación de ciberataques tipo red team, que mide la detección y la respuesta además de la existencia de un fallo.
- Un informe formal para un cliente, un tender o una certificación que exige una fecha y un alcance cerrados.
- Una auditoría de seguridad informática amplia que cubra también organización, accesos y procesos, más allá del software.
La combinación razonable en una pyme que publica software es continua para el día a día y un ejercicio anual profundo para lo que necesita perspectiva o firma.
Cómo saber cuál te toca
Cuatro preguntas resuelven la decisión sin teoría:
- ¿Cada cuánto despliegas a producción? Si la respuesta se mide en semanas o menos, el modelo anual te deja meses de código sin probar.
- ¿Tu producto maneja datos de clientes o dinero? Cuanto más sensible es lo que hay detrás, menos tolerable es la ventana entre pruebas.
- ¿Cuánto tardas hoy en corregir un hallazgo grave? Si son meses, el problema es el proceso y no la frecuencia, y conviene arreglarlo antes.
- ¿Alguien te pide evidencia? Los cuestionarios de seguridad de clientes grandes ya no se conforman con saber si haces pentesting; preguntan con qué frecuencia y cómo verificas las correcciones.
Esa última pregunta decide más contratos de lo que parece. Responder «una vez al año, en marzo» y responder «en cada despliegue, con verificación de la corrección» abren conversaciones muy distintas con el departamento de compras de un cliente grande.
Qué hace falta para empezar
Un modelo continuo exige menos de lo que la gente supone, aunque sí exige tres cosas del lado del cliente. Un inventario actualizado de dominios, aplicaciones y APIs, porque no se prueba lo que no está en la lista. Un entorno donde probar sin frenar el negocio, normalmente preproducción con datos realistas. Y un canal de comunicación directo con quien programa, para que un hallazgo llegue al ticket sin pasar por tres intermediarios.
Con eso montado, unas pruebas de seguridad continuas convierten la seguridad del producto en parte del ciclo de desarrollo, con el mismo ritmo que el resto del trabajo. El objetivo es sencillo: que ningún despliegue llegue a producción sin que alguien lo haya mirado con la cabeza de quien intenta romperlo.
¿Quieres saber cuán expuesto está tu sitio?
El Security Assessment de Ciphraverse verifica sitios, portales y e-commerce con una auditoría externa profesional pensada para pymes.