Academia  /  RioGuard82  /  Aprende por qué
🛡 Gestión de vulnerabilidades

197 bugs... o quizá ninguno

Un escáner te dice “tienes 197 vulnerabilidades” y te da un infarto. Casi nunca es verdad. Aprende a saber cuáles importan DE VERDAD y a parchear sin romper nada.

👁La trampa del «2 millones de amenazas»

¿Te acuerdas de aquellos antivirus —el Panda, por ejemplo— que nada más instalarlos gritaban «¡2 millones de amenazas!» con la pantalla en rojo… y no tenías nada? Puro humo para venderte la versión de pago.

Con las vulnerabilidades pasa IGUAL. Una herramienta que te asusta con 197 «fallos» que no lo son es tan mala como una que se calla. Aquí aprendes a no caer en ese juego — ni de víctima, ni de profesional que lo provoca.

🐼El efecto “Panda”: no todo lo que suena a CVE es peligroso

Las bases de datos marcan por la versión original (upstream) del software. Pero tu distro (Ubuntu/Debian) hace backport: coge solo el arreglo de seguridad y lo mete en la versión vieja sin cambiar el número. Ejemplo: openssl 3.0.2-0ubuntu1.15 ya lleva el parche aunque “3.0.2” figure como vulnerable.

En cristiano: es como si el taller arreglara la pieza defectuosa de tu coche pero sin cambiar el año del modelo en los papeles. Por fuera sigue poniendo «3.0.2», por dentro ya está arreglado.

Por eso una herramienta que solo mira la versión canta falsos positivos en masa. Decir “197 bugs” cuando hay 0 accionables es tan inútil como callarse.

La autoridad de “hay fix que aplicar” es tu gestor de paquetes (apt, dpkg --compare-versions) y el estado ESM/Pro, no el conteo bruto del escáner.

🏁Los 4 estados de una vulnerabilidad

ParcheadoEl fix ya está (tu versión ≥ la corregida de la distro). No cuenta.
PendienteHay fix disponible y NO instalado. Esto es lo accionable.
ESM / sin fix libreEl arreglo solo está en Ubuntu Pro/ESM, o aún no hay. Informativo.
Sin triarTodavía no hay parche publicado. Informativo.

RioGuard82 cruza cada hallazgo con tu estado de parcheo real y te da el nº accionable, no el bruto.

🎯Priorizar de verdad (no por CVSS a secas)

El orden que usa el sector:

1
1. KEV (CISA)
¿Se está explotando AHORA en el mundo real? Esto primero, siempre.
2
2. EPSS
Probabilidad (0–1) de que se explote pronto. Rankea el resto.
3
3. CVSS
Gravedad/impacto técnico. Desempata.
4
4. Contexto
¿El servicio está expuesto a internet? ¿en uso? Ajusta.

🧮El número que importa

El titular siempre es el nº ACCIONABLE (lo pendiente) + cuántos son KEV. Nunca el bruto del escáner.

Y si un paquete no se pudo evaluar (timeout, distro no soportada), se marca “no evaluado”, que no es lo mismo que “limpio”. Honestidad antes que un falso “✅ estás a salvo”.

🔃El bucle de parcheo sano

1
apt list --upgradable
Mira lo PENDIENTE de seguridad de verdad.
2
Snapshot antes de lo gordo
timeshift/btrfs/LVM/ZFS, o ten el downgrade a mano: marcha atrás REAL.
3
sudo apt-get update && sudo apt-get upgrade
Aplica. Considera 'unattended-upgrades' para seguridad automática.
4
Verifica el servicio
Que siga vivo tras el parche. Parchear y romper no es ganar.

⚠️Errores típicos

Tomar “N CVEs” como “N problemas”
Cruza con el estado de parcheo real: casi siempre lo accionable es una fracción (o cero).
Parchear algo crítico sin backup
Un upgrade puede romper un servicio. Snapshot antes, o ten claro el downgrade.
Confundir “no evaluado” con “limpio”
Un timeout o una distro no soportada NO significan que estés a salvo. Reintenta o usa otra herramienta.