Análisis de vulnerabilidades o pentest: ¿cuál necesitas?

Dos presupuestos encima de la mesa, una diferencia de precio de uno a cinco y, a primera vista, la misma promesa: «identificamos tus vulnerabilidades». Ahí es donde la mayoría de responsables de seguridad se paran, y hacen bien. Las dos líneas no describen el mismo trabajo ni responden a la misma pregunta.

La petición suele llegar además en el mismo estado. Alguien ha lanzado una herramienta, tiene delante 340 resultados con 28 marcados como «crítico» y no sabe por dónde empezar. La reacción correcta casi nunca es ponerse con los 28. Es averiguar cuáles de ellos significan algo de verdad en tu entorno.

Este artículo separa tres términos que los presupuestos mezclan, explica qué encuentra una herramienta automática y qué no puede encontrar por construcción, y entra en la pregunta que casi nadie trata en español: de qué sirve como prueba cada uno de los dos trabajos cuando quien pregunta es un cliente, una entidad certificadora o un órgano de contratación. Porque esa es la parte que paga la factura.

Conviene que sepas cuál es nuestro interés antes de seguir: vendemos los dos. Por eso hemos preferido citar las normas a resumirlas y decir con la misma claridad cuándo te basta el trabajo barato.

Tres palabras que los presupuestos mezclan

En español la distinción existe y es limpia, pero se pierde en cuanto alguien traduce del inglés a ojo. Cuesta dinero justo en el momento de comparar dos ofertas.

La herramienta. El escáner: Nessus, OpenVAS, Nuclei, Qualys y compañía. Se compra por suscripción, se programa y produce una lista. Es un medio de trabajo, no un servicio.

El servicio: análisis de vulnerabilidades. La pasada automatizada, después la verificación humana de lo que importa, después la priorización según la exposición real. Es el término que usa el mercado español para el servicio, y es el que aparece en los pliegos. La traducción literal del inglés circula por ahí, pero en España el servicio se llama así, y lo llamamos igual en nuestra página de análisis de vulnerabilidades.

El pentest. Un trabajo de otra naturaleza: no se constata la presencia de un fallo, se demuestra qué haría un atacante con él. En registro de contratación se escribe test de intrusión, que es la forma que verás en un pliego y en la carpeta de un auditor, y así titulamos nuestra página de test de intrusión.

Y una cuarta cosa que no es ninguna de las tres: la gestión de vulnerabilidades. Es el proceso continuo que envuelve a todo lo anterior: detectar, registrar, priorizar, asignar, corregir y comprobar. La herramienta es una de sus fuentes, el análisis es su revisión periódica y el pentest es su sondeo en profundidad. Quien te venda una gestión de vulnerabilidades en sustitución de un pentest te está vendiendo un proceso en lugar de un hallazgo.

Una nota de vocabulario que ahorra malentendidos en una mesa de contratación. La expresión «pruebas de penetración» aparece en este artículo varias veces, siempre entrecomillada, porque es la que emplean el Real Decreto 311/2022 y la versión española de la normativa europea. Fuera de ese registro no es la forma que usa el mercado —en español general nombra además un ensayo geotécnico—, así que en una conversación comercial se dice pentest y en un documento de cumplimiento se escribe test de intrusión. No es una manía de estilo: si en un pliego buscas la palabra equivocada, no encuentras la cláusula.

La pregunta útil no es cuál es mejor

Es de qué sirve como prueba cada uno. La palabra «prueba» hace aquí doble trabajo, y esa es justamente la confusión: prueba es lo que ejecutas, y prueba es lo que entregas.

Casi ningún comparativo en español llega hasta aquí, y es la parte que decide el presupuesto, porque nadie compra un pentest por curiosidad técnica. Se compra porque alguien —un cliente que exige un informe antes de firmar, una entidad certificadora, un órgano de contratación, un delegado de protección de datos— va a pedir una evidencia, y esa evidencia tiene una forma concreta.

