El mundo de las vulnerabilidades está diseñado —sin querer— para que un dueño de negocio desconecte. CVE, CVSS, día cero, KEV, ATT&CK: una sopa de siglas y anglicismos que suena a que hace falta un doctorado para opinar. No lo hace. Detrás de todo ese vocabulario hay una historia bastante simple y muy humana: una falla existe, alguien la descubre, alguien le pone nombre, alguien decide qué tan grave es, alguien la aprovecha —y tú, con tiempo y presupuesto limitados, tienes que decidir qué hacer al respecto—. Esta guía une las piezas en ese orden, y deja cada una a un clic por si quieres el detalle.
La tesis, por si prefieres el resumen antes que la historia: no puedes arreglar todo, así que el juego no es saberlo todo, sino priorizar bien. Y priorizar bien depende de entender qué significa cada pieza.
1. Qué es una vulnerabilidad (y el mito del día cero)
Una vulnerabilidad es, simplemente, una debilidad que alguien puede aprovechar: una puerta que no cierra del todo. La primera distinción que importa es entre el día cero —una falla que el fabricante aún no conoce y que no tiene parche— y la vulnerabilidad conocida, que ya se hizo pública y tiene corrección disponible. El instinto lleva a temerle al día cero, el villano de las noticias. Pero para casi toda empresa el riesgo real es el opuesto: la vulnerabilidad conocida que nunca se parchó, porque es común, se explota en masa y es completamente resoluble. Por qué el miedo suele estar mal puesto lo desarrollamos en día cero vs. vulnerabilidad conocida.
2. Cómo se nombra y se mide (CVE, CVSS, NVD)
Cuando una vulnerabilidad se hace pública, entra en una maquinaria de identificación. Recibe un CVE, su nombre único (ese código tipo CVE-2024-3094) para que todos hablen de la misma falla. Recibe un CVSS, un puntaje del 0 al 10 que estima su gravedad en abstracto. Y suele pasar por el NVD, la base del gobierno estadounidense que la enriquece con datos. Suena ordenado, y a veces lo es —pero tiene grietas que conviene conocer: el puntaje CVSS no sabe nada de tu contexto, y la base oficial que lo asigna (el NVD) lleva desde 2024 desbordada, al punto de que hoy solo enriquece lo de mayor riesgo. La conclusión práctica es liberadora: el número oficial es una guía, no un mandato, y no hay que esperarlo para actuar. El desglose está en CVE, CVSS y NVD.
3. Cómo saber qué se está explotando de verdad (KEV)
Aquí es donde la teoría aterriza. Que existan millones de vulnerabilidades no significa que todas te vayan a atacar; solo una fracción se explota activamente en el mundo real. La agencia de ciberseguridad de EE.UU. (CISA) publica esa fracción en el catálogo KEV (Known Exploited Vulnerabilities): la lista de fallas confirmadas como usadas en ataques reales. Es la mejor herramienta de priorización que existe y es gratuita —si algo está en el KEV, deja de ser hipótesis y pasa al frente de la fila—. Es también el criterio que hoy usa hasta el NVD para decidir qué enriquecer primero, lo que dice mucho de su valor.
4. Cómo atacan de verdad (MITRE ATT&CK)
Un CVE describe una puerta rota; pero un ataque real es toda una secuencia: entrar, esconderse, escalar privilegios, moverse, robar. Para mapear ese comportamiento existe MITRE ATT&CK, una base de conocimiento de las tácticas (el "por qué" de cada movimiento) y técnicas (el "cómo") que usan los atacantes reales. Cambia la pregunta de "¿qué falla tengo?" a "¿cómo me atacarían, y lo detectaría?". El CVE te dice qué parchar; ATT&CK, qué comportamientos vigilar. Lo explicamos en MITRE ATT&CK: el mapa de cómo atacan.
5. Qué hacer con todo esto: identificar, priorizar, remediar
Aquí se cierra el círculo, porque saber no sirve de nada sin actuar. El ciclo sano de gestión de vulnerabilidades tiene tres tiempos:
- Identificar: saber qué tienes (un inventario vivo) y qué vulnerabilidades corren en ello. No puedes proteger lo que no sabes que existe.
- Priorizar: cruzar el puntaje (CVSS) con lo que de verdad importa —¿está expuesto?, ¿es crítico?, ¿está en el KEV?—. Esta es la etapa que casi todos se saltan, y la que separa gestionar de solo coleccionar reportes.
- Remediar: cerrar la ventana, que en la práctica significa parchar a tiempo y de forma sostenida.
Y ese último paso es donde la mayoría falla, no por falta de conocimiento sino de proceso: la explotación de vulnerabilidades conocidas es hoy el vector de acceso número uno a las brechas, justamente porque el parche existía y no se aplicó a tiempo. Cómo cerrar esa ventana —incluyendo la mitad olvidada, las aplicaciones de terceros— lo tratamos en el parche que no se aplicó y en el parcheo de aplicaciones de terceros.
La idea que lo resume todo
Si te quedas con una sola cosa, que sea esta: el objetivo no es cerrar todas las vulnerabilidades —es imposible—, sino cerrar las que importan antes de que alguien las use. El CVE te da el nombre, el CVSS una primera idea de gravedad, el KEV te dice qué se está explotando de verdad, ATT&CK cómo te atacarían, y el parcheo disciplinado es la acción que convierte todo eso en protección real. Nadie puede con todo; los que duermen tranquilos no son los que lo saben todo, sino los que priorizan bien y actúan a tiempo. Ayudar a montar ese ciclo —ver tu superficie de ataque con nuestro evaluador de gestión de parches y endpoints y cerrarla como parte de la defensa del endpoint— es exactamente donde entramos nosotros.