≡En resumen
- Un escáner compara lo que encuentra con bases de datos de fallos conocidos y con patrones de ataque.
- DAST prueba la web en marcha desde fuera; SAST lee el código; SCA revisa las librerías que usas.
- Escanear no es auditar: detecta rápido lo conocido, pero no los fallos de lógica ni todo el riesgo.
- Solo se escanea lo que es tuyo o lo que tienes permiso por escrito para probar.
- Un informe sirve de algo cuando cada hallazgo se prioriza, se corrige y se vuelve a escanear.
01 ¿Qué es el vulnerability scanning?
La diferencia con una auditoría o un test de intrusión es la profundidad. El escáner es rápido, barato y repetible, pero solo encuentra lo que sabe buscar. Un pentester humano encadena fallos, entiende la lógica del negocio y prueba lo que ninguna firma describe. Lo razonable es escanear a menudo y auditar a fondo de vez en cuando.
02 Tipos de escaneo: SAST, DAST, SCA y de infraestructura
| Tipo | Qué analiza | Qué encuentra bien | Qué se le escapa |
|---|---|---|---|
| DAST (dinámico) | La aplicación en ejecución, desde fuera, como un atacante | XSS, inyecciones, cabeceras y cookies inseguras, errores expuestos | Código que no recorre; fallos de permisos y de lógica |
| SAST (estático) | El código fuente, sin ejecutarlo | Patrones peligrosos: consultas SQL concatenadas, secretos en el código | Problemas de configuración y de despliegue; da falsos positivos |
| SCA (dependencias) | Librerías y paquetes de terceros (npm, Composer, plugins) | Componentes con CVE conocidos y licencias problemáticas | Fallos en tu propio código |
| Red e infraestructura | Servidores, puertos, servicios y sistemas operativos | Servicios expuestos, versiones antiguas, TLS débil | Lo que ocurre dentro de la aplicación web |
| Específico de CMS | WordPress, Drupal, Joomla y sus extensiones | Plugins y temas vulnerables, usuarios enumerables | Código a medida fuera del CMS |
03 Herramientas de escaneo de vulnerabilidades
| Herramienta | Tipo | Licencia o precio | Para qué se usa |
|---|---|---|---|
| ZAP (Zed Attack Proxy) | DAST | Código abierto y gratuita; hoy respaldada por Checkmarx | Escanear aplicaciones web y APIs, también en integración continua |
| WPScan | Escáner de WordPress | CLI gratuita; API con 25 peticiones al día gratis para uso no comercial | Detectar versiones vulnerables de núcleo, plugins y temas |
| Nmap | Red | Código abierto | Descubrir puertos y servicios expuestos |
| Greenbone OpenVAS | Infraestructura | Código abierto con versión comercial | Escaneos de red completos con miles de pruebas |
| Nessus | Infraestructura | Comercial, con versión Essentials limitada | Escaneo de servidores y redes en empresas |
| Escáneres de dependencias (npm audit, composer audit) | SCA | Incluidos en los gestores de paquetes | Avisar de librerías con fallos conocidos al instalar o compilar |
04 Cómo hacer un escaneo de vulnerabilidades paso a paso
-
1
Define el alcance y el permiso
Dominios, subdominios, IP, API y entornos (mejor en preproducción idéntica a producción). Déjalo por escrito.
-
2
Haz el inventario
CMS, plugins, librerías y servicios con su versión. Muchos hallazgos salen solo de cruzar esta lista con las bases de datos de CVE.
-
3
Elige las herramientas
DAST para la web, SCA para las dependencias, escaneo de red para el servidor y un escáner específico si usas un CMS.
-
4
Ejecuta con cuidado
Programa los escaneos activos fuera de horas punta, limita la velocidad y ten una copia de seguridad reciente por si algo falla.
-
5
Revisa y descarta falsos positivos
Comprueba a mano los hallazgos críticos antes de movilizar al equipo; los escáneres exageran a menudo.
-
6
Prioriza y corrige
Primero lo crítico y expuesto a Internet con exploit conocido; después el resto por gravedad.
-
7
Vuelve a escanear
Confirma que cada fallo está corregido y guarda el informe como evidencia.
Revisa también la capa de cifrado: certificados caducados, protocolos antiguos o una configuración de HTTPS incompleta son hallazgos habituales en los escaneos de infraestructura.
05 Cada cuánto escanear y qué exige la normativa
| Proyecto | Frecuencia recomendada |
|---|---|
| Web corporativa en WordPress | Monitorización diaria de plugins vulnerables y escaneo completo mensual |
| Tienda online con pagos | Escaneo externo al menos trimestral (PCI DSS) y tras cada cambio importante |
| Aplicación o SaaS propio | SAST y SCA en cada despliegue; DAST semanal o en cada versión |
| Cualquier proyecto | Después de una migración, un rediseño o la instalación de nuevos componentes |
Si cobras con tarjeta, PCI DSS 4.x exige en su requisito 11.3.2 escaneos externos al menos una vez cada tres meses realizados por un proveedor aprobado por el PCI Security Standards Council (ASV), repitiéndolos hasta obtener un resultado aprobado. En un proyecto de diseño de tiendas online conviene resolver pronto este requisito eligiendo bien la pasarela: si el pago se hace en la página del proveedor, el alcance es menor, aunque no desaparece.
06 Qué hacer con los resultados y cómo informar de un fallo
- ✓Agrupa los hallazgos por causa: diez avisos pueden venir de un solo plugin desactualizado.
- ✓Asigna a cada uno responsable y plazo según gravedad y exposición.
- ✓Si no hay parche, mitiga: desactiva el componente o bloquea el ataque en el WAF.
- ✓Revisa los registros para comprobar si el fallo se explotó antes de corregirlo; si hay rastro de malware, limpia antes de parchear.
- ✓Documenta las excepciones aceptadas con su motivo y fecha de revisión.
- ✓Compara cada informe con el anterior para medir si la superficie de ataque baja.
Una infección por malware suele ser la prueba de que una vulnerabilidad llegó antes que el escáner. Y si eres tú quien encuentra un fallo en software de terceros, sigue la divulgación responsable: avisa al fabricante por su canal de seguridad (el archivo /.well-known/security.txt del RFC 9116 indica el contacto), da un plazo razonable y no publiques detalles hasta que exista corrección.
En los proyectos de desarrollo de aplicaciones web a medida el escaneo forma parte del ciclo de entrega: dependencias revisadas en cada compilación, análisis dinámico antes de cada versión y un informe que el cliente puede enseñar en una auditoría.
Preguntas frecuentes sobre Vulnerability scanning (escaneo de vulnerabilidades)
Es un análisis automatizado de webs, servidores, redes o código que detecta fallos de seguridad conocidos y configuraciones inseguras, y los ordena por gravedad en un informe.
El escaneo es automático, rápido y repetible, y encuentra fallos conocidos. El pentesting lo hace una persona que combina fallos, prueba la lógica de negocio y demuestra hasta dónde llega un atacante. Se complementan.
DAST analiza la aplicación en ejecución desde fuera, como haría un atacante. SAST analiza el código fuente sin ejecutarlo. DAST encuentra problemas reales de despliegue y SAST detecta errores antes de publicar.
Con WPScan, que detecta versiones vulnerables del núcleo, plugins y temas, o con un plugin o servicio de seguridad que vigile esas versiones a diario. Complétalo con un escaneo DAST como ZAP.
Solo si es tuya o tienes autorización del propietario. Un escaneo activo no autorizado puede constituir un delito de acceso o daños informáticos y suele provocar bloqueos de IP.
Como mínimo, mensual en webs sencillas y tras cada cambio importante. Si procesas tarjetas, PCI DSS exige escaneos externos al menos trimestrales por un proveedor aprobado.
Un ASV (Approved Scanning Vendor) es una empresa autorizada por el PCI Security Standards Council para hacer los escaneos externos de vulnerabilidades que PCI DSS exige a quien procesa pagos con tarjeta, al menos una vez cada tres meses.
Sí. ZAP, Nmap y Greenbone OpenVAS son de código abierto, y la CLI de WPScan es gratuita; su API permite 25 peticiones diarias sin coste para uso no comercial.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