La consecuencia práctica es incómoda para quien vende solo una de las dos cosas: casi nunca es uno u otro. Es cuál de los dos te falta ahora mismo para poder enseñar lo que te van a pedir.

Lo que pide el RGPD, palabra por palabra

El Reglamento (UE) 2016/679 no nombra el pentest. Tampoco el análisis de vulnerabilidades. Describe un resultado, y eso es lo que hay que leer con cuidado.

El art. 32.1 obliga al responsable y al encargado del tratamiento a aplicar «medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo», y enumera a continuación, «que en su caso incluya, entre otros», cuatro medidas. La cuarta, la del apartado d), es la que nos ocupa:

«un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento»

Tres expresiones soportan todo el peso de esa frase.

1. «Un proceso».

El texto no pide un informe, pide un dispositivo recurrente, documentado y con alguien asignado. Un pentest aislado, por bueno que sea, no es un proceso. Una suscripción a una herramienta cuyos resultados no lee nadie, tampoco. Esta es la razón por la que una organización con un informe excelente de hace catorce meses y nada después está peor colocada de lo que cree.

2. «Regulares».

No hay ninguna frecuencia escrita. Te toca a ti justificarla en función del riesgo, y esa justificación se escribe. En este punto concreto, un análisis mensual del que queda rastro vale más que un pentest anual cuya fecha se desplaza cada año.

3. «La eficacia de las medidas».

Esta es la palabra que reparte el trabajo entre los dos servicios. Una pasada de herramienta mide la presencia de defectos conocidos en componentes; no mide si tus medidas funcionan. Que la segmentación aguante, que el doble factor no se rodee por una API que no lo exige, que el aislamiento entre dos clientes de una aplicación multiinquilino resista: ninguna de las tres cosas aparece en la salida de un escáner, y las tres son medidas en el sentido del art. 32.

Así que la respuesta práctica se parte en dos, y conviene decirla sin adornos:

• para «verificación y valoración regulares», un análisis de vulnerabilidades recurrente y documentado hace el trabajo, a un coste que ninguna otra cosa se acerca;
• para «eficacia», hacen falta hallazgos verificados, alcance escrito, fecha y comprobación posterior de las correcciones. Esa es la forma de un informe de test de intrusión, no la de una exportación de herramienta.

Dos precisiones que se olvidan. La primera: el inciso «que en su caso incluya, entre otros» significa que la enumeración no es una lista cerrada de obligaciones absolutas, pero el apartado d) sigue siendo la única disposición del RGPD que nombra expresamente la verificación periódica, y es lo primero que va a buscar un delegado de protección de datos. La segunda: el art. 32 se dirige también al encargado del tratamiento. Si desarrollas software en modo alojado, tus clientes te van a pedir ese informe por contrato mucho antes de que la Agencia Española de Protección de Datos se interese por ti.

Lo que no se puede decir, y se dice demasiado: que el RGPD «obliga a hacer un pentest». No lo hace. Lo que obliga es a demostrar un proceso, y el pentest es la forma más sólida de demostrar una parte de él.

El ENS los separa por su cuenta, y esa es la mejor prueba

Si tuviéramos que elegir un solo argumento para toda esta página, sería este, porque no lo firmamos nosotros: lo firma un real decreto.

El Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (BOE-A-2022-7191) incluye en su Anexo II la medida op.mon.3, del marco operacional. Su refuerzo R6, «Inspecciones de seguridad», dice literalmente:

«Periódicamente, o tras incidentes que hayan desvelado vulnerabilidades del sistema nuevas o subestimadas, se realizarán las siguientes inspecciones: [op.mon.3.r6.1] Verificación de configuración. [op.mon.3.r6.2] Análisis de vulnerabilidades. [op.mon.3.r6.3] Pruebas de penetración.»

Tres inspecciones, tres códigos, un orden. Si fueran el mismo trabajo, el decreto no habría necesitado dos puntos distintos para las dos últimas. Es la demostración más limpia que existe en español de que no son intercambiables, y viene del propio regulador.

