En seguridad existe una obsesión colectiva con los zero-days. Son el tema de las conferencias, el plot de las películas, el argumento de ventas de cada vendor. Un zero-day suena a espionaje de élite, a APT con recursos ilimitados, a algo que solo le pasa a los otros.
El problema es que esa narrativa es, en su mayor parte, una distracción. La estadística real es brutalmente diferente: la mayoría de organizaciones que sufren un breach no fueron víctimas de un zero-day. Fueron víctimas de una vulnerabilidad que llevaba semanas, meses o años en su lista de pendientes.
Eso tiene nombre: N-day.
¿Qué es un N-day?
Un N-day es una vulnerabilidad que ya fue pública — tiene CVE asignado, tiene análisis técnico disponible, a veces tiene código de explotación (PoC) en GitHub — pero que no ha sido parcheada en el sistema afectado.
La "N" representa el número de días transcurridos desde que se publicó el CVE. Un N-day de 30 días lleva un mes sin parche. Un N-day de 365 días lleva un año. En la práctica, cuando hablas con equipos de respuesta a incidentes, encontrar N-days de 2 a 3 años en sistemas productivos es completamente normal.
N-day: vulnerabilidad ya documentada, con CVE, con parche disponible, con frecuencia con exploit público. El defensor debería tener ventaja — pero rara vez la usa.
El ciclo de vida que importa entender
Para entender por qué los N-days son tan peligrosos, hay que ver qué pasa en el tiempo entre que se descubre una vulnerabilidad y cuando realmente la explotan masivamente.
El dato clave: el atacante y el defensor reciben la misma información el mismo día. La diferencia es que el atacante actúa en días, y el defensor promedio tarda semanas o meses.
El dato que duele: CISA KEV
La CISA Known Exploited Vulnerabilities (KEV) es una lista que el gobierno de Estados Unidos mantiene con vulnerabilidades que están siendo explotadas activamente en el mundo real. No son teóricas. Son las que están siendo usadas ahora mismo para comprometer sistemas.
On-premise: el infierno del patch management
En entornos on-premise, parchear no es apretar un botón. Es un proceso con fricción real que explica por qué los N-days prosperan.
- Change management: cada parche requiere aprobación formal y ventana de mantenimiento
- Dependencias: una librería actualizada puede romper una aplicación de negocio
- Sistemas legacy que ya no reciben parches del fabricante (EOL)
- Inventario incompleto — no sabes lo que tienes, no puedes parchear lo que no ves
- Downtime intolerable en sistemas críticos 24/7 (manufactura, hospitales, OT/ICS)
- Equipos con ancho de banda limitado para gestionar todo el volumen de CVEs
- Responsabilidad compartida: el proveedor parchea la infraestructura, tú parcheas tu capa
- Contenedores con imágenes base desactualizadas que nadie reconstruye
- Dependencias en código propio (npm, pip, Maven) que el cloud provider no toca
- Servicios gestionados auto-actualizados que esconden la versión real
- IaC (Terraform, CloudFormation) con versiones de AMI congeladas
- Microservicios: cientos de repositorios, cada uno con sus propias dependencias
Por qué los N-days suelen ser más peligrosos que los zero-days
Esta afirmación suena contraintuitiva, pero tiene sentido cuando analizas la dinámica de ataque:
- Los zero-days requieren capacidades élite. Desarrollar o comprar un zero-day cuesta desde decenas hasta millones de dólares. Solo APTs con recursos significativos los usan. Son ataques dirigidos, no masivos.
- Los N-days son democráticos para el atacante. El PoC está en GitHub. Metasploit tiene el módulo. Cualquier script kiddie puede lanzar el exploit con un comando. El número de actores que pueden atacarte con un N-day es órdenes de magnitud mayor.
- Los N-days escalan con botnets. Los ataques de ransomware modernos escanean millones de IPs buscando versiones vulnerables. No te eligen a ti — encuentran todo lo que no ha sido parcheado. Eres una víctima estadística, no un objetivo.
- El tiempo juega en contra del defensor. Cuanto más viejo el N-day, más automatizadas están las herramientas de explotación, más amplio el pool de atacantes, y más probable que ya estén adentro sin que lo sepas.
Cómo priorizar: no todos los CVEs son urgentes
El volumen de CVEs publicados es brutal — más de 28,000 en 2024. No puedes parchear todo al mismo tiempo. La clave es priorizar correctamente.
| Prioridad | Criterio | Acción | Plazo |
|---|---|---|---|
| P1 | CRÍTICO — En CISA KEV + CVSS ≥ 9 + servicio expuesto a internet | Parchea o mitiga (WAF, desconectar) de inmediato | <24 horas |
| P2 | ALTO — CVSS ≥ 7 + PoC público + activo crítico | Plan de parche con ventana de emergencia | 7 días |
| P3 | MEDIO — CVSS ≥ 7 sin PoC o sistema interno sin exposición directa | Incluir en ciclo normal de patch management | 30 días |
| P4 | BAJO — CVSS < 7, sin explotación activa conocida, activo no crítico | Backlog de parches regulares | 90 días |
Las herramientas que cambian el juego
Para gestionar N-days a escala, necesitas herramientas que automaticen el inventario y la correlación:
- Tenable / Qualys / Rapid7 — escaneo de vulnerabilidades y correlación con CVEs
- SCCM / Intune / Ansible — distribución centralizada de parches
- CMDB actualizado — sin inventario, el patch management es aleatorio
- Wazuh / OpenVAS — alternativas open source para detección
- AWS Inspector / Security Hub — detección de CVEs en EC2 y contenedores
- Trivy / Grype — escaneo de imágenes Docker en CI/CD
- Dependabot / Renovate — actualizaciones automáticas de dependencias en repos
- CSPM (Wiz, Orca, Prisma) — visibilidad unificada de riesgos cloud
El cambio de mentalidad que realmente importa
El problema de fondo no es técnico — es de incentivos. Los zero-days generan cobertura de prensa, presupuesto para herramientas sofisticadas y conversaciones interesantes en conferencias. Parchear un N-day de dos años no genera nada de eso.
Pero los ataques reales viven en el espacio aburrido. El ransomware que paraliza un hospital no usa un zero-day de inteligencia militar. Usa CVE-2023-xxxx que lleva seis meses en la lista de pendientes del equipo de operaciones.
La madurez en seguridad no se mide por las herramientas que compras para detectar amenazas avanzadas. Se mide por qué tan rápido reduces la superficie de ataque de lo que ya sabes que es vulnerable.
2. Suscripción al feed de CISA KEV — parcheado obligatorio en <14 días para activos expuestos.
3. Escaneo continuo de vulnerabilidades, no puntual.
4. Pipeline de CI/CD con escaneo de contenedores e imágenes base.
5. Métricas de tiempo-hasta-parche por prioridad. Lo que no se mide no mejora.
Conclusión
Los zero-days son reales y peligrosos. Pero son el problema de unos pocos. Los N-days son el problema de todos — y la brecha entre saber que existe una vulnerabilidad y aplicar el parche es exactamente la ventana donde ocurren la mayoría de los incidentes.
En on-premise, el reto es organizacional: change management, inventario, sistemas legacy. En la nube, el reto es conceptual: entender que la responsabilidad compartida no cubre tu código ni tus dependencias. En ambos entornos, el vector de ataque más común en 2026 no es algo nuevo y sofisticado.
Es algo que ya tiene número de CVE, parche disponible y 180 días de antigüedad.