Introducción
Un CVE publicado el lunes puede convertirse en un exploit funcional el martes. No es una exageración: modelos de IA generativa han reducido el tiempo de desarrollo de exploits de días a menos de 12 horas en casos documentados. Mientras tanto, el National Vulnerability Database (NVD) de NIST registró más de 40.000 CVEs solo en 2024, un incremento del 30% respecto al año anterior. El modelo clásico —escanear, asignar severidad CVSS, exportar un CSV al equipo de desarrollo— no escala. No porque la gente no trabaje, sino porque la pregunta «¿cuántos CVEs tenemos?» produce una lista que ningún equipo puede procesar en un ciclo de sprint. La pregunta correcta es otra: ¿qué vulnerabilidades son alcanzables en nuestro entorno y cuáles están siendo explotadas activamente?
Qué ocurrió
La industrialización de la vulnerabilidad no es un evento aislado, es la convergencia de tres tendencias que AI amplifica simultáneamente. Primero, el volumen de código: la adopción de microservicios, contenedores y dependencias open-source multiplica la superficie atacable. Un servicio Node.js típico en producción arrastra 800 a 1.200 dependencias transitivas vía npm; un stack Java con Spring Boot puede superar las 300. Cada una es un vector potencial.
Segundo, la velocidad de explotación. Antes de 2023, el promedio entre publicación de un CVE y disponibilidad de un exploit funcional en repositorios públicos rondaba los 14 a 21 días. Con herramientas de IA asistida para análisis de parches (diffing) y generación de payloads, ese intervalo se comprimió a 24-72 horas para componentes populares. El caso de CVE-2024-21762 (Fortinet FortiOS) demostró que un exploit funcional apareció en foros criminales en menos de 48 horas tras la divulgación.
Tercero, la composición de ataques. AI permite concatenar vulnerabilidades de baja severidad individual en cadenas de ataque que CVSS por separado no captura. Un SSRF de CVSS 5.3 combinado con una deserialización insegura de CVSS 6.1 puede escalar a RCE con impacto crítico, pero ningún score estático lo refleja.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para un equipo SRE que gestiona 200+ contenedores en EKS o ECS, la consecuencia es operativa: los scanners de contenedores (Trivy, Grype, Amazon Inspector) devuelven miles de findings por imagen, de los cuales quizás el 2% es realmente ejecutable en el runtime específico. El equipo gasta el 80% del tiempo de triage clasificando hallazgos que no representan riesgo explotable.
En entornos AWS, Amazon Inspector Continuous Scanning detecta vulnerabilidades en EC2, ECR y Lambda, pero entrega una lista plana sin contexto de red, sin saber si el puerto vulnerable está expuesto detrás de un Network Load Balancer con security groups restrictivos, o si el código vulnerable nunca se ejecuta en ese runtime. El resultado: ingenieros parcheando librerías que no usan, mientras un misconfiguration en un S3 bucket con acceso público queda sin tocar porque no tiene CVE asociado.
Para seguridad, el problema es estratégico. Los dashboards de cumplimiento muestran «98% de CVEs críticos remediados» mientras el ataque real entra por una ruta lateral que ningún scanner de vulnerabilidades cubre: credenciales hardcodeadas en Terraform, roles IAM con permisos excesivos, o un sidecar de Istio con mTLS deshabilitado.
Detalles técnicos
El CVSS v3.1 (y la transición a v4.0 publicada por FIRST en noviembre 2023) evalúa severidad intrínseca: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, y los metrics de impacto CIA. No incorpora: existencia de exploit público, exposición de red, ejecutabilidad del código vulnerable, ni contexto organizacional. Un CVE-2024-3094 (xz/liblzma backdoor, CVSS 10.0) tenía un score perfecto, pero el riesgo real dependía de qué distros lo empaquetaban y si el daemon sshd cargaba la librería vulnerable en ese build específico.
Herramientas que sí contextualizan:
- EPSS (Exploit Prediction Scoring System): modelo ML de FIRST que estima la probabilidad de explotación en los próximos 30 días. Un CVE con CVSS 7.5 pero EPSS 0.99 (99% de probabilidad de explotación) debe priorizarse sobre uno con CVSS 9.8 y EPSS 0.01.
- CISA KEV (Known Exploited Vulnerabilities): catálogo que lista CVEs confirmados como explotados en el mundo real. Actualizado semanalmente. Si un CVE está en KEV, la conversación sobre prioridad termina.
- Reachability analysis: herramientas como Snyk Reachability o JFrog Xray determinan si la ruta de código vulnerable se invoca en el runtime actual. En una aplicación Java con 300 dependencias, típicamente solo el 15-20% del código vulnerable es alcanzable.
En AWS específicamente, aws inspector batch-get-findings –filter-attribute-keys permite filtrar hallazgos, pero no integra reachability ni EPSS nativamente. La correlación con VPC flow logs, security groups y subnets públicas sigue siendo manual o vía scripts ad-hoc.
Qué deberían hacer los administradores y equipos técnicos
1. Reducir la superficie antes de parchear. Reemplazar imágenes base Alpine/Debian por versiones hardenadas (Distroless de Google, BCI de SUSE) elimina 80-90% de CVEs de librerías del sistema operativo que nunca se ejecutan. En un pipeline de CI/CD con ECR:
# Reemplazo en Dockerfile
FROM gcr.io/distroless/java17-debian12 # en lugar de FROM openjdk:17-slim
2. Correr SAST con IA en el pre-commit y CI. Semgrep con reglas customizadas o GitHub CodeQL detectan vulnerabilidades en código propio antes de que lleguen a un registry. Integrar como check bloqueante en el pull request:
semgrep scan –config auto –error –severity ERROR .
3. Cambiar la fuente de verdad al runtime. Escanear el registry está bien, pero lo que importa es lo que corre en producción. Activar Amazon Inspector Continuous Scanning en las cuentas con aws inspector enable y correlacionar findings con aws ec2 describe-instances + VPC reachability analyzer para saber si el puerto vulnerable tiene ruta de acceso externa.
4. Priorizar con contexto, no con CVSS solo. Un flujo mínimo viable: filtrar findings que estén en CISA KEV o con EPSS > 0.80, cruzar con reachability (¿el código vulnerable se ejecuta?), evaluar exposición de red (¿hay un path desde internet?), y recién ahí escalar al equipo de desarrollo.
5. Evaluar configuración como primera clase. STIG scanning (DISA) o AWS Config con reglas de conformance detectan misconfigurations que no tienen CVE pero son vectores de ataque. En AWS: aws configservice put-configuration-recorder con reglas para S3 public access, IAM policies wildcard, y security groups con 0.0.0.0/0.
Conclusión
AI no creó el problema de gestión de vulnerabilidades, pero aceleró la asimetría entre defensores y atacadores hasta un punto donde el modelo de «parchear todo lo crítico» es matemáticamente inviable. El equipo que gestiona 40.000 CVEs anuales con un proceso secuencial de triage pierde por diseño. El que reduce superficie, analiza reachability en producción, integra EPSS y KEV en su pipeline de priorización, y trata la configuración como un vector de riesgo equivalente al código, cierra la brecha. No con más herramientas, sino con mejores preguntas. La pregunta nunca fue «¿cuántos bugs tenemos?» sino «¿cuál es el siguiente paso que un atacante puede dar en mi entorno, y cuánto tiempo tengo para cortarle el camino?»
Fuentes
- https://thenewstack.io/cve-vulnerability-risk-management/
- https://eng.uber.com/
- https://blog.apnic.net/