Introducción
Tu aplicación tiene vulnerabilidades. La pregunta no es si existen — es quién las encuentra primero: tu equipo de QA o alguien externo no autorizado.
El costo promedio de una brecha de datos fue de 4,45 millones de dólares en 2024 (IBM Cost of a Data Breach Report). Las vulnerabilidades de software son la causa principal. La mayoría de esas vulnerabilidades son detectables con testing de seguridad antes del lanzamiento.
¿Qué son las pruebas de seguridad de software?
Las pruebas de seguridad de software (application security testing) son el proceso de verificar que una aplicación no tiene vulnerabilidades que puedan ser explotadas por un atacante. No son lo mismo que el testing funcional ni el de rendimiento — tienen metodologías, herramientas y criterios de aceptación distintos.
El marco de referencia más usado para organizar las pruebas de seguridad es el OWASP Top 10 — la lista de las vulnerabilidades web más críticas y frecuentes, actualizada periódicamente por la Open Web Application Security Project. Las categorías incluyen inyección SQL, configuración insegura, autenticación defectuosa, exposición de datos sensibles y otros tipos de vulnerabilidades con alta prevalencia en aplicaciones reales.
¿Cuáles son los tipos principales de testing de seguridad?
DAST — Dynamic Application Security Testing
Pruebas de caja negra: el tester (o la herramienta) interactúa con la aplicación en ejecución sin acceso al código fuente, buscando vulnerabilidades explotables desde el exterior. Simula el punto de vista de un atacante real. No requiere acceso al código — solo a la aplicación funcionando.
SAST — Static Application Security Testing
Análisis estático del código fuente sin ejecutar la aplicación. Identifica vulnerabilidades de seguridad en el código antes de que la aplicación esté desplegada. Detecta problemas como inyección SQL en el código, uso inseguro de funciones criptográficas, o manejo incorrecto de variables de entorno.
IAST — Interactive Application Security Testing
Combina DAST y SAST: analiza la aplicación mientras se ejecuta, con instrumentación dentro del código. Más preciso que ambos por separado, requiere más configuración.
Análisis de composición de software (SCA)
Verifica las dependencias y librerías de terceros que usa el proyecto en busca de vulnerabilidades conocidas. Muchas brechas de seguridad no vienen del código propio sino de dependencias desactualizadas con vulnerabilidades publicadas.
Pentesting (pruebas de penetración)
Un profesional de seguridad intenta comprometer la aplicación usando técnicas reales de ataque, con autorización explícita. Más profundo que el testing automatizado — detecta vulnerabilidades que requieren creatividad y encadenamiento de técnicas para explotar.
¿Cuándo son críticas las pruebas de seguridad?
Hay situaciones donde el testing de seguridad no es opcional:
- Antes de cualquier lanzamiento que maneje datos personales, financieros o de salud — donde una brecha tiene consecuencias regulatorias y de responsabilidad
- Antes de integraciones con sistemas de terceros que van a compartir datos o credenciales
- Después de cambios arquitectónicos mayores — un cambio de base de datos, una migración a la nube, un rediseño de la autenticación
- Al menos una vez al año para sistemas en producción activa, independientemente de si hubo cambios
- Cuando el sistema va a procesar datos bajo regulaciones específicas (GDPR en Europa, LGPD en Brasil, regulaciones sectoriales de banca o salud)
¿Qué vulnerabilidades buscan las pruebas de seguridad?
Las vulnerabilidades más frecuentes según OWASP Top 10 (versión más reciente):
- Inyección: código malicioso insertado en inputs del sistema (SQL injection, command injection, LDAP injection)
- Fallos de autenticación: sesiones mal gestionadas, contraseñas débiles por defecto, tokens predecibles
- Exposición de datos sensibles: datos en texto plano, cifrado débil, datos personales no protegidos en tránsito o en reposo
- Vulnerabilidades en componentes: dependencias desactualizadas con vulnerabilidades conocidas y publicadas
- Configuraciones inseguras: credenciales por defecto, puertos abiertos innecesarios, mensajes de error que exponen información del sistema
- Control de acceso roto: un usuario puede acceder a datos o funciones de otro usuario, o escalar privilegios no autorizados
¿Qué pasa si se encuentran vulnerabilidades?
El resultado de un proceso de testing de seguridad bien ejecutado no es alarmante — es accionable. Las vulnerabilidades se documentan con:
- Nivel de criticidad: crítica, alta, media o baja, según el impacto potencial y la facilidad de explotación
- Descripción técnica: qué es la vulnerabilidad y cómo funciona
- Evidencia: cómo se reprodujo (proof of concept, si aplica)
- Recomendación de corrección: qué cambio en el código o la configuración resuelve el problema
El equipo técnico implementa las correcciones priorizadas por criticidad. Un segundo ciclo de testing verifica que las correcciones son efectivas y no introdujeron nuevas vulnerabilidades.
¿Cómo integrar seguridad en el ciclo de vida del software?
El concepto de DevSecOps (ver /recursos/ciclo-de-vida-del-software/) integra el testing de seguridad en el pipeline CI/CD, en lugar de dejarlo para el final del ciclo:
- SAST en el pipeline: el análisis estático corre automáticamente en cada commit o pull request
- SCA en el pipeline: las dependencias se verifican automáticamente en busca de vulnerabilidades conocidas
- DAST periódico: las pruebas dinámicas se corren en el entorno de staging antes de cada release mayor
- Pentesting anual: revisión manual por un profesional de seguridad con metodología de caja negra
Este enfoque — llamado 'security by design' — es más eficiente que el testing de seguridad puntual porque detecta vulnerabilidades donde cuestan menos corregir: en el código, no en producción.