Pruebas de seguridad
Pentesting frente al análisis continuo de vulnerabilidades: cómo se complementan
Un pentest (prueba de penetración) es un ejercicio de duración limitada en el que probadores expertos intentan entrar en un sistema como lo haría un atacante. El análisis continuo de vulnerabilidades comprueba el software de forma automática y repetida en busca de debilidades conocidas. Responden a preguntas distintas, así que la mayoría de los programas de seguridad necesitan ambos.
Plan gratuito, sin tarjeta.
¿Qué es un pentest?
El NIST describe las pruebas de penetración como pruebas de seguridad en las que los evaluadores imitan ataques reales para encontrar formas de eludir las funciones de seguridad de una aplicación, un sistema o una red. Los probadores encadenan pequeñas debilidades, sondean la lógica de negocio y valoran qué podría conseguir realmente un atacante.
Un pentest tiene un alcance definido y una autorización por escrito, dura un período fijo y termina con un informe de hallazgos, su impacto y las correcciones recomendadas. Su resultado es una instantánea: describe el sistema tal como estaba durante la prueba.
¿Qué es el análisis continuo de vulnerabilidades?
El NIST define el análisis de vulnerabilidades como una técnica para identificar hosts, sus atributos y las vulnerabilidades asociadas. El análisis de composición de software aplica la misma idea al código: enumera los componentes de código abierto que contiene un producto y los contrasta con avisos públicos como los registros CVE.
El análisis es continuo cuando se ejecuta en cada cambio y el inventario se vuelve a comprobar a medida que se publican nuevos avisos. Un componente que estaba limpio en el lanzamiento puede volverse vulnerable meses después sin que cambie ni una sola línea de su código.
Pentest frente a análisis de vulnerabilidades de un vistazo
Los dos métodos difieren en quién hace el trabajo, qué encuentran y cuánto tiempo sigue siendo cierto el resultado.
| Pregunta | Prueba de penetración | Análisis continuo |
|---|---|---|
| Quién lo hace | Personas expertas, a menudo una empresa externa | Herramientas automatizadas |
| Qué encuentra | Cadenas explotables, fallos de lógica y configuraciones incorrectas, con su impacto real | Vulnerabilidades conocidas en componentes, secretos expuestos y errores de configuración comunes |
| Con qué frecuencia | A menudo una vez al año y tras cambios importantes | En cada cambio y de forma repetida entre versiones |
| Profundidad | Profunda, en un alcance definido | Amplia, en todos los productos y versiones |
| Resultado | Un informe en un momento dado | Una lista actualizada de hallazgos y su estado |
| Límites | No ve lo que cambia después de la prueba; es costosa de repetir | No demuestra la explotabilidad ni encuentra nuevos fallos de lógica |
Por qué se necesitan ambos
Cada uno cubre los puntos ciegos del otro. Un pentest encuentra lo que ningún escáner puede: una comprobación de autorización rota, un flujo de trabajo que se puede abusar, una cadena de problemas menores que suman una brecha. El análisis encuentra lo que un pentest no puede seguir: el aviso publicado la semana después de que se fueran los probadores, la dependencia añadida en el siguiente sprint, la versión de firmware entregada a un cliente nuevo.
Las normas reflejan esta división. La NIST SP 800-53 enumera las pruebas de penetración (CA-8) y la monitorización y el análisis de vulnerabilidades (RA-5) como controles distintos. La OWASP Web Security Testing Guide defiende un enfoque equilibrado: los escáneres tienen su lugar en un programa de pruebas, pero no pueden sustituir las pruebas manuales, y las pruebas de penetración no deberían ser la única técnica.
Analizar de forma continua también hace más rentable un pentest. Cuando las vulnerabilidades conocidas ya están corregidas, los probadores dedican su tiempo a los problemas que solo las personas pueden encontrar.
Cómo combinarlos
Un ritmo sencillo funciona para la mayoría de los equipos de producto:
- Analiza de forma continua desde el principio: cada repositorio, imagen de contenedor y versión de firmware, con una nueva comprobación a medida que aparecen avisos.
- Corrige o documenta las vulnerabilidades conocidas antes de un pentest, para que el informe se centre en lo que los escáneres no ven.
- Encarga un pentest antes de las versiones principales, tras cambios de arquitectura importantes y con la frecuencia que esperen clientes, aseguradoras o reguladores.
- Entrega a los probadores tu SBOM y la lista actual de hallazgos abiertos, para que puedan centrarse en los componentes de mayor riesgo.
- Incorpora los hallazgos del pentest al mismo seguimiento que los del análisis y vuelve a analizar tras cada corrección.
Disponible hoy en KROMSE
KROMSE no es una prueba de penetración ni sustituye a una. Cubre la parte del análisis continuo: el análisis de URL comprueba lo que cualquiera puede ver desde internet, y KROMSE revisa el código, las dependencias, las imágenes de contenedor y el firmware que hay detrás de un producto.
- Comprobación de dependencias con OSV.dev para lockfiles y manifiestos, incluidos npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler y .NET.
- Detección de secretos en el commit analizado; los valores de los secretos se enmascaran y nunca se almacenan.
- Imágenes de firmware basadas en Linux desempaquetadas de forma recursiva, con los paquetes contrastados con OSV.dev y el sistema de archivos raíz revisado en busca de errores de configuración y secretos incrustados.
- En los planes de pago, el último SBOM de cada fuente se vuelve a contrastar con OSV.dev cada 6 horas, y las nuevas coincidencias aparecen como avisos en la aplicación.
- Contexto de CISA KEV, FIRST EPSS, NVD y la EUVD de ENISA en los hallazgos, con las vulnerabilidades de explotación conocida señaladas.
Preguntas frecuentes
¿Es lo mismo un análisis de vulnerabilidades que un pentest?
No. Un análisis es automatizado y busca debilidades conocidas. Un pentest lo dirigen personas que intentan explotar debilidades, incluidas algunas que ningún escáner conoce, y valoran su impacto. Los probadores suelen usar escáneres durante el trabajo, pero un informe de análisis no es un informe de pentest.
¿Con qué frecuencia debe hacerse un pentest?
No hay un único intervalo. La NIST SP 800-53 deja la frecuencia a criterio de la organización, y muchas organizaciones hacen pruebas una vez al año y tras cambios importantes. Los clientes, las aseguradoras y las normas sectoriales suelen fijar un mínimo.
¿Puede el análisis continuo sustituir a un pentest?
No. El análisis no puede probar la lógica de negocio, encadenar debilidades ni mostrar lo que un atacante podría conseguir de verdad. Reduce el número de problemas conocidos a los que un pentest tiene que dedicar tiempo y sigue vigilando cuando la prueba ha terminado.
¿Necesito permiso para hacer un pentest a un sistema?
Sí. Probar un sistema sin la autorización por escrito de su propietario puede constituir delito; en la UE, la Directiva 2013/40/UE obliga a los Estados miembros a sancionar el acceso ilegal a los sistemas de información. Un pentest siempre empieza con un alcance acordado y unas reglas de actuación por escrito.
¿Hace KROMSE pruebas de penetración?
No. KROMSE no realiza pruebas de penetración ni pruebas dinámicas completas de aplicaciones (DAST). Revisa el código, las dependencias, las imágenes de contenedor y el firmware basado en Linux en busca de vulnerabilidades conocidas, secretos y errores de configuración, lo que complementa un pentest realizado por probadores cualificados.
Guías relacionadas
Fuentes
- Glosario del NIST: penetration testing
- NIST SP 800-115: guía técnica de pruebas y evaluación de la seguridad de la información
- NIST SP 800-53 Rev. 5: controles de seguridad y privacidad (CA-8, RA-5)
- OWASP Web Security Testing Guide
- Directiva 2013/40/UE sobre los ataques contra los sistemas de información, EUR-Lex