Una evaluación de vulnerabilidades es la revisión sistemática de un sistema — código fuente, aplicaciones en ejecución, configuraciones de nube, dependencias, infraestructura — para identificar debilidades de seguridad, clasificarlas según el riesgo que representan y reportarlas para que se corrijan. Abarca el escaneo automatizado y las pruebas manuales, y termina en una lista priorizada de hallazgos, no en un inventario crudo.
En los sistemas que Fluid Attacks evaluó durante 2025, los escáneres automatizados detectaron el 55,8 % de la exposición al riesgo. El otro 44,2 % salió de técnicas manuales, y de ahí vino también el 87 % de los hallazgos de severidad crítica.
Esta página cubre qué es y qué no es una evaluación de vulnerabilidades, en qué se diferencia del escaneo de vulnerabilidades y del pentesting, los tipos que existen, los pasos que sigue una evaluación completa, qué debe contener su reporte para ser útil y qué dicen nuestros propios datos sobre lo que encuentra cada método.
¿Qué es una evaluación de vulnerabilidades?
La evaluación de vulnerabilidades es el proceso de examinar un sistema de información para hallar, clasificar y reportar sus debilidades de seguridad. Una evaluación completa reporta cada hallazgo con su categoría, su ubicación exacta, la evidencia que lo respalda y una calificación de severidad, para que la remediación se priorice en vez de adivinarse.
Tanto las herramientas automatizadas como las personas realizan evaluaciones de vulnerabilidades. Los escáneres basados en firmas comparan lo que ven contra una base de datos de problemas conocidos, como las entradas del listado Common Vulnerabilities and Exposures (CVE), lo que significa que su alcance está limitado por esa base. El análisis moderno está menos limitado que eso — nuestro AI SAST genera hallazgos candidatos en repositorios de código abierto que nuestros analistas luego validan, un trabajo que ha producido 12 advisories publicados hasta ahora — pero el punto general se mantiene: una herramienta encuentra lo que fue construida para reconocer.
Lo que una evaluación de vulnerabilidades no es: una prueba de penetración, un certificado de cumplimiento ni un proyecto de una sola vez. Es la capa de detección y reporte de la que depende el resto de la gestión de vulnerabilidades, y la calidad de todo lo que viene después queda limitada por ella.
Por qué importa la evaluación de vulnerabilidades
La evaluación de vulnerabilidades es la única parte de tu programa de seguridad que te dice qué encontraría un atacante de verdad. Todo lo que viene después — priorización, remediación, evidencia de cumplimiento — se construye sobre lo que la evaluación reporta, y hereda los puntos ciegos de ese reporte.
Exposición al riesgo, no conteo de vulnerabilidades
Una lista larga de hallazgos no es una medida de riesgo. Diez problemas de severidad baja no equivalen a uno crítico, y por eso puntuamos los hallazgos con CVSSF, una métrica de exposición al riesgo derivada de CVSS en lugar de un conteo plano. La brecha es amplia en la práctica: en nuestros datos de 2025, las vulnerabilidades reportadas por herramientas automatizadas promediaron 15,5 unidades CVSSF, mientras que las reportadas por nuestros pentesters promediaron 93,2, seis veces más. Una evaluación de vulnerabilidades que solo reporta cuántos problemas existen dice muy poco sobre qué tan expuesto estás.
Lo que cuesta detectar tarde
Corregir una debilidad antes de una publicación es más barato que corregirla en producción, y mucho más barato que responder a su explotación. Entre los sistemas que evaluamos en 2025, los que usaron nuestro CI Gate — que rompe el build cuando hay una vulnerabilidad que viola la política — alcanzaron una tasa de remediación del 72,2 % al cierre del año, frente al 58 % de los sistemas sin él, y sus equipos cerraron hallazgos en una mediana de 22 días contra 30.
Dónde entra el cumplimiento
Varios estándares esperan que las debilidades se identifiquen con regularidad y se corrijan, y esperan que lo demuestres. Nuestro catálogo mapea requisitos de seguridad directamente a PCI DSS, HIPAA, ISO 27001, GDPR y decenas de estándares y marcos más, así que un hallazgo puede rastrearse hasta el requisito que incumple. El cumplimiento es un subproducto de una evaluación de vulnerabilidades bien hecha, no una razón para hacerla.
Evaluación, escaneo y pruebas de penetración no son lo mismo
La evaluación de vulnerabilidades, el escaneo de vulnerabilidades y las pruebas de penetración se usan de forma intercambiable, incluso por proveedores. No son equivalentes, y la diferencia decide qué vas a encontrar y qué no.
Práctica | Qué es | Quién la ejecuta | Qué encuentra | ¿Confirma explotabilidad? |
Evaluación de vulnerabilidades | El proceso completo de hallar, clasificar y reportar debilidades | Herramientas, personas o ambas | Depende de los métodos que incluya | Solo si incluye pruebas manuales |
Escaneo de vulnerabilidades | Un método dentro de la evaluación: detección automatizada contra patrones conocidos | Escáneres automatizados | Clases de problemas conocidos, a escala y con velocidad | No |
Pruebas de penetración | Una metodología, no un objetivo: simular a un atacante para alcanzar una meta | Hackers éticos | Fallas lógicas complejas, ataques encadenados, zero-days | Sí, con evidencia del impacto |
El escaneo es un método; la evaluación de vulnerabilidades es el proceso que puede contenerlo. Las pruebas de penetración son un segundo método que puede ir dentro del mismo proceso. Los dos se complementan: los escáneres aportan amplitud y velocidad, los pentesters aportan profundidad y prueba, y la revisión manual además corrige lo que el escáner reportó mal, sacando falsos positivos del reporte final.
Evaluación de vulnerabilidades en Fluid Attacks
Ejecutamos la evaluación de vulnerabilidades como un atacante abordaría tu software: de forma continua, combinando IA, nuestros propios escáneres y nuestros pentesters. Lo que sigue es cómo funciona y qué dicen nuestros números al respecto, incluido el punto donde esos números dejan de ser evidencia.
▶️ Video: mostramos cómo nuestros escáneres con IA, nuestros escáneres determinísticos y nuestros pentesters certificados trabajan sobre el mismo sistema de una evaluación de vulnerabilidades completa.
Qué evaluamos, y bajo qué reglas
Toda evaluación de vulnerabilidades empieza por el alcance, acordado antes de las pruebas y puesto por escrito: qué aplicaciones web, aplicaciones móviles, APIs y microservicios, infraestructura de nube, contenedores e infraestructura como código entran, qué queda fuera de límites y qué evidencia podemos recolectar. La explotación se realiza para probar el impacto, nunca para causarlo: nuestros evaluadores confirman que una debilidad es alcanzable y explotable, y se detienen ahí.
Cómo se ve en la práctica
Superficie | Técnica | Evidencia que recibes |
Código fuente | Archivo, línea y flujo de datos, con ejemplos de código que cumple | |
Aplicaciones en ejecución | Request, response y una prueba de concepto reproducible | |
Dependencias | Componente afectado, versión y si el código vulnerable es alcanzable | |
Nube y contenedores | Recurso mal configurado o credencial expuesta, con su ubicación | |
Binarios y componentes cerrados | Lógica recuperada del binario y la debilidad que expone |
Escaneo automatizado y pruebas manuales en nuestros datos
Entre el 1 de enero y el 31 de diciembre de 2025 registramos 1.119.396 vulnerabilidades en los sistemas que evaluamos, con 27.440.146 unidades CVSSF de exposición al riesgo. El desglose por método de detección:
Método | Porción de la exposición al riesgo | Hallazgos de severidad crítica | CVSSF promedio por hallazgo |
Automatizado (SAST, AI SAST, SCA, DAST, CSPM) | 55,8 % | 13 % | 15,5 |
Manual (PTaaS, secure code review, reverse engineering) | 44,2 % | 87 % | 93,2 |
Fuente: Fluid Attacks, State of Attacks 2026, sobre todos los sistemas evaluados en 2025. Las cifras de pentesters provienen solo de sistemas del plan Advanced; las de herramientas incluyen los planes Advanced y Essential.
El patrón es consistente: las herramientas cargan el volumen, las personas cargan la severidad. Eso es lo más útil que puedes saber cuando decides cómo dotar de personal una evaluación de vulnerabilidades.
Qué no demuestra el benchmark
En nuestro benchmark de herramientas AppSec y pentesting, ejecutado contra un universo de 1.201 vulnerabilidades repartidas en 105 categorías CWE, un pentester reportó 1.076 de ellas: 89,6 % de recall con 100 % de precisión. De ese universo, 743 vulnerabilidades — el 61,9 % — fueron detectadas por el pentester y por nadie más, frente a 36 herramientas de terceros de SAST, DAST o SCA.
Tres límites sobre ese resultado, porque una cifra sin sus salvedades no es evidencia:
La herramienta automatizada con mayor recall es nuestro propio escáner, con 22,7 %, frente al 89,6 % del pentester.
El conjunto de datos es curado, no un producto. 1.201 es el tamaño de un conjunto etiquetado de vulnerabilidades conocidas, no una aplicación en producción. Una cifra de recall medida contra casos de prueba con respuesta conocida no se traslada igual al software real, donde nadie sabe el total.
El recall se calcula sobre la porción que el pentester revisó. La nota al pie del propio benchmark dice que sus falsos negativos se cuentan como 73 y no 125, porque no volvió a revisar las secciones que el escáner ya había cubierto. Cambia ese denominador y el 89,6 % se mueve.
La herramienta automatizada con mayor recall en ese benchmark es nuestro propio escáner, con 22,7 %. Publicamos ese número precisamente porque es bajo. Los escáneres no están cerca de reemplazar a las personas, y preferimos decirlo a redondearlo hacia arriba.
La misma cautela aplica a la comparación de 2025: el promedio de 93,2 CVSSF de los pentesters viene de sistemas del plan Advanced, mientras que el promedio de 15,5 de las herramientas abarca ambos planes. Las bases no son idénticas, y la brecha de seis veces debe leerse con eso en mente.
Reevalúa cada corrección
Una corrección puede fallar, o introducir una debilidad nueva. En nuestra plataforma puedes solicitar un reattack, y el mismo hallazgo se prueba otra vez contra el código corregido antes de cerrarlo. Una evaluación de vulnerabilidades que nunca verifica sus propias remediaciones reporta intenciones, no estado.
Tipos de evaluación de vulnerabilidades
Las evaluaciones de vulnerabilidades suelen clasificarse por lo que se está evaluando, y la mayoría de los equipos ejecuta más de un tipo.
Tipo | Objetivo | Análisis típico |
Host | Servidores, estaciones de trabajo y otros dispositivos en una red | Revisión de configuración, nivel de parches, servicios expuestos |
Red | Una red completa, cableada o inalámbrica, y sus recursos alcanzables | Descubrimiento, identificación de puertos y servicios, chequeos de segmentación |
Base de datos | Bases de datos y entornos de big data | Control de acceso, cifrado, rutas de inyección, datos expuestos |
Aplicación | Aplicaciones web y móviles, APIs y microservicios | Análisis estático del código, análisis dinámico de la aplicación en ejecución |
Nube e IaC | Cuentas de nube, contenedores y definiciones de infraestructura | Gestión de postura, escaneo de imágenes, revisión de plantillas |
El pentesting no pertenece a esta lista de tipos de evaluación de vulnerabilidades. Es una metodología, definida por cómo se hacen las pruebas, no por qué sistema está bajo evaluación, y por eso se compara contra el escaneo de vulnerabilidades y no contra la evaluación de red o de aplicación.
Cómo funciona una evaluación de vulnerabilidades
La SP 800-115 del NIST (2008), la guía técnica para pruebas y evaluación de seguridad de la información, agrupa el trabajo en técnicas de revisión, identificación y análisis del objetivo — descubrimiento de red, identificación de puertos y servicios, escaneo de vulnerabilidades — y validación de vulnerabilidades del objetivo. La secuencia de abajo sigue esa forma.
Alcance e inventario de activos
No puedes evaluar lo que no has listado. Este paso fija qué sistemas, repositorios, cuentas y componentes de terceros están dentro del alcance, y cuánto vale cada uno para el negocio. A la mayoría de las evaluaciones de vulnerabilidades que se les escapa algo, se les escapa aquí, no durante la detección.
Detección
Los escáneres y los analistas trabajan sobre el alcance acordado de la evaluación de vulnerabilidades. La amplitud viene de la automatización que corre en cada commit y cada despliegue; la profundidad viene de los evaluadores que recorren la lógica de negocio que ninguna firma describe.
Validación
Una evaluación de vulnerabilidades que se salta la validación le envía sus propios errores a los desarrolladores, así que los hallazgos reportados se confirman primero. Aquí es donde se eliminan los falsos positivos y donde un problema sospechado se convierte en uno documentado, con evidencia adjunta.
Priorización
La severidad por sí sola es una mala fila. CVSS describe el impacto potencial; el EPSS estima la probabilidad de explotación; el catálogo Known Exploited Vulnerabilities de CISA — 1.734 entradas a octubre de 2026 — registra qué se está explotando ya en la realidad, y CISA recomienda usarlo como insumo para priorizar la gestión de vulnerabilidades.
Nuestro propio puntaje de prioridad funciona así. Parte de una base derivada de CVSS y la ajusta con las políticas de priorización de tu organización: la transitividad de la dependencia afectada, la fase de uso del componente vulnerable, si el problema aparece en la lista KEV de CISA, su valor de EPSS y el tiempo estimado de corrección. El resultado es un percentil contra todas las vulnerabilidades identificadas hasta ahora, que es algo más útil para ordenar que un puntaje sobre diez.
Remediación y verificación
Los hallazgos se asignan, se corrigen con cambios de código, cambios de configuración o parches, y luego se vuelven a probar. La evaluación de vulnerabilidades no termina cuando se entrega el reporte; termina cuando la corrección se confirma.
Ciclo de la evaluación de vulnerabilidades. Cada vuelta alimenta la siguiente: las correcciones verificadas cierran hallazgos, y los commits nuevos reabren el ciclo.
Dentro de un reporte de evaluación de vulnerabilidades
Un reporte de evaluación de vulnerabilidades es accionable cuando un desarrollador puede abrir un hallazgo y saber qué está mal, dónde está, por qué importa, qué hacer al respecto y cuánto debería tomar. Menos que eso y el reporte se vuelve un ejercicio de generar tiquetes. Esta es la parte que los compradores evalúan menos y sufren más, así que vale la pena ser concreto sobre los campos.
El hallazgo: qué, dónde y la evidencia que lo respalda
Todo hallazgo empieza con una categoría de debilidad — una clase estandarizada, no texto libre — y la instancia específica encontrada en tu sistema. Una categoría puede aparecer muchas veces; cada instancia necesita su propia ubicación.
En una evaluación de vulnerabilidades, ubicación significa la ruta del archivo o la URL del entorno, más la línea de código, el número de puerto o el campo de entrada exactos. Para código, nuestra plataforma también registra el hash del commit que introdujo el problema, el correo de su autor y la cantidad de días entre ese commit y el reporte. Esa última cifra es la que los equipos subestiman: es una medida directa de cuánto tiempo estuvo la debilidad en el repositorio antes de que alguien la viera.
La descripción pertenece a la debilidad, no a la instancia. Nuestra base de datos pública de vulnerabilidades la publica abiertamente, y cada entrada trae los mismos cinco campos: qué es la debilidad, su impacto, el actor de amenaza que asume, la recomendación para corregirla y un tiempo esperado de remediación en minutos. La debilidad 079, Non-upgradable dependencies, es un ejemplo llano: el impacto es la pérdida de mantenibilidad porque las dependencias no se mantienen, la amenaza es un atacante autenticado desde internet, la recomendación es declarar cada dependencia con un gestor de dependencias, y el tiempo esperado de remediación es de 120 minutos. Cada entrada también enlaza al requisito de seguridad que incumple, que es como un hallazgo se vuelve evidencia de cumplimiento en vez de un ejercicio aparte.
Debilidad 079 en nuestra base de datos abierta. Cada entrada trae los mismos cinco campos y enlaza al requisito de seguridad que incumple, así que cualquiera puede comprobar sobre qué está construida una evaluación de vulnerabilidades nuestra.
La severidad, y lo que el puntaje no dice
La severidad en una evaluación de vulnerabilidades debe ser un puntaje y su vector. El puntaje solo es una opinión; el vector es el razonamiento. Nuestra plataforma muestra la cadena del vector CVSS v4.0, el puntaje calculado con su calificación cualitativa y un desglose de cada métrica que lo produjo, para que quien lea pueda estar en desacuerdo con una métrica concreta y no con el número.
Las bandas cualitativas vale la pena enunciarlas con claridad, porque los equipos discuten sobre ellas más de lo que deberían: baja es 0,1 a 3,9; media, 4,0 a 6,9; alta, 7,0 a 8,9; y crítica, 9,0 a 10,0. Un reporte que solo te da la banda botó la parte que podías verificar.
La pestaña Severity en nuestra plataforma: el puntaje calculado, su calificación cualitativa y el vector que lo produjo, métrica por métrica. Una evaluación de vulnerabilidades que solo reporta la calificación esconde el razonamiento.
Campo | Qué responde | Por qué importa |
Debilidad y descripción | De qué clase de problema se trata | Agrupa instancias y las conecta con una corrección conocida |
Ubicación y línea, puerto o campo específico | Dónde está exactamente | Un hallazgo sin esto es un rumor |
Evidencia | Cómo sabemos que es real | Permite al desarrollador reproducirlo en vez de creerte |
Puntaje CVSS y vector | Qué tan grave podría ser, y con qué razonamiento | Hace auditable la severidad |
Prioridad | Qué corregir primero | Suma datos de explotación y contexto a la severidad |
Tiempo esperado de remediación | Cuánto debería costar corregirlo | Convierte un backlog en algo que puedes planear |
Tratamiento y responsable | Quién lo tiene a cargo y bajo qué decisión | Evita que los hallazgos queden sin dueño |
Registro de reattack | Si la corrección funcionó | Cierra el ciclo con prueba y no con un cambio de estado |
Requisito asociado | Qué estándar incumple | Convierte hallazgos en evidencia de cumplimiento |
Tratamiento: quién lo tiene a cargo, y hasta cuándo
Un hallazgo sin dueño no se corrige. Un reporte de evaluación de vulnerabilidades debe traer el tratamiento aplicado a cada vulnerabilidad, la persona asignada, la fecha en que se tomó esa decisión y, cuando el tratamiento es temporal, la fecha en que expira. Un riesgo aceptado sin vencimiento no es una decisión; es un hallazgo que se abandonó en silencio.
Lo mismo aplica a los falsos positivos. Nuestra plataforma trata un falso positivo como un tratamiento solicitado y registrado, no como un borrado silencioso, lo que mantiene el desacuerdo visible y revisable. Si tu reporte de evaluación de vulnerabilidades deja que los hallazgos desaparezcan sin rastro, no tienes forma de auditar los juicios que se hicieron en tu nombre.
Verificación: el registro de reattacks
El último campo es el que separa una evaluación de vulnerabilidades de una afirmación. Cada hallazgo debe mostrar el resultado de su reattack más reciente, la fecha en que se solicitó, quién lo solicitó, por cuántos ciclos de reattack ha pasado y la eficiencia de esos ciclos: la proporción que confirmó una corrección real.
Ciclos y eficiencia son el diagnóstico que nadie pide y todos necesitan. Una vulnerabilidad que pasó por cuatro reattacks con baja eficiencia no es un problema de remediación; es una señal de que el equipo está parchando un síntoma y la debilidad de fondo sigue ahí.
La evaluación de vulnerabilidades dentro de la gestión de vulnerabilidades
La evaluación de vulnerabilidades detecta y reporta; la gestión de vulnerabilidades decide qué se corrige primero, lo asigna, le hace seguimiento y lo verifica. Un enfoque basado en riesgo para esa segunda mitad es lo que mantiene el tiempo limitado de ingeniería apuntando a los hallazgos que importan.
Las dos mitades tienen que correr de forma continua, y por eso la evaluación de vulnerabilidades es un proceso y no un proyecto. Los sistemas cambian en cada merge, y aparecen debilidades nuevas en dependencias que no tocaste: nuestra base de datos rastrea más de 340.000 vulnerabilidades en 15 ecosistemas de código abierto. Las pruebas puntuales describen un sistema que ya no existe para cuando se lee el reporte, y por eso la evaluación de vulnerabilidades va dentro del pipeline de CI/CD, como prescribe DevSecOps, y no al lado.
Conclusiones
Trata la evaluación de vulnerabilidades como un problema de medición, no como un ejercicio de reporte. El método que elijas pone un techo a lo que puedes llegar a encontrar: en nuestros datos de 2025, la automatización produjo la mayor parte del volumen mientras que el 87 % de los hallazgos críticos vino de personas, y en nuestro benchmark la mejor herramienta automatizada alcanzó el 22,7 % de un conjunto conocido de vulnerabilidades contra el 89,6 % de un pentester. Elige un solo método y no habrás reducido el riesgo: habrás reducido tu visión de él.
Después juzga la evaluación de vulnerabilidades por sus campos, no por su número de páginas. Un hallazgo que trae su ubicación, su evidencia, su vector, su prioridad, su responsable y su historial de reattacks es uno sobre el que un desarrollador puede actuar esta semana. Una banda de severidad y un párrafo, no.
La consecuencia práctica de tratar así la evaluación de vulnerabilidades es una lista corta. Inventaría lo que tienes, corre ambos métodos sobre eso de forma continua, valida antes de escalar, prioriza con datos de explotación y no solo con severidad, y vuelve a probar cada corrección.
Preguntas frecuentes
¿La evaluación de vulnerabilidades es lo mismo que el escaneo de vulnerabilidades?
No. El escaneo de vulnerabilidades es un método dentro de una evaluación de vulnerabilidades. Una evaluación de vulnerabilidades es el proceso completo de hallar, clasificar y reportar debilidades, y puede combinar escaneo automatizado con pruebas manuales. Describir una evaluación como «correr un escáner» deja fuera la parte que encuentra los problemas complejos.
¿Cada cuánto debe hacerse una evaluación de vulnerabilidades?
De forma continua, no según un calendario. El código cambia en cada merge y aparecen vulnerabilidades nuevas en dependencias que nunca editaste, así que una evaluación anual o trimestral reporta sobre un sistema que ya cambió. En nuestros datos de 2025, los sistemas con una compuerta de CI alcanzaron una tasa de remediación del 72,2 % frente al 58 % de los que no la tenían.
¿Los escáneres automatizados pueden reemplazar a los pentesters?
Por ahora no. Entre los sistemas que Fluid Attacks evaluó en 2025, el 87 % de los hallazgos de severidad crítica se identificó mediante revisión manual, y las vulnerabilidades encontradas por pentesters promediaron 93,2 unidades CVSSF contra 15,5 de las encontradas por herramientas. Los escáneres aportan velocidad y cobertura; las personas encuentran las fallas lógicas y los ataques encadenados que ninguna firma describe.
¿Qué debe incluir un reporte de evaluación de vulnerabilidades?
Como mínimo: la debilidad, su ubicación exacta, la evidencia, un puntaje CVSS con su vector, una prioridad, un tiempo esperado de remediación, un responsable y un registro de verificación. Un reporte que da una banda de severidad sin el vector, o un hallazgo sin una ubicación reproducible, no se puede accionar ni auditar.
¿Una evaluación de vulnerabilidades ayuda con el cumplimiento de PCI DSS o ISO 27001?
Sí, cuando los hallazgos se mapean a requisitos. Estándares como PCI DSS, HIPAA, ISO 27001 y GDPR esperan que las debilidades se identifiquen y se corrijan. Un hallazgo que puede rastrearse hasta el requisito específico que incumple convierte un reporte de evaluación de vulnerabilidades en evidencia de cumplimiento en vez de un ejercicio aparte.
¿Fluid Attacks realiza evaluaciones de vulnerabilidades?
Sí. Combinamos IA y nuestros propios escáneres — SAST, AI SAST, SCA, DAST, MAST, CSPM, Secret Scanning — con Pentesting as a Service, Secure Code Review y Reverse Engineering. Cada hallazgo llega a nuestra plataforma con su evidencia, su severidad, su guía de remediación y un botón de reattack para verificar la corrección.
Evalúa lo que un atacante alcanzaría de verdad
Nuestros escáneres y pentesters ejecutan la evaluación de vulnerabilidades sobre tus sistemas a medida que cambian, para que los hallazgos que priorizas reflejen lo que es explotable hoy y no lo que un escaneo encontró el trimestre pasado. Prueba gratuita · Contáctanos.
