Cada semana se publican cientos de vulnerabilidades nuevas. Ninguna empresa puede aplicar todas las actualizaciones el mismo día, y tampoco debería: una actualización mal probada también puede detener tu operación. La pregunta correcta no es “¿hay algo nuevo?”, sino “¿qué de todo esto me afecta a mí, qué atiendo primero y cómo lo compruebo antes de tocar lo que está en producción?”.
Este es el método que usamos para responderla.
Qué es un CVE y por qué no todos te afectan
Un CVE (Common Vulnerabilities and Exposures) es el identificador público de una vulnerabilidad: un código como CVE-2026-12345 que describe qué falla, en qué producto y en qué versiones. Que exista un CVE no significa que tu empresa esté expuesta. Solo te afecta si usas ese producto, en una de esas versiones y de una forma en que la falla se pueda aprovechar.
1. Saber exactamente qué tienes
Sin inventario no hay decisión posible. Una CMDB (base de datos de configuración) registra cada servidor y computadora, su sistema operativo, los programas instalados y sus versiones. Es la diferencia entre “creo que tenemos esa versión” y “estos tres equipos la tienen”.
2. Cruzar cada vulnerabilidad con tus versiones
Con el inventario al día, cada CVE nuevo se compara contra lo que realmente tienes instalado. El resultado es una lista corta y concreta: qué equipos están afectados y cuáles no. La mayoría de los avisos se descartan en este paso.
3. Priorizar
No todo lo que te afecta es igual de urgente. Para ordenar la lista conviene revisar:
- La gravedad: la calificación CVSS, del 0 al 10.
- Si ya se está explotando: el catálogo de vulnerabilidades explotadas conocidas de CISA (KEV) es una buena referencia.
- La exposición: no es lo mismo un servidor publicado en internet que una computadora de la red interna.
- La importancia del equipo: el servidor de facturación pesa más que una computadora de pruebas.
4. Probar antes de producción
Antes de aplicar una actualización en un equipo real, se reproduce el caso en un entorno aislado, por ejemplo en máquinas virtuales con la misma configuración. Así se comprueba que la actualización corrige la falla y que no rompe los programas de los que depende tu operación.
5. Que una persona decida
La automatización puede proponer, pero la decisión de tocar producción la toma una persona: revisa la propuesta, elige la ventana de mantenimiento y tiene listo cómo revertir si algo sale mal.
6. Dejar evidencia
Cada paso debe quedar registrado: qué vulnerabilidad era, qué equipos afectaba, cómo se probó, quién aprobó y cuándo se aplicó. Esa evidencia es lo que te permite demostrar, a tu dirección o a un auditor, que la seguridad se está atendiendo.
Cómo lo hacemos en Aureo
Hoy nuestro equipo mantiene actualizadas las computadoras con una plataforma de gestión de parches, correlaciona las alertas de seguridad y prioriza lo que se atiende primero. Cada incidente queda en un ticket, y el resultado llega al reporte mensual.
Además, estamos construyendo en Fireman, nuestra plataforma propia, un flujo que automatiza este método: lee los CVE, los cruza con la CMDB de cada cliente, valida el caso en máquinas virtuales y emite un dictamen que un especialista califica y, si lo aprueba, ejecuta en producción. Ese flujo está en desarrollo; lo que ya opera está descrito en la página de Fireman.
Preguntas para tu proveedor (incluidos nosotros)
- ¿Tienen un inventario de mis equipos con versiones actualizadas?
- ¿Cómo deciden qué actualización aplicar primero?
- ¿Prueban las actualizaciones antes de aplicarlas en producción?
- ¿Quién aprueba el cambio y dónde queda registrado?
- ¿Puedo ver esa evidencia en un reporte?
Si quieres saber cómo está hoy la seguridad de tus equipos, empieza con un diagnóstico sin costo.