El orden tampoco es decorativo. Primero se comprueba cómo está configurado el sistema, después se identifica lo que está expuesto y, por último, se intenta explotarlo y encadenarlo. Es exactamente la secuencia con la que se construye una campaña seria. A quien te ofrezca lo tercero sin haber hecho lo primero le estás comprando la parte vistosa del trabajo.

Ahora el dato honesto, que alguna página de cumplimiento se salta: R6 entra en la cláusula de aplicación de la categoría ALTA. La cláusula de op.mon.3 suma R1 y R2 en categoría MEDIA, y R1 a R6 en ALTA. De modo que los dos puntos, r6.2 y r6.3, se activan por esta vía en sistemas de categoría ALTA, no en los demás. Y el decreto no fija ninguna frecuencia: dice «periódicamente» y añade un disparador concreto, los incidentes que revelen vulnerabilidades nuevas o subestimadas.

Lo que sí tiene plazo es la auditoría. El art. 31 somete los sistemas incluidos en el ámbito de aplicación a «una auditoría regular ordinaria, al menos cada dos años», más una auditoría extraordinaria obligatoria cuando se produce una modificación sustancial que afecte a las medidas exigidas, que además reinicia el cómputo. El art. 31.3 añade que esa auditoría se apoya en «criterios, métodos de trabajo y de conducta generalmente reconocidos».

Y el art. 38.1 separa las dos vías de conformidad: los sistemas de categoría MEDIA o ALTA «precisarán de una auditoría para la certificación de su conformidad», mientras que los de categoría BÁSICA «solo requerirán de una autoevaluación para su declaración de la conformidad». Quién puede hacer cada cosa no es lo mismo en los dos casos, y lo desarrollamos en quién puede auditar el ENS.

Dos cosas conviene no confundir, porque el mercado las confunde a diario:

• La auditoría bienal del art. 31 no es un pentest. Es una auditoría de cumplimiento del esquema. Los trabajos técnicos —el análisis de vulnerabilidades, las pruebas ofensivas— alimentan esa auditoría con evidencia; no la sustituyen.
• El ENS no alcanza a una empresa privada por el mero hecho de vender a la Administración. El art. 2.3 lo condiciona a prestar servicios o proveer soluciones a entidades del sector público «para el ejercicio por estas de sus competencias y potestades administrativas», y el mecanismo real son los pliegos. Lo que el decreto exige de verdad en materia de pentesting lo detallamos en qué exige realmente el ENS sobre pentesting.

Haxoris no es entidad de certificación acreditada por ENAC y no expide certificaciones ni declaraciones de conformidad con el ENS. Lo que hacemos es el trabajo técnico que esas dos líneas del Anexo II describen, con informe de alcance, hallazgos y verificación posterior.

El Reglamento (UE) 2024/2690: el tipo de prueba sale del análisis de riesgos

Aquí está la norma que responde mejor que ninguna otra a la pregunta «¿cada cuánto y de qué tipo?», y casi nadie la cita en español.

El Reglamento de Ejecución (UE) 2024/2690 desarrolla los requisitos técnicos y metodológicos de las medidas de gestión de riesgos de la Directiva (UE) 2022/2555 para un grupo cerrado de entidades: proveedores de servicios DNS, registros de nombres de dominio de primer nivel, proveedores de servicios de computación en nube y de centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de servicios gestionados de seguridad, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza. Es directamente aplicable desde el 18 de octubre de 2024 y no depende de que España haya transpuesto la directiva.

Su anexo dedica el punto 6.5 a las pruebas de seguridad, y lo hace en tres tiempos:

Lo importante del 6.5.2 no es que obligue a hacer pentesting. No lo hace. Lo que obliga es a que el tipo de prueba sea una consecuencia razonada del riesgo y no una costumbre heredada del presupuesto del año pasado. Eso da la vuelta a la conversación: la pregunta deja de ser «¿qué es obligatorio?» y pasa a ser «¿qué riesgo tengo, y qué prueba lo mide?».

