19. Pruebas automatizadas de seguridad: SAST, DAST, IaC scanning, secret scanning y policy as code

19.1 Introducción

La automatización es una pieza central de DevSecOps. Permite ejecutar controles de forma repetible en cada cambio, reducir dependencia de revisiones manuales y ofrecer feedback rápido a los equipos.

Sin embargo, automatizar no significa bloquear todo. Una estrategia madura define qué pruebas se ejecutan, en qué etapa, qué hallazgos bloquean, cómo se gestionan falsos positivos y cómo se corrigen las causas de fondo.

En este tema veremos las principales técnicas de pruebas automatizadas y cómo integrarlas sin generar ruido operativo.

19.2 Tipos de pruebas automatizadas

Cada técnica observa una parte distinta del sistema. Ninguna herramienta cubre todo.

19.3 SAST

SAST, Static Application Security Testing, analiza código sin ejecutarlo. Busca patrones que pueden indicar vulnerabilidades o malas prácticas.

Puede detectar:

• Inyecciones SQL o de comandos.
• Uso inseguro de criptografía.
• Validación insuficiente de entrada.
• Exposición de datos sensibles.
• Errores de autorización.
• Funciones peligrosas o APIs obsoletas.

19.4 DAST

DAST, Dynamic Application Security Testing, prueba una aplicación en ejecución desde fuera. No necesita ver el código; interactúa con endpoints, formularios y APIs.

Puede detectar:

• Errores de configuración HTTP.
• Cabeceras de seguridad ausentes.
• Exposición de endpoints sensibles.
• Problemas de autenticación o sesión visibles.
• Inyecciones detectables dinámicamente.
• Información sensible en respuestas.

DAST debe ejecutarse en ambientes controlados para evitar daño, ruido o pruebas contra producción sin autorización.

19.5 IaC scanning

IaC scanning analiza infraestructura como código antes de crear recursos. Permite detectar configuraciones inseguras temprano.

Ejemplos de hallazgos:

• Buckets públicos.
• Security groups con puertos administrativos abiertos a internet.
• Bases de datos sin cifrado.
• Logs de auditoría deshabilitados.
• Kubernetes pods privilegiados.
• Roles IAM con permisos comodín.
• Recursos sin etiquetas obligatorias.

19.6 Secret scanning

Secret scanning busca credenciales en código, historial Git, imágenes, logs y artefactos. Debe actuar rápido porque un secreto filtrado debe considerarse comprometido.

Buenas prácticas:

• Ejecutar escaneo antes del commit cuando sea posible.
• Bloquear pushes o merges con secretos reales.
• Escanear historial y repositorios existentes.
• Escanear imágenes y capas de contenedores.
• Notificar con instrucciones de revocación.
• Rotar automáticamente cuando la integración lo permita.

19.7 Policy as code

Policy as code define reglas de seguridad, cumplimiento y operación en archivos versionados. Permite validar cambios de forma automática y consistente.

19.8 Ubicación en el pipeline

La misma prueba puede tener distinto comportamiento según la etapa. En etapas tempranas conviene feedback rápido; cerca de producción conviene mayor rigor.

19.9 Gates razonables

Un gate debe bloquear riesgos claros, no todo hallazgo posible. Si los gates son arbitrarios, los equipos los perciben como ruido y pierden confianza.

Buenos candidatos para bloqueo:

• Secretos reales detectados.
• Vulnerabilidades críticas explotadas activamente.
• IaC que expone administración a internet.
• Imágenes sin firma para producción.
• Pods privilegiados sin excepción aprobada.
• Dependencias maliciosas o prohibidas.

19.10 Priorización de hallazgos

Los hallazgos deben priorizarse por impacto real y contexto. No todos los problemas de baja severidad son irrelevantes, ni todos los críticos son explotables en el entorno.

Factores de priorización:

• Exposición a internet.
• Datos sensibles procesados.
• Ambiente afectado.
• Exploit disponible o explotación activa.
• Privilegios del componente afectado.
• Facilidad de remediación.
• Controles compensatorios existentes.

19.11 Gestión de falsos positivos

Los falsos positivos son inevitables. El objetivo es gestionarlos sin apagar controles útiles.

Buenas prácticas:

• Permitir supresiones justificadas y versionadas.
• Exigir motivo, dueño y vencimiento para supresiones relevantes.
• Ajustar reglas ruidosas.
• Separar hallazgos informativos de bloqueantes.
• Revisar periódicamente supresiones antiguas.
• Medir reincidencia y calidad de reglas.

19.12 Reportes accionables

Un reporte de seguridad debe ayudar a corregir. Si solo lista problemas sin contexto, genera fricción.

Debe incluir:

• Ubicación exacta del hallazgo.
• Impacto y severidad contextual.
• Recomendación concreta.
• Referencia a política o regla incumplida.
• Ejemplo de corrección si aplica.
• Estado: bloqueante, advertencia o informativo.
• Ruta para excepción.

19.13 Pruebas en ambientes efímeros

Los ambientes efímeros permiten desplegar una versión temporal para pruebas de seguridad y funcionales. Son útiles para DAST, validación de configuración y pruebas de integración.

Controles necesarios:

• Datos sintéticos o anonimizados.
• Secretos separados de producción.
• Acceso restringido y tiempo de vida limitado.
• Limpieza automática de recursos.
• Costos y cuotas controladas.
• Logs suficientes para analizar resultados.

19.14 Métricas de pruebas automatizadas

Las métricas deben medir mejora, no solo actividad.

• Cobertura de repositorios con SAST, SCA, IaC y secret scanning.
• Tiempo de feedback en pull requests.
• Hallazgos críticos bloqueados antes de producción.
• Tiempo medio de remediación.
• Falsos positivos por herramienta o regla.
• Supresiones vencidas.
• Reincidencia por causa raíz.

19.15 Errores frecuentes

• Ejecutar herramientas sin definir política de bloqueo.
• Usar el mismo umbral para desarrollo y producción.
• No dar feedback claro a desarrolladores.
• Ignorar falsos positivos hasta que todos ignoran la herramienta.
• Ejecutar DAST contra producción sin control.
• No escanear infraestructura como código.
• Guardar supresiones permanentes sin revisión.
• Medir éxito por cantidad de hallazgos en lugar de reducción de riesgo.

19.16 Lista de verificación

• ¿SAST, SCA, IaC scanning y secret scanning corren en pull requests?
• ¿DAST se ejecuta en ambientes controlados?
• ¿Los gates bloquean solo riesgos definidos y justificables?
• ¿Los reportes explican cómo corregir?
• ¿Las supresiones tienen dueño, motivo y vencimiento?
• ¿Policy as code se versiona y prueba antes de bloquear?
• ¿Las métricas miden remediación, cobertura y ruido?
• ¿Los hallazgos alimentan mejoras en plantillas, patrones y capacitación?

19.17 Qué debes recordar de este tema

• Cada técnica detecta una clase distinta de problema.
• La etapa del pipeline define si una prueba debe informar, advertir o bloquear.
• Los gates deben ser defendibles y accionables.
• Policy as code permite aplicar reglas de forma consistente.
• La gestión del ruido es parte esencial de la automatización.

19.18 Conclusión

Las pruebas automatizadas de seguridad permiten escalar DevSecOps si están bien ubicadas, priorizadas y conectadas con remediación. El objetivo no es encontrar todo, sino detectar temprano lo importante y mejorar el flujo de entrega.

En el próximo tema estudiaremos infraestructura como código segura: Terraform, plantillas, revisión, módulos y guardrails.