Estimados amigos de Inseguros !!!
Seguimos con el control 7 de los CIS, gestión continua de vulnerabilidades, y hoy toca el 7.4: realizar análisis automatizados de vulnerabilidades en aplicaciones. Y aquí es donde mucha gente se da cuenta de que llevaba años haciendo “gestión de vulnerabilidades”… pero solo de infraestructura.
Porque una cosa es escanear servidores, endpoints y servicios (7.3).
Y otra muy distinta es mirar las aplicaciones: lo que tú desarrollas, lo que tú despliegas, lo que tú publicas, y lo que procesa datos de verdad.
Y te lo digo claro: hoy la mayoría de incidentes serios entran por identidad, por correo… o por aplicaciones. Portales, APIs, paneles de administración, integraciones, SaaS, formularios, servicios web. Si tienes app, tienes superficie de ataque. Y si no la escaneas, estás volando a ciegas.
Qué significa “automatizado” en aplicaciones
Significa que no vale con hacer un pentest al año y olvidarte.
Eso está bien, pero no es suficiente.
Aquí hablamos de meter seguridad en el ciclo de vida.
Cada vez que se despliega, se analiza.
Cada vez que cambias dependencias, se analiza.
Cada vez que sacas una nueva versión, se analiza.
Y esto, en la práctica, se hace con varias capas.
SAST, DAST y dependencias
SAST: análisis estático del código (busca patrones peligrosos en el código fuente).
DAST: análisis dinámico, atacando la aplicación en ejecución (tipo escáner web).
SCA: análisis de dependencias y librerías (lo que se lleva puesto tu código).
No hace falta que te vuelvas loco con siglas, pero sí con el concepto: una app no es solo “el código que escribiste”, también son sus librerías, sus frameworks, sus containers, sus imágenes, su configuración, su pipeline y su despliegue.
Y por eso vuelve a salir el concepto SBOM, que ya lo mencionábamos antes. Si tú no sabes qué librerías tienes, no sabes dónde te afecta una vulnerabilidad cuando salga el próximo “gran CVE” del mes.
Qué vulnerabilidades buscas aquí
Las típicas de aplicaciones: inyecciones, XSS, SSRF, control de acceso roto, exposición de secretos, configuraciones inseguras, headers, CORS mal, autenticación floja, errores de autorización, APIs sin control, etc.
Pero lo bonito del 7.4 es que no se queda en “me salió un finding”.
Se queda en “lo detecto temprano”.
Y detectar temprano es barato.
Detectar tarde es caro.
Y detectarlo cuando ya estás comprometido… eso ya no tiene precio.
Cómo se aterriza en empresa
Esto, si lo quieres hacer bien, va conectado al pipeline (CI/CD).
Cada commit o cada build pasa por controles.
Si algo crítico salta, bloqueas el despliegue o al menos lo marcas para revisión.
Y para lo que ya está en producción, también: escaneo recurrente de tus apps y APIs publicadas. Porque hay cambios que no vienen del código: vienen de configuraciones, de infraestructura, de librerías actualizadas por debajo, de cambios en WAF, de nuevos endpoints, etc.
Una organización madura combina:
escaneo automatizado continuo + revisiones manuales + pentest periódico.
No es una cosa u otra. Es conjunto.
Si estás montando un programa de gestión de vulnerabilidades y quieres que sea completo, el 7.4 es obligatorio. Y si quieres aprender a aplicarlo con ejemplos reales (DAST/SAST/SCA, SBOM, pipelines, escaneo de APIs y cómo integrar todo esto con remediación), pásate por www.seguridadsi.com y mira los cursos de ciberseguridad online para profesionales que tenemos en la academia.
Gracias por leerme !!!