Y una segunda honestidad, porque es lo que evita que compres de más: el punto 6.5 no exige que quien ejecuta la prueba sea externo ni independiente. Un equipo interno que trabaje con una metodología documentada y deje registro cumple el texto. Lo que se compra fuera se compra por otras razones —mirada ajena, especialización, y un informe que un tercero acepta sin discutir quién lo firma—, y esas razones hay que sostenerlas en sus propios términos, no inventando una obligación.

Sobre el estado de la directiva en España conviene ser exacto. A 12 de septiembre de 2026, la Directiva (UE) 2022/2555 no está transpuesta al derecho español; el régimen operativo sigue siendo el Real Decreto-ley 12/2018 y el Real Decreto 43/2021, ninguno de los dos derogado. Qué obliga hoy y qué no lo tratamos en NIS2 en España, y la preparación en nuestra página de pentesting para NIS2.

DORA (Reglamento (UE) 2022/2554) es un régimen aparte, para entidades financieras, con su propio marco de pruebas. No traslades sus obligaciones a un contexto que no es el suyo.

ISO 27001: dos controles, dos evidencias

El Anexo A de la norma distingue dos controles que se confunden con frecuencia, y la distinción es exactamente la de este artículo:

• A.8.8, sobre la gestión de vulnerabilidades técnicas: se satisface con un dispositivo de análisis documentado, con seguimiento y con decisiones registradas.
• A.8.29, sobre las pruebas de seguridad en desarrollo y aceptación: espera pruebas, no inventarios.

Por eso un programa ISO 27001 serio lleva los dos, y por eso un informe sin prueba de concepto se cae en cuanto alguien lo mira de cerca. Un apunte necesario: la certificación la expide un organismo de certificación acreditado, no nosotros; lo que aportamos es el trabajo técnico que sirve de evidencia ante él, como explicamos en pentesting para ISO 27001.

Qué encuentra bien una herramienta automática

Puesto el límite, conviene decir lo otro: un escáner es excelente en su terreno, y su terreno no es pequeño.

• Componentes desactualizados con CVE conocidas, sobre cientos de sistemas en una noche.
• Errores de configuración con firma clara: interfaces de administración abiertas, credenciales por defecto, listado de directorios, puntos de depuración que se quedaron activos.
• Configuraciones TLS débiles, certificados caducados, versiones de protocolo obsoletas todavía aceptadas.
• Cabeceras de seguridad ausentes y permisos manifiestamente amplios.
• Desviaciones respecto de una línea base: qué ha cambiado desde la pasada anterior.

Es justo el trabajo que una persona no debería hacer a mano: voluminoso, repetitivo y propenso al error en cuanto se hace a ojo. Por eso nuestro análisis de vulnerabilidades también empieza con pasadas automatizadas. Simplemente no se queda ahí.

Conviene saber también dónde se acaba el alcance de la herramienta por razones físicas. En equipos con firmware propio, un escáner de red llega a la superficie del dispositivo y no más allá: lo que hay por debajo es terreno de un test de intrusión de OT, ICS e IoT.

Cómo funciona, en cuatro pasos

1. Descubrimiento. Qué equipos responden, qué puertos están abiertos, qué servicios hay detrás.
2. Identificación. Qué software y qué versión se esconden tras cada servicio. Es el paso sobre el que se apoya todo lo demás, y el que más se equivoca.
3. Correlación. La versión detectada se compara con una base de vulnerabilidades publicadas, identificadas por su número CVE.
4. Puntuación. Cada coincidencia recibe una severidad, casi siempre la puntuación base CVSS heredada de la ficha CVE.

El punto decisivo cabe en una frase: en la mayoría de las comprobaciones la vulnerabilidad se deduce, no se demuestra. La herramienta lee «nginx 1.18.0», encuentra una ficha CVE que encaja y la reporta. No ha comprobado que ese fallo sea alcanzable en tu configuración.

Qué no puede encontrar, y no por falta de calidad

