Las pruebas de seguridad son la práctica de evaluar un sistema —código fuente, una aplicación en ejecución o la infraestructura que la sostiene— para encontrar las debilidades que un atacante podría explotar, y para confirmar que su diseño y su configuración protegen la disponibilidad, la confidencialidad y la integridad de los datos.
Lo que las hace valer la pena es la distancia entre lo que un escáner reporta y lo que de verdad rompe un sistema: en el benchmark de herramientas de Fluid Attacks, un pentester encontró 743 de las 1.201 vulnerabilidades presentes en la aplicación evaluada que ninguna herramienta automatizada del estudio detectó. Esas 743 concentraban el 86,8% de la exposición al riesgo total de esa aplicación.
Esta página cubre qué son estas evaluaciones, qué buscan, los tipos y técnicas que existen, las herramientas involucradas y cómo montar un programa que reduzca el riesgo de forma medible.
¿Qué son las pruebas de seguridad?
Las pruebas de seguridad evalúan si un sistema se comporta de forma segura bajo condiciones que sus diseñadores no previeron. Una prueba funcional pregunta si una función sirve. Una evaluación de seguridad pregunta qué pasa cuando alguien la usa mal a propósito: enviando entradas malformadas, saltándose un paso de un flujo, reutilizando un token o encadenando dos comportamientos inofensivos en un resultado peligroso.
El objeto evaluado —el objetivo de evaluación, o ToE— puede ser código fuente, una aplicación desplegada, una API, un binario móvil, una red o un entorno en la nube. La salida es un conjunto de vulnerabilidades, cada una con su severidad, su ubicación y evidencia suficiente para que un desarrollador la reproduzca y la corrija.
Las pruebas de seguridad no son una sola actividad. Abarcan el escaneo automatizado, rápido y amplio, y el trabajo manual de hackers éticos, más lento y más profundo. La mayoría de los programas necesitan ambos, por razones que las cifras de esta página hacen concretas.
Objetivos principales de las pruebas de seguridad
Una buena evaluación cumple cuatro objetivos a la vez:
Encontrar debilidades explotables antes que un atacante: no todo defecto es un riesgo, y no todo riesgo merece la misma atención. El punto es sacar a la luz las que un adversario podría abusar de verdad.
Medir la exposición al riesgo, no solo contar vulnerabilidades: diez problemas de severidad baja no equivalen a uno crítico. Fluid Attacks usa CVSSF, una métrica derivada del CVSS (CVSSF = 4 ^ (CVSS − 4)), de modo que una vulnerabilidad crítica vale 4.096 unidades mientras que diez menores suman 0,2.
Darles a los equipos de desarrollo algo accionable: un hallazgo sin una ruta reproducible y sin una vía de remediación es ruido.
Apoyar el cumplimiento sin convertirlo en el objetivo: estándares como PCI DSS, HIPAA e ISO 27001 exigen pruebas de seguridad, pero pasar una auditoría y ser difícil de atacar son logros distintos.
¿Por qué son importantes las pruebas de seguridad?
Porque la explotación de vulnerabilidades ya es la vía de entrada más común. Según el Data Breach Investigations Report 2026 de Verizon, "casi un tercio (31 %) de todas las brechas empieza con la explotación de una vulnerabilidad" — la primera vez en 19 años que supera a las credenciales robadas como principal punto de entrada.
El lado del costo está igual de documentado. La investigación anual de IBM sobre el impacto financiero de las brechas ubica la brecha promedio en millones de dólares, antes de contar sanciones regulatorias, pérdida de clientes y el tiempo de ingeniería desviado a la respuesta a incidentes. Una vulnerabilidad encontrada durante el desarrollo cuesta una fracción de esa misma vulnerabilidad encontrada por un atacante.
Hay además un efecto acumulativo. Los sistemas cambian todo el tiempo, y cada cambio puede introducir una debilidad que el mes pasado no existía. Una sola evaluación anual produce una foto que queda desactualizada en semanas. Realizar pruebas de seguridad continuamente mantiene el panorama al día a medida que el código evoluciona.
Caso de estudio: Lecciones costosas sobre el poder de las pruebas de seguridad
En 2023, el equipo de investigación en IA de Microsoft expuso por accidente 38 TB de datos internos —incluidas claves privadas, contraseñas y mensajes internos— a través de un token SAS de Azure con permisos excesivos, publicado junto a un repositorio público de GitHub.
La mala configuración detrás de esa fuga no fue un zero-day exótico. Fue un error de permisos que una revisión de la configuración en la nube habría detectado, y estuvo a la vista durante casi tres años antes de que unos investigadores lo reportaran.
Marriott International, una de las principales cadenas hoteleras, lamentablemente fue blanco de dos grandes brechas de datos, en 2014 y en 2020, que expusieron la información personal de millones de huéspedes.
Estudio de caso: filtraciones de datos de Marriott International
Esa es la forma que tiene la mayoría de los incidentes reales: no un exploit novedoso, sino un error ordinario que nadie buscó.
Las pruebas de seguridad en Fluid Attacks
Qué evaluamos y bajo qué reglas
Fluid Attacks evalúa únicamente sistemas para los que ha sido autorizada de forma explícita, dentro de un alcance acordado con el cliente antes de empezar cualquier trabajo. Toda técnica descrita más abajo en esta página —del análisis estático a la explotación manual— corre dentro de ese acuerdo. El hacking ético sin autorización no es una prueba de seguridad; es un ataque.
El trabajo se entrega como una solución todo en uno con dos planes. El plan Essential corre el lado automatizado: nuestros propios motores de SAST, AI SAST, DAST, SCA, escaneo de secretos y CSPM. El plan Advanced suma a nuestros pentesters, que tienen 63 certificaciones en seguridad ofensiva en web, móvil, nube, red teaming y desarrollo de exploits, y que ejecutan pruebas de penetración manuales, revisión de código seguro e ingeniería inversa contra el mismo objetivo.
Qué muestran nuestras propias cifras
La razón por la que insistimos en combinar ambos es que medimos la diferencia sobre una misma aplicación.
En nuestro benchmark de herramientas pusimos a competir 36 herramientas de terceros de SAST, DAST y SCA —varias de ellas en el Cuadrante Mágico de Gartner— más nuestro propio escáner y uno de nuestros pentesters contra el mismo objetivo: 1.201 vulnerabilidades conocidas en 105 categorías CWE, equivalentes a 461.500 unidades CVSSF, con el 73,2 % de ellas detrás de autenticación.
Evaluador | Verdaderos positivos | Falsos positivos | Precisión | Exhaustividad | Exhaustividad (CVSSF) |
Pentester de Fluid Attacks (manual) | 1.076 | 0 | 100 % | 89,6 % | 98,9 % |
Escáner de Fluid Attacks (automatizado) | 273 | 3 | 99 % | 22,7 % | 8,8 % |
Mejor herramienta de terceros del estudio | 260 | 102 | 72 % | 21,6 % | 4,0 % |
Promedio de las otras 34 herramientas | — | — | — | 1,7 % | — |
Dos hallazgos destacan. Primero, 17 de las 36 herramientas de terceros no lograron identificar ni diez vulnerabilidades de las 1.201 presentes. Segundo, 743 vulnerabilidades —el 61,9 % del total y el 86,8 % de la exposición al riesgo— fueron detectadas exclusivamente por el pentester.
El patrón se sostuvo años después contra datos frescos. Nuestro reporte State of Attacks 2026, que cubre las evaluaciones del 1 de enero al 31 de diciembre de 2025, encontró que nuestras herramientas detectaron el 55,8 % de la exposición al riesgo total, mientras que las pruebas de seguridad manuales detectaron, en promedio, cinco veces más exposición al riesgo por hallazgo. Los pentesters dieron cuenta del 90 % de la exposición al riesgo proveniente de vulnerabilidades de severidad crítica.
De dónde viene esa experiencia
Los benchmarks miden a un equipo sobre una aplicación. Las competencias lo miden contra todos los demás. En el Hack The Box Business CTF de 2025 —el Global Cyber Skills Benchmark, una competencia de cuatro días que abarca hacking web, criptografía, ingeniería inversa, nube y compromiso total de redes— nuestro equipo de hacking quedó #1 en Latinoamérica y #9 a nivel mundial, resolviendo 59 de 66 retos con 14 jugadores frente a los cerca de 30 que alineó cada equipo del top cinco.
Ese resultado es el final de una progresión, no un golpe de suerte. Simon Correa, Head of Research de Fluid Attacks, lo documentó en su recuento de cómo el equipo llegó al top 10:
"En 2021, la primera edición de la competencia, quedamos #80 a nivel mundial. En 2024 subimos 45 puestos hasta el #35. Y en 2025 saltamos otras 26 posiciones para terminar #9 a nivel mundial." Simon Correa, Head of Research, Fluid Attacks, enero de 2026.
Las mismas personas ejecutan las evaluaciones descritas en esta página.
Del hallazgo a la corrección
Encontrar problemas es apenas la mitad del trabajo. En el conjunto de datos de 2025, la tasa general de remediación llegó al 62,2 % al cierre del año —21,2 puntos porcentuales más que en 2024— y los problemas de severidad crítica tuvieron la mejor tasa acumulada, con 63,8 %. Los sistemas que usaron nuestro CI Gate, que rompe la compilación cuando se cruza un umbral de política, alcanzaron una tasa de remediación del 72 % frente al 58 % de los que no lo usaron, y cerraron los problemas un 27 % más rápido.
Las fases descritas más adelante en esta página no son teóricas para nosotros. Cada hallazgo se reporta en nuestra plataforma con su evidencia y su valor CVSSF, mapeado contra nuestro propio catálogo de 384 debilidades de software, 182 requisitos de seguridad y 1.937 guías de remediación. Cuando un equipo cree haber corregido algo, solicita un reattack y uno de nuestros pentesters lo verifica contra el sistema vivo.
▶️ Video: Michael Rivera, Chief Data & AI Officer de Fluid Attacks, recorre el conjunto completo de datos de 2025 —tasas de remediación, el reparto entre manual y automatizado, y el efecto del CI Gate— en nuestro webinar del State of Attacks 2026 (36 minutos, en español).
Principios clave de las pruebas de seguridad
Cinco principios separan una evaluación que reduce el riesgo de una que produce un documento:
Confidencialidad, integridad y disponibilidad: todo hallazgo debería poder rastrearse hasta cuál de estas tres propiedades amenaza.
Autenticación y autorización: la mayoría de los hallazgos serios vive detrás de un inicio de sesión. En nuestro benchmark, el 73,2 % de las vulnerabilidades del objetivo requerían autenticación para ser alcanzadas — por eso los escaneos sin autenticar subreportan de forma sistemática.
No repudio: las acciones deben ser atribuibles, y los registros deben sobrevivir a un atacante que quiera borrarlos.
Mínimo privilegio: prueba si una cuenta comprometida de bajo privilegio puede llegar a datos que no le corresponden.
Defensa en profundidad: que falle un solo control no debería ser el final de la historia.
Tipos de pruebas de seguridad
El tipo lo define qué estás evaluando, no cómo.
Pruebas de seguridad de aplicaciones web
Los sistemas web son la superficie más expuesta que tienen la mayoría de las organizaciones. Las evaluaciones aquí combinan escáneres web con trabajo manual contra las categorías del OWASP Top 10: control de acceso roto, inyección, fallas criptográficas y las demás. Las fallas de lógica de negocio —un carrito que acepta cantidades negativas, un restablecimiento de contraseña que revela si una cuenta existe— son casi invisibles para los escáneres y rutinarias para un pentester. Mira cómo puedes proteger tus aplicaciones web.
Pruebas de seguridad de aplicaciones móviles
Las pruebas de aplicaciones móviles inspeccionan la aplicación compilada, su almacenamiento local, su manejo de certificados y las APIs con las que habla. Claves incrustadas en el código, bases de datos locales sin cifrar y certificate pinning deshabilitado son los hallazgos recurrentes. Como el binario llega al dispositivo del propio atacante, la revisión manual importa aquí más que en casi cualquier otra parte. Mira cómo puedes proteger tus aplicaciones móviles.
Pruebas de seguridad de redes
Las evaluaciones de red mapean hosts y servicios expuestos, revisan la segmentación y buscan servicios desactualizados y protocolos débiles. La pregunta no es solo qué es alcanzable desde internet, sino a qué puede llegar un atacante después de aterrizar en un único host interno.
Pruebas de APIs
Las APIs concentran lógica de negocio con muy poca interfaz que la limite. La autorización rota a nivel de objeto —cambiar un ID en una petición y obtener los datos de otra persona— sigue siendo el hallazgo serio más común. Limitación de tasa, validación de esquemas y manejo de tokens completan la lista. Mira cómo puedes proteger tus APIs.
Pruebas de seguridad de infraestructura en la nube
Las evaluaciones en la nube revisan políticas de identidad, permisos de almacenamiento, reglas de red y gestión de secretos contra el modelo de responsabilidad compartida del proveedor. El caso de Microsoft de arriba es el ejemplo canónico de lo que sale mal aquí.
Otros términos relacionados con las pruebas de seguridad
Estos términos se usan de forma intercambiable. No son lo mismo.
Evaluación de riesgos de ciberseguridad
Una evaluación de riesgos es un ejercicio de gestión: identifica activos, estima la probabilidad y el impacto de las amenazas contra ellos y fija prioridades. Informa dónde probar. No encuentra vulnerabilidades.
Auditoría de seguridad
Una auditoría verifica la conformidad contra un estándar o una política. Responde "¿cumplimos?" — una evaluación técnica responde "¿esto se puede romper?". Las dos importan, y pasar una no implica pasar la otra.
Evaluación de la postura de seguridad
Una evaluación de postura mira a toda la organización: herramientas, procesos, personas y las brechas entre ellos. Es más amplia y más superficial que una evaluación técnica de un solo sistema.
Escaneo de vulnerabilidades
El escaneo de vulnerabilidades es la detección automatizada de problemas conocidos contra firmas y reglas. Es un componente de una evaluación de vulnerabilidades, y un componente de unas pruebas de seguridad completas — no un sustituto de ninguna de las dos. La tabla del benchmark de arriba es la declaración más clara de lo que cubre y lo que no.
Hacking ético
El hacking ético es la simulación autorizada de ataques reales. Un hacker ético trabaja con la misma mentalidad y buena parte del mismo instrumental que un adversario, bajo un contrato que define el alcance y las reglas de enfrentamiento. El pentesting, el red teaming y la ingeniería social están todos dentro de él — y las distinciones entre ellos las hemos abordado antes en este blog.
Técnicas de pruebas de seguridad
La técnica la define cómo pruebas.
SAST: el análisis estático lee código fuente, bytecode o binarios sin ejecutarlos. Detecta patrones inseguros temprano y se integra limpiamente en un pipeline, a costa de falsos positivos y de no ver el comportamiento en tiempo de ejecución. Elegir una herramienta SAST es sobre todo una cuestión de cobertura de lenguajes y de ruido.
DAST: el análisis dinámico ataca la aplicación en ejecución desde afuera. Ve lo que el sistema desplegado hace de verdad, incluidos problemas de configuración e integración, pero solo alcanza lo que puede rastrear.
SCA: el análisis de composición de software inventaría dependencias de terceros y señala versiones vulnerables conocidas. Las buenas herramientas de SCA además te dicen si el código vulnerable es realmente alcanzable desde tu aplicación.
CSPM: la gestión de la postura de seguridad en la nube revisa continuamente la configuración de la nube contra líneas base seguras.
MPT: la prueba de penetración manual es un humano atacando el sistema con un objetivo. Es de donde salen las fallas de lógica de negocio, los exploits encadenados y las brechas de autorización, y donde se encuentra la exposición al riesgo que las herramientas no ven.
SCR: la revisión de código seguro es un humano leyendo el código, normalmente guiado por la salida de las herramientas, para juzgar lo que la herramienta no pudo.
RE: la ingeniería inversa de software desarma artefactos compilados para entender comportamientos que el código fuente no revela — esencial para aplicaciones móviles y binarios de terceros.
Herramientas de pruebas de seguridad
Las herramientas aportan la amplitud. Los escáneres de Fluid Attacks cubren SAST, SCA y DAST, y están recomendados bajo el Cloud Application Security Assessment de la App Defense Alliance para escaneo estático y recomendados por CASA para escaneo dinámico. En el OWASP Benchmark, nuestro motor estático obtuvo un 100 % en verdaderos positivos y un 0 % en falsos positivos.
Si estás evaluando opciones de código abierto, el estado de mantenimiento es la señal que más importa — y cómo hacerles benchmark correctamente merece su propio proceso. Algunos ejemplos, con su situación en el programa OpenSSF Best Practices:
Horusec tiene una insignia de aprobación en las buenas prácticas de OpenSSF.
SpotBugs aún no ha obtenido la insignia de aprobación, y un estudio del 2021 midió cuánto de lo que reporta es accionable.
Flawfinder tiene una insignia de aprobación en las buenas prácticas de OpenSSF.
Railroader tiene una insignia de aprobación en las buenas prácticas de OpenSSF.
OWASP Zed Attack Proxy es el escáner de vulnerabilidades de aplicaciones web de código abierto más usado, y vale la pena revisar los listados de insignias equivalentes antes de adoptar cualquiera de estas. Para móvil, el proyecto OWASP MASTG las ha recopilado aquí.
Nada de esto reemplaza el criterio. El benchmark de arriba midió 36 de estas herramientas contra una aplicación; 34 de ellas promediaron un 1,7 % de exhaustividad.
El impacto de los falsos positivos y los falsos negativos en las pruebas de seguridad
Un falso positivo es una alerta sin nada detrás. Un falso negativo es una vulnerabilidad real que nadie reportó. Los dos son caros, de formas distintas.
Los falsos positivos consumen el recurso más difícil de recuperar: la confianza de los desarrolladores. Un equipo que se gasta un sprint persiguiendo hallazgos fantasma empieza a ignorar advertencias legítimas en el futuro. En el benchmark, la mejor herramienta de terceros produjo 102 falsos positivos contra 260 verdaderos —una precisión del 72 %—, mientras que otras seis herramientas promediaron unos 130 falsos positivos cada una. Nuestro pentester produjo cero.
Los falsos negativos son peores y más silenciosos. Nadie los nota hasta que lo hace un atacante. Aquí es donde el 8,8 % de exhaustividad en CVSSF del mejor motor automatizado se vuelve la cifra para recordar: un reporte de escaneo limpio no es lo mismo que una aplicación segura.
Cómo hacer pruebas de seguridad
Sea cual sea el alcance, la secuencia es la misma:
Define el alcance y las reglas de enfrentamiento. Qué sistemas, qué entornos, qué técnicas se permiten, a quién contactar si algo se rompe. Ponlo por escrito.
Mapea la superficie de ataque. Enumera endpoints, servicios, dependencias y puntos de entrada. No puedes probar lo que no has encontrado.
Corre el análisis automatizado. SAST y SCA en el pipeline en cada commit, DAST y CSPM contra entornos desplegados de forma programada. Esta es la capa barata y amplia.
Suma trabajo manual donde rinde. Flujos autenticados, lógica de negocio, límites de autorización, todo lo que maneje dinero o datos personales. Esta es la capa que encuentra los problemas críticos.
Prioriza por riesgo, no por conteo. Usa una métrica de severidad que refleje el impacto real, y corrige primero lo de arriba de la lista.
Corrige y verifica. Un hallazgo no está cerrado hasta que alguien confirmó la corrección contra el sistema vivo.
Repite a medida que el sistema cambia. Idealmente en cada commit, no una vez al año.
Incrustar las pruebas de seguridad en una metodología DevSecOps es lo que las convierte de un proyecto en una práctica, y qué técnicas utilizar en cada etapa es la decisión que determina si funciona.
El Secure Software Development Framework del NIST (SP 800-218, versión 1.1, publicado en febrero de 2022) formaliza la misma idea: revisar el código legible por humanos y probar el código ejecutable son prácticas distintas y ambas obligatorias — no alternativas.
Conclusiones
Las pruebas de seguridad son la forma en que una organización se entera de lo que un atacante se enteraría, en sus propios términos y en su propio calendario. La evidencia es consistente sobre lo que eso requiere. El DBIR 2026 de Verizon ubica la explotación de vulnerabilidades en el 31 % de las brechas, por delante de las credenciales robadas por primera vez en 19 años. Nuestro propio benchmark encontró el 61,9 % de las vulnerabilidades de una aplicación —y el 86,8 % de su exposición al riesgo— únicamente mediante trabajo manual. Nuestros datos de 2025 encontraron a los pentesters responsables del 90 % de la exposición al riesgo de las vulnerabilidades críticas.
La automatización no es opcional: nada más te da cobertura en cada commit. Pero un programa construido solo sobre escaneo está midiendo la parte del problema que es fácil de medir. Combina ambos, córrelos continuamente y verifica las correcciones.
Preguntas frecuentes
¿Cuál es la diferencia entre unas pruebas de seguridad y una auditoría de seguridad?
Las pruebas de seguridad buscan vulnerabilidades explotables en un sistema. Una auditoría verifica si la organización cumple con un estándar o una política — sus procesos, su documentación y sus controles. Una organización puede pasar una auditoría y seguir siendo trivialmente explotable.
¿Cada cuánto se deben hacer pruebas de seguridad?
De forma continua, integradas al pipeline de CI/CD, en lugar de una vez al año antes de una auditoría. Los sistemas cambian en cada commit, y una evaluación puntual queda desactualizada en semanas. En nuestros datos de 2025, los equipos que usaron nuestro CI Gate alcanzaron una tasa de remediación del 72 % frente al 58 % de los equipos que no lo usaron.
¿Son suficientes las pruebas de seguridad automatizadas por sí solas?
No. En el benchmark de Fluid Attacks de 36 herramientas de terceros contra una aplicación con 1.201 vulnerabilidades conocidas, el mejor motor automatizado alcanzó un 22,7 % de exhaustividad y cubrió el 8,8 % de la exposición al riesgo, mientras que un pentester alcanzó un 89,6 % de exhaustividad y el 98,9 % de la exposición al riesgo. La automatización te da amplitud; los evaluadores humanos encuentran los problemas críticos.
¿Fluid Attacks usa herramientas automatizadas, pruebas manuales o ambas?
Ambas, sobre el mismo objetivo. Nuestro plan Essential corre nuestros motores de AI SAST, SAST, SCA, DAST, escaneo de secretos y CSPM. Nuestro plan Advanced suma pentesters que ejecutan pruebas de penetración manuales, revisión de código seguro e ingeniería inversa, y permite a los equipos solicitar reattacks para verificar que una corrección funcionó de verdad.
¿Qué tipo de pruebas de seguridad encuentra más vulnerabilidades críticas?
Las manuales. En nuestro reporte State of Attacks 2026, que cubre todas las evaluaciones ejecutadas en 2025, los pentesters dieron cuenta del 90 % de la exposición al riesgo proveniente de vulnerabilidades de severidad crítica, y el trabajo manual detectó en promedio cinco veces más exposición al riesgo por hallazgo que nuestras herramientas automatizadas.
¿Cuánto cuestan unas pruebas de seguridad?
Depende del alcance —una aplicación frente a todo un parque tecnológico—, de qué técnicas se incluyan y de si es un trabajo puntual o un programa continuo. Los programas continuos cuestan más al año y encuentran mucho más, porque evalúan el sistema a medida que cambia en vez de una sola vez.
Mira lo que tu escáner no ve
En nuestro benchmark, el mejor escáner encontró el 22,7 % de las vulnerabilidades y nuestros pentesters el 89,6 %. Prueba con los dos. Prueba gratuita · Contáctanos.
