En resumen: pentest o escaneo de vulnerabilidades no es una cuestión de «o lo uno o lo otro», sino de orden. Un escaneo de vulnerabilidades encuentra de forma automatizada vulnerabilidades conocidas y errores de configuración, con rapidez y a bajo coste, pero con falsas alarmas y puntos ciegos. Una prueba de penetración comprueba de forma dirigida qué podría lograr realmente un atacante. Un programa de bug bounty abre la auditoría a investigadores externos y solo compensa cuando los escaneos y los pentests forman parte de la rutina. Para la mayoría de las pymes, el orden es: escanear con regularidad, corregir los hallazgos, hacer pruebas dirigidas y crear un punto de notificación de vulnerabilidades.
Por qué la pregunta se replantea tras PHP2Shell
Quien tras PHP2Shell audita su sitio web con un escáner en línea puede obtener resultados desconcertantes. Un escáner notifica quizá una vulnerabilidad crítica aunque el proveedor de alojamiento haya confirmado el parche. Otro no notifica nada aunque el servidor siga usando una versión antigua de PHP, porque se oculta la indicación de versión.
La razón está en el modo de trabajo. Muchos escáneres deducen la vulnerabilidad a partir de la versión mostrada. Pero las distribuciones instalan backports sin cambiar el número de versión; según los informes, por ejemplo Ubuntu 24.04 sigue mostrando 8.3.6 tras la actualización. Por qué es así lo explica Por qué php -v muestra el mismo número tras la actualización. La prueba fiable la proporciona el registro de cambios del paquete; véase Comprobar correctamente la versión de PHP y el estado del parche.
Esto no es un argumento contra los escáneres, sino a favor de conocer sus límites y combinarlos con otros métodos.
Pentest o escaneo de vulnerabilidades: los tres métodos comparados
| Criterio | Escaneo de vulnerabilidades | Prueba de penetración | Bug bounty |
|---|---|---|---|
| ¿Quién audita? | Herramienta automatizada | Especialistas contratados | Investigadores externos, a menudo mediante una plataforma |
| ¿Qué se encuentra? | Vulnerabilidades conocidas, versiones obsoletas, errores de configuración | Vulnerabilidades explotables, errores de lógica, encadenamientos | Lo que los investigadores encuentran y comunican, a menudo algo inusual |
| Profundidad | Amplia, pero superficial | Profunda dentro del alcance acordado | Variable, según los participantes |
| Falsas alarmas | Frecuentes | Raras, los hallazgos se acreditan | Muchos avisos que hay que valorar |
| Planificabilidad | Alta, repetible a voluntad | Alta, periodo y alcance fijos | Baja, los avisos llegan de forma continua |
| Requisitos en la empresa | Alguien que valore los resultados | Alcance acordado, entorno de pruebas o ventana de mantenimiento | Proceso maduro de valoración, corrección y recompensa |
| Uso típico | De forma continua, por ejemplo mensual o tras cambios | Antes del lanzamiento, tras cambios importantes, con regularidad | Complementario en aplicaciones maduras y expuestas |
Ninguno de los métodos sustituye a los demás. El escaneo muestra mucho en poco tiempo, el pentest muestra lo que realmente cuenta y el bug bounty encuentra aquello en lo que nadie había pensado.
En los escáneres conviene además una segunda mirada al tipo de escaneo. Un escaneo desde fuera solo ve lo que ve cualquier visitante y a menudo debe adivinar las versiones a partir de las respuestas del servidor. Un escaneo autenticado, en el que la herramienta lee con credenciales propias los paquetes instalados en el servidor, ofrece resultados claramente más fiables, precisamente en cuanto al estado real del paquete de PHP. Pero presupone que usted configure para ello un acceso restringido y lo proteja bien. Para las dependencias de las propias aplicaciones PHP existen a su vez herramientas de revisión específicas, como composer audit para los paquetes de Composer.
El orden razonable para las pymes
- Inventario y escaneo: primero saber qué sitios web y servidores hay y después escanear con regularidad. No asumir los hallazgos sin revisarlos, sino valorarlos.
- Corregir lo básico: eliminar el software obsoleto, las actualizaciones que faltan y los errores de configuración evidentes. Programar un pentest sobre sistemas sin parchear malgasta presupuesto.
- Prueba de penetración dirigida: para las aplicaciones más importantes, como la tienda, el portal de clientes o las interfaces, con un alcance claramente acordado y una nueva prueba posterior.
- Revisión del código en desarrollos propios: quien opera aplicaciones PHP propias complementa la prueba con una revisión del código fuente. Cómo se desarrolla lo describe Revisión de código de seguridad para proyectos PHP.
- Punto de notificación de vulnerabilidades: una política sobre cómo pueden comunicar vulnerabilidades los externos y un archivo security.txt según RFC 9116 en
/.well-known/security.txtcon contacto y fecha de caducidad. - Bug bounty cuando lo básico esté asentado: solo cuando los avisos se valoren con fiabilidad y las vulnerabilidades se corrijan con prontitud.
Para que de esto salga un procedimiento permanente, merece la pena ver Gestión de vulnerabilidades para la pyme.
Lo que ninguno de los métodos logra
Ningún método de auditoría demuestra que un sistema sea seguro. Solo muestra lo que se encontró en un momento dado con determinados métodos. Un informe de pentest limpio de la primavera no dice nada sobre una vulnerabilidad como PHP2Shell, que se conoce en octubre.
Tampoco responden el escaneo ni el pentest a la pregunta de si un servidor ya está comprometido. Para ello hace falta una búsqueda de rastros en el propio sistema: procesos, archivos, tareas cron, cuentas, conexiones. Es una tarea propia con métodos propios.
Haga auditar solo los sistemas para los que esté autorizado y aclare de antemano, en los sistemas alojados, las normas del proveedor. Una prueba de penetración necesita un encargo por escrito con alcance, periodo e interlocutores.
Cuándo no necesita una prueba externa
Para un sitio web corporativo sencillo sin formularios con datos sensibles, en un proveedor de alojamiento que instala las actualizaciones con fiabilidad, a menudo basta un escaneo periódico con valoración crítica de los resultados. Una prueba de penetración sería aquí normalmente desproporcionada. Son más importantes el software actualizado, los accesos sólidos y las copias de seguridad.
Una prueba externa compensa en tiendas, portales, desarrollos propios, interfaces con sistemas internos y siempre que clientes o normas exijan una prueba independiente.
¿Cómo ayuda PHP SOS en concreto?
- Configuramos escaneos periódicos y valoramos los resultados, incluidas las falsas alarmas por backports.
- Ayudamos a corregir lo básico antes de que el dinero fluya a un pentest.
- Junto con socios especializados realizamos auditorías de seguridad y pruebas de penetración con alcance acordado y nueva prueba posterior.
- Apoyamos la creación de un punto de notificación de vulnerabilidades y de un security.txt.
Conclusión
El escaneo, el pentest y el bug bounty son peldaños, no competidores. Quien empieza con escaneos periódicos, corrige lo básico y después hace pruebas dirigidas obtiene la máxima seguridad para su presupuesto. El bug bounty es la guinda para las organizaciones cuya obligación básica ya está asentada.
Preguntas frecuentes
¿Cuál es la diferencia entre un pentest y un escaneo de vulnerabilidades?
Un escaneo de vulnerabilidades comprueba de forma automatizada si se reconocen vulnerabilidades conocidas o errores de configuración. Una prueba de penetración va más lejos: especialistas intentan, dentro de un marco acordado, aprovechar y encadenar realmente las vulnerabilidades y valoran las consecuencias.
¿Averigua un escáner si mi servidor está parcheado contra PHP2Shell?
Solo de forma limitada. Muchos escáneres leen la versión de PHP mostrada. Si la distribución instala un backport, el número suele seguir igual y el escáner notifica una vulnerabilidad que hace tiempo está cerrada. A la inversa, puede mostrarse un número nuevo mientras siguen en ejecución procesos antiguos.
¿Es un programa de bug bounty algo para pequeñas empresas?
Normalmente todavía no. El bug bounty presupone que los avisos se valoran rápido y las vulnerabilidades se corrigen con prontitud. Un buen comienzo es una sencilla política de notificación de vulnerabilidades con un archivo security.txt.
¿Puedo auditar mi sitio web yo mismo con un escáner?
Sus propios sistemas, por lo general sí, si está autorizado para ello. Si el sitio web está en un proveedor de alojamiento, aclare antes si los escaneos están permitidos o deben anunciarse. Los sistemas ajenos solo se auditan con autorización escrita del operador.
¿Con qué frecuencia debe hacerse un pentest?
No hay una regla fija. Lo habitual es una prueba antes del lanzamiento de una aplicación nueva, tras cambios importantes y a intervalos regulares que determinan su riesgo y, en su caso, las exigencias de clientes o normas.