Las clases de hallazgo que vienen ahora no son difíciles para una herramienta: le son estructuralmente inaccesibles, porque no sabe qué debería estar permitido en tu aplicación.

• Fallos de autorización. El usuario A ve los pedidos del usuario B. Para la herramienta eso es una respuesta HTTP 200 correcta. No tiene forma de saber de quién debería ser cada registro.
• Fallos de lógica de negocio. Un código de descuento que se puede canjear dos veces. Un paso del proceso de compra que se puede saltar. Un importe negativo que se contabiliza como abono.
• Cadenas de vulnerabilidades. Una fuga de información menor, más una política de contraseñas floja, más una cuenta de pruebas olvidada: juntas, una toma de control completa. La herramienta reporta tres hallazgos de severidad baja y no ve la cadena.
• Elusión del doble factor por un camino secundario, por ejemplo una API que no lo exige.
• Fugas funcionales de datos. Un endpoint que devuelve más campos de los que pinta la pantalla: técnicamente correcto y, desde el punto de vista del RGPD, una violación de seguridad de datos personales.

El ejemplo que resume la diferencia

Una tienda en línea permite usar dos veces el mismo código de descuento. No hay CVE, no hay versión desactualizada, no hay parámetro mal puesto: el código hace exactamente lo que alguien escribió. Una herramienta no ve nada, y no puede ver nada, porque no existe una base de datos de fallos que solo existen en tu aplicación.

Quien prueba con una cuenta de test y media hora lo encuentra. Y lo mismo con el paso del pedido que se salta, con la transferencia de importe negativo y con el usuario que accede a datos ajenos cambiando un identificador en la URL. Por eso los dos servicios no son intercambiables, y por eso el presupuesto más barato casi nunca es el mismo producto que el otro. La metodología con la que se buscan estas clases en una aplicación web está publicada: es la OWASP WSTG, y se puede exigir por nombre en un pliego.

Falsos positivos: por qué hay tantos

El caso más frecuente en la práctica son los parches retroportados. Debian, Red Hat y otras distribuciones incorporan la corrección de seguridad a su propio paquete sin subir el número de versión que anuncia la aplicación. El fallo está cerrado y la herramienta lo sigue marcando: solo conoce el número.

A eso se suman:

• código inalcanzable: la función vulnerable está en la biblioteca, pero tu aplicación no la llama nunca;
• medidas compensatorias: un WAF, una segmentación de red o una autenticación previa hacen inviable el camino de ataque en la práctica;
• identificación errónea: un proxy inverso o una cabecera modificada a propósito llevan a una coincidencia enteramente falsa.

De ahí sale el paso que convierte una salida de herramienta en un servicio: verificar a mano cada hallazgo serio, descartar el resto como ruido y escribir por qué. Una lista entregada sin ese paso ocupa a tu equipo durante semanas en cosas que no cuentan y, lo que es peor, lo distrae de la que sí contaba.

Cómo leer una puntuación CVSS sin equivocarte

La puntuación CVSS se lee habitualmente como si fuera un riesgo. No lo es. Describe la vulnerabilidad en sí misma, bajo supuestos estándar, sin saber nada de tu entorno.

Una puntuación base de 9,8 significa: explotable desde la red, sin credenciales, con impacto completo en confidencialidad, integridad y disponibilidad —si el sistema está expuesto como la puntuación supone. Cuatro preguntas convierten ese número en una prioridad real.

En la práctica, un 6,5 en el portal de clientes es casi siempre más urgente que un 9,8 en una maqueta aislada. Esa traducción es la priorización, y es la que ordena tus tres próximos meses. También es la parte que no viene en la exportación de la herramienta.

El cuadro comparativo

El orden es creciente, no alternativo. Quien solo pasa la herramienta obtiene una lista larga sin prioridades. Quien solo prueba una vez al año se pierde todas las CVE publicadas en los once meses que separan una campaña de la siguiente.

Cómo reconocer un análisis vendido como pentest

