Un análisis de vulnerabilidades busca y prioriza la mayor cantidad posible de debilidades. Un pentest busca demostrar qué puede hacer realmente un atacante con algunas de ellas. Uno es amplitud, el otro es profundidad. Casi toda la confusión entre análisis de vulnerabilidades vs pentest viene de proveedores que usan las dos palabras como sinónimos, y de equipos que compran una cosa cuando necesitaban la otra.
En esta guía explicamos los dos, los comparamos lado a lado (objetivo, profundidad, explotación, frecuencia, automatización, costo y entregable), vemos cuándo conviene cada uno y dónde entra la evaluación continua a nivel de código.
Qué es un análisis de vulnerabilidades
Un análisis de vulnerabilidades (en inglés, vulnerability assessment) es un proceso sistemático para identificar, validar, priorizar y reportar debilidades de seguridad. Es mayormente automatizado y está pensado para repetirse. Un ciclo típico se ve así:
- Alcance e inventario: qué hosts, aplicaciones, repositorios, cuentas cloud y dependencias entran en juego.
- Descubrimiento: scanners y analizadores buscan problemas conocidos: parches faltantes, versiones de librerías vulnerables, configuraciones inseguras, patrones de código riesgosos, secretos expuestos.
- Validación: sacar falsos positivos y duplicados.
- Priorización: ordenar por severidad (CVSS), probabilidad de explotación (señales como el EPSS de FIRST o el catálogo Known Exploited Vulnerabilities de CISA) y contexto de negocio: ¿está expuesto a internet?, ¿toca datos de clientes?
- Reporte y remediación: responsables, fixes, plazos, y un re-escaneo para confirmar.
Hay distintos tipos según el objetivo: análisis de red y hosts, de aplicaciones web, revisiones de configuración cloud y evaluaciones a nivel de código que analizan el código fuente, las dependencias y la infraestructura como código. Una auditoría de seguridad de código es, en esencia, un análisis de vulnerabilidades profundo a nivel de código.
Qué es un pentest
Un pentest (penetration test o prueba de penetración) es un ataque simulado y autorizado. Los testers trabajan dentro de un alcance y unas reglas de enfoque definidas, y no se quedan en "esto parece vulnerable": intentan explotarlo, encadenarlo con otras debilidades y demostrar el impacto. Suele seguir fases como reconocimiento, mapeo, explotación, post-explotación y reporte, y puede ser de caja negra (sin información), caja gris (con algunas credenciales o documentación) o caja blanca (con acceso al código). Para el panorama completo, leé qué es el pentesting.
El valor de un pentest es el criterio. Un tester humano nota que un token de reseteo de contraseña es predecible, que una fuga de información de severidad baja expone IDs internos, y que esos IDs más un chequeo de autorización faltante permiten leer las facturas de todos los clientes. Ningún hallazgo por separado era crítico; la cadena sí.
Análisis de vulnerabilidades vs pentest: tabla comparativa
| Dimensión | Análisis de vulnerabilidades | Pentest |
|---|---|---|
| Objetivo | Encontrar y priorizar la mayor cantidad posible de debilidades | Demostrar el impacto real explotando debilidades |
| Profundidad | Amplio y superficial: muchos activos, muchos chequeos | Acotado y profundo: objetivos seleccionados, caminos de ataque creativos |
| Explotación | Normalmente ninguna, o verificación segura limitada | Sí, bajo reglas de enfoque, incluyendo encadenamiento |
| Frecuencia | Continua, por cambio, semanal o mensual | Típicamente anual, por release grande o tras cambios significativos |
| Automatización | Mayormente automatizado, con triage humano | Mayormente manual, asistido por herramientas |
| Costo | Menor por corrida; escala con activos y frecuencia | Mayor por proyecto; depende de horas de tester y alcance |
| Entregable | Lista priorizada de hallazgos con guía de remediación | Informe narrativo con caminos de ataque, evidencia e impacto de negocio |
| Punto débil | Se pierde fallas de lógica y cadenas; puede ser ruidoso | Foto de un momento; limitado por alcance y horas |
La misma aplicación, dos informes distintos
Imaginá una API SaaS con tres problemas: una dependencia con un CVE conocido, mensajes de error verbosos que filtran IDs internos de usuarios, y un endpoint que carga un registro por ID sin verificar de quién es.
- El análisis de vulnerabilidades reporta el CVE como alto, los errores verbosos como bajo y, si la herramienta razona sobre autorización, el chequeo de ownership faltante como alto. Cada hallazgo va por separado, con su fix.
- El pentest quizás ignora el CVE si no es alcanzable, pero usa los IDs filtrados para enumerar cuentas y el chequeo faltante para bajarse datos de otros tenants. El informe dice: "Un usuario autenticado puede leer los registros de cualquier cliente". Esa frase es la que consigue presupuesto y atención.
Los dos informes son correctos. Responden preguntas distintas.
Cuándo usar cada uno
Usá un análisis de vulnerabilidades cuando
- Deployás código todos los días y necesitás detectar debilidades nuevas apenas aparecen.
- Nunca miraste la seguridad de forma sistemática y necesitás una línea de base.
- Querés limpiar los problemas conocidos antes de pagar un pentest.
- Necesitás evidencia continua de gestión de vulnerabilidades. ISO/IEC 27001:2022, por ejemplo, incluye en su Anexo A un control de gestión de vulnerabilidades técnicas.
Usá un pentest cuando
- Estás por lanzar un producto o feature grande que maneja datos sensibles.
- Un cliente, un inversor o un regulador te pide un informe de pentest independiente.
- Hiciste cambios de arquitectura significativos: autenticación nueva, nuevo modelo multi-tenant, API pública nueva.
- Lo exige el compliance. PCI DSS v4.0, por ejemplo, pide escaneos externos de vulnerabilidades por un Approved Scanning Vendor al menos cada tres meses (requisito 11.3.2) y pentests internos y externos al menos cada 12 meses y después de cambios significativos (requisito 11.4).
Si estás evaluando proveedores, nuestra guía de herramientas de pentesting explica qué puede reemplazar la automatización y qué no.
Qué preguntar antes de contratar cualquiera de los dos
Ya sea que contrates un análisis de vulnerabilidades, un pentest o los dos, estas preguntas separan el trabajo útil del ruido caro:
- ¿Qué entra exactamente en el alcance? Dominios, APIs, apps mobile, cuentas cloud, código fuente. Lo que no esté en la lista no se va a probar.
- ¿Cuánto es manual? En un pentest, pedí la cantidad de días de tester y quiénes son. En un análisis, preguntá cómo se validan los hallazgos antes de llegarte.
- ¿Autenticado o no? La mayoría de los bugs serios de un SaaS están detrás del login. Probar solo la superficie pública los deja afuera.
- ¿Cómo se priorizan los hallazgos? La etiqueta de severidad sola no alcanza. Querés explotabilidad y contexto de negocio.
- ¿Cómo se ve un hallazgo? Pedí un informe de ejemplo. Un buen hallazgo trae evidencia, pasos para reproducirlo y un fix concreto.
- ¿Incluye re-test? Confirmar que los fixes funcionan es parte del trabajo, no un extra.
Errores comunes
- Comprar un escaneo con etiqueta de pentest. Si el entregable es un export del scanner sin editar y sin evidencia de explotación, es un análisis de vulnerabilidades. Preguntá cuántas horas de testing manual incluye.
- Hacer un pentest sobre un código lleno de problemas conocidos. Los testers van a gastar tu presupuesto reportando librerías viejas y headers faltantes en vez de encontrar fallas de lógica.
- Tratar el pentest como si fuera el programa de seguridad. Un pentest es una foto. Dos semanas después sale código nuevo y el informe ya está envejeciendo.
- No priorizar. Un análisis de vulnerabilidades con 900 hallazgos sin ordenar genera parálisis, no remediación.
Dónde entra la evaluación continua a nivel de código
En una empresa de software, la mayor parte del riesgo nuevo entra por cambios de código: un endpoint nuevo, un upgrade de dependencia, un cambio en un workflow de CI. Un pentest anual no puede seguir ese ritmo. La respuesta práctica es hacer análisis de vulnerabilidades a nivel de código en cada cambio y reservar los pentests para lo que las personas hacen mejor.
La evaluación a nivel de código combina varias técnicas estáticas:
- SAST sobre tu propio código, idealmente AI SAST que razone sobre autorización y flujo de datos, no solo sobre patrones fijos. En SAST vs DAST vemos cómo se complementa con el testing en runtime.
- Software composition analysis para CVEs conocidos en dependencias, que explicamos en SAST vs SCA.
- Detección de secretos en todo el historial de git.
- Chequeos de infraestructura como código y CI para GitHub Actions, Dockerfiles, Terraform y Kubernetes.
Ahí encaja Nurbak. Conectás GitHub y escaneás un repositorio; su propio modelo de IA self-hosted analiza el código (el análisis no manda tu código a OpenAI ni a Anthropic) y reporta vulnerabilidades explotables con archivo y línea, CVEs de dependencias vía OSV con versiones corregidas, configuraciones inseguras de GitHub Actions, Docker, Terraform y Kubernetes y secretos en el historial de git, todo resumido en un score de 0 a 100 con explicaciones en lenguaje simple. Para ser claros con el alcance: Nurbak analiza código y configuración. No hace DAST, ni escaneo de red, ni explotación en vivo contra tus sistemas, así que complementa un pentest en vez de reemplazarlo. Podés arrancar con una evaluación continua de tu código; el escaneo gratis muestra completos los 3 hallazgos más importantes.
Un programa práctico para una empresa de software
- En cada pull request: evaluación a nivel de código (SAST, SCA, secretos, IaC), con los hallazgos explotables resueltos antes del merge.
- Semanal o mensual: re-escaneo completo del repo y revisión del backlog pendiente; escaneos externos de los activos expuestos a internet.
- Una vez por año y después de cambios grandes: un pentest manual enfocado en lógica de negocio, autenticación, multi-tenancy y cadenas de ataque.
- Después de cada pentest: convertir cada hallazgo en un test de regresión y, cuando se pueda, en un chequeo que corra en cada cambio, para que la misma clase de bug no vuelva.
Para una mirada más amplia de prioridades más allá del testing, mirá nuestra guía de ciberseguridad para empresas de software.
Conclusión
Análisis de vulnerabilidades vs pentest no es una competencia. El análisis te da cobertura y continuidad; el pentest te da profundidad y prueba. Corré análisis de forma continua, sobre todo a nivel de código, donde tu riesgo cambia todos los días, y sumá pentesters cuando necesites una mirada independiente y adversarial. Si querés tener andando hoy la parte continua, empezá con una evaluación automatizada de tu repositorio.