Tres señales, y las tres se ven en el presupuesto o en el informe de muestra antes de firmar.

1. Ningún hallazgo lleva prueba.

Cada vulnerabilidad tiene una descripción cuidada, pero en ninguna parte se explica cómo la reprodujo quien la encontró. Sin reproducción no hay demostración, y sin demostración no tienes una prueba de eficacia: tienes un inventario con mejor tipografía.

2. Las descripciones son genéricas.

Salen de una base de datos y no dicen nada de tu entorno. Un párrafo que serviría igual para cualquier cliente no es un hallazgo, es una ficha.

3. Hay precio antes de que exista alcance.

Dar una cifra sin saber cuántas aplicaciones, cuántos roles y cuántas integraciones hay es adivinar —o entregar una pasada automatizada. Nosotros tampoco presupuestamos sin alcance, y por eso la página se llama solicitar presupuesto y empieza con preguntas.

Pide siempre un informe de muestra anonimizado y mira una sola cosa: la prueba de concepto asociada a un hallazgo serio. Está, o no está. El resto de la conversación depende de eso. Hemos desarrollado esta forma de evaluar, pregunta a pregunta, en cómo elegir una empresa de pentesting.

Un pentest de verdad cuesta más, y es normal. Lo que recibes a cambio es una lista corta en la que cada punto está demostrado, en lugar de una lista larga que todavía tienes que ordenar tú.

Un calendario de doce meses que aguanta una revisión

Un esquema que funciona en una pyme o en una empresa mediana, y que además se deja escribir en una política:

1. Pasada continua. Lo expuesto a internet, cada semana; la red interna, cada mes; más una pasada extra tras cada cambio relevante. La razón no es que tus sistemas cambien deprisa, sino que cada día se publican CVE nuevas: un sistema sano ayer puede tener un fallo crítico hoy sin que nadie lo haya tocado.
2. Revisión trimestral con criterio humano. Alguien retoma los hallazgos serios, descarta los falsos positivos y ordena la lista por prioridad real. Ese es el análisis de vulnerabilidades.
3. Pentest anual. Cubre las clases que ninguna herramienta encuentra y produce la evidencia que te va a pedir un cliente o una auditoría. Para una aplicación expuesta, empieza por un test de intrusión de aplicaciones web; para un dominio de Active Directory, por un test de intrusión de infraestructura.
4. Verificación después de corregir. Sin comprobación posterior documentas un problema, no una solución, y es la solución lo que te van a pedir. En Haxoris la verificación va incluida en el precio del servicio.
5. Una revisión al año de la propia decisión. Es literalmente lo que exige el punto 6.5.3 del anexo del Reglamento (UE) 2024/2690 a las entidades que alcanza, y es buena práctica para todas las demás.

Si lo que tienes delante es una auditoría concreta con fecha, el orden cambia un poco: primero se cierra el alcance, después se ejecuta, y la lista de deberes previos la hemos escrito en cómo prepararse para una auditoría de ciberseguridad. La auditoría en sí, como servicio, está en auditoría de ciberseguridad.

Todos nuestros trabajos se ejecutan con autorización escrita y sobre un alcance definido contractualmente. No es una formalidad: los arts. 197 bis, 197 ter, 264, 264 bis y 264 ter del Código Penal describen las conductas de acceso e interferencia «sin estar debidamente autorizado», y la autorización escrita es lo que separa una prueba de seguridad de un delito.

Preguntas frecuentes

¿Sigues sin tenerlo claro? Lo decimos cuando basta con un análisis de vulnerabilidades: te cuesta menos y te evita comprar una profundidad para la que todavía no tienes uso. Describe el alcance en cuatro líneas y solicita presupuesto, o empieza por leer qué es el pentesting.

Nuestros servicios relacionados: análisis de vulnerabilidades de tus sistemas y aplicaciones · pentesting y tests de intrusión de tus aplicaciones e infraestructuras · auditoría de infraestructura con tests de intrusión externos e internos · auditoría de ciberseguridad de tu entorno tecnológico