Gestión de Vulnerabilidades: Conoce a los Dueños de tus Activos en Linux

Por qué tu backlog de vulnerabilidades no baja aunque tengas buenos escaneos

Si tu scanner encuentra 800 hallazgos cada lunes y los mismos 800 siguen abiertos al viernes siguiente, no te falta una mejor herramienta de detección. Te falta saber quién es dueño de cada servidor, si tiene autoridad para tocarlo y si tiene tiempo en el sprint. Esa es la tesis del artículo de Nishant Sharma publicado en Dark Reading en octubre de 2026, y es exactamente el problema que vemos en flotas Linux medianas — entre 20 y 500 servidores — donde el equipo de seguridad reporta métricas que ningún equipo de ingeniería sabe cómo mover.

La pieza corta de Sharma mete el dedo en una llaga que muchos programas de vulnerabilidades se rehúsan a mirar: el conteo bruto de hallazgos abiertos mezcla cobertura de detección con capacidad de remediación. Cuando compras una licencia mejor, ves más. Cuando ves más, el número sube. Cuando el número sube, alguien en la gerencia pregunta por qué. Y entonces el equipo aprende a no mirar — porque expandir cobertura castiga la métrica con la que lo miden.

En este post vamos a desarmar el argumento, mirar los números que sí importan (MTTR segmentado por equipo, SLA compliance, porcentaje del estate con dueño verificado) y dejar un flujo reproducible en bash + systemd + CMDB para que un sysadmin Linux pueda auditar hoy mismo quién es dueño de qué en su flota.

Lo que realmente mide un backlog de vulnerabilidades

Un hallazgo se cierra cuando se cumplen cinco cosas a la vez, no una. Sharma las enumera así:

1. Alguien sabe que el activo existe.
2. Alguien es responsable de él.
3. Esa persona puede cambiarlo.
4. Esa persona tiene tiempo para cambiarlo.
5. Esa persona tiene razón para priorizarlo sobre su otro trabajo.

Tu scanner resuelve la primera. Las otras cuatro son gobernanza. Y aquí está el punto donde dos empresas con idéntica herramienta, idéntico estate e idéntico volumen de hallazgos pueden diferir diez veces en velocidad de remediación: la diferencia no es tecnológica, es de quién firma el cambio y a quién le duele si no se firma.

El autor describe cuatro modos de falla que reconocemos en cualquier flota Linux mediana:

• Sin dueño. El activo no está mapeado a nadie. Es el peor caso porque un hallazgo sin dueño no se puede escalar — no hay a quién escalar.
• Dueño sin autoridad. El equipo es responsable pero no puede actuar: el parche lo controla el vendor, otro equipo tiene la plataforma, la app está contractualmente congelada.
• Dueño sin capacidad. Accountability y autoridad están, pero la remediación compite con feature delivery en el mismo backlog, y el bonus del product owner no menciona seguridad.
• Dueño sin consecuencia. Todo está en su lugar y nada pasa porque incumplir el SLA de remediación no le cuesta a nadie.

Si tu reporte de seguridad llega al equipo de seguridad en vez de llegar al jefe del dueño del activo, tu estado default es el cuarto modo de falla.

Por qué el open-finding count es la métrica más reportada y la menos útil

El conteo bruto de hallazgos abiertos se mueve por razones que no tienen nada que ver con seguridad ni con ingeniería: una actualización del scanner, un nuevo feed de threat intel, una política que añade controles, una adquisición que suma 300 servidores al inventario. Es ruido. Cuando lo reportas al board, lo que el board escucha es “tenemos 4,200 problemas”. Cuando el CISO lo reporta como tendencia, lo que la tendencia esconde es si te estás poniendo más seguro o simplemente mirando más.

Sharma propone tres métricas que sí sirven, y vale la pena adoptarlas tal cual en lugar de reinventarlas:

• Mean Time to Remediate segmentado por equipo dueño. Convierte una métrica de seguridad en una métrica de gestión. Si el equipo de pagos tarda 12 días y el de infraestructura 45, sabes dónde hay que hablar con gerencia, no con seguridad.
• SLA compliance en lugar de closure rate. El closure rate recompensa cerrar lo fácil y castiga al equipo que se queda con lo difícil. El SLA compliance mide si cumpliste lo que prometiste, en el tiempo que prometiste.
• Porcentaje del estate con dueño verificado. Es el leading indicator de todo lo demás. Por debajo de 90%, las otras métricas no significan nada.

Una anécdota del propio Sharma: en un programa, el tiempo de remediación cayó de 45 a 10 días y el SLA compliance subió de 30% a 95% en seis meses. La herramienta ayudó, pero la herramienta no fue la intervención. Los hallazgos empezaron a enrutarse automáticamente a equipos con nombre y apellido. Los breaches de SLA se empezaron a reportar a liderazgo de ingeniería, no a seguridad. Las excepciones obtuvieron un camino real de aprobación. Los activos sin dueño se convirtieron en hallazgos de gobernanza. Y — counterintuitive — el throughput de desarrollo subió en el mismo período.

Mapeando ownership en tu flota Linux con bash + CMDB

La parte operativa del artículo es la que más cuesta aterrizar. Aquí va un flujo reproducible para que un sysadmin Linux empiece hoy mismo a auditar quién es dueño de qué, sin comprar una plataforma de asset management nueva. Vamos a usar nmap para descubrir, awk para consolidar, y un CSV controlado por git como CMDB mínimo viable.

Primero, el descubrimiento. Queremos ver toda la flota en una sola vista, identificable por dueño, con la huella mínima para luego cruzar contra hallazgos del scanner:

# Escaneo autenticado con nmap a la subred 10.10.0.0/16
# -sV detecta servicios, -O intenta adivinar el SO, --privileged para SYN scan
sudo nmap -sV -O -T4 --open -oX /tmp/escaneo_inicial.xml 10.10.0.0/16
# Convertir XML a CSV solo con lo que nos sirve para ownership
sudo xmlstarlet sel -t -m //host 
  -v '@addr' -o ',' 
  -v 'address/@addr/' -o ',' 
  -v 'hostnames/hostname/@name' -o ',' 
  -v 'os/osclass/@osfamily' -o ',' 
  -v 'ports/port/@portid' -o '|' 
  -v 'ports/port/service/@name' -o '|' 
  -v 'ports/port/service/@product' -n 
  /tmp/escaneo_inicial.xml > /tmp/flota_raw.csv

El xmlstarlet no está en todos los servers por default; en Debian/Ubuntu viene en xmlstarlet, en RHEL family en xmlstarlet también pero hay que instalar EPEL. Si no lo quieres agregar, puedes pasar el -oX directo al pipeline de Python más abajo.

Ahora consolidamos puertos por host en una sola fila, y dejamos el archivo listo para merge con el CMDB:

awk -F',' 'BEGIN { OFS=","; print "ip,hostname,osfamily,services" }
NR==1 { next }
{
  key = $1 "|" $2 "|" $3
  if (!(key in seen)) {
    seen[key] = $4 ":" $5
    order[++n] = key
  } else {
    seen[key] = seen[key] "|" $4 ":" $5
  }
}
END {
  for (i = 1; i <= n; i++) {
    split(order[i], f, "|")
    print f[1] "," f[2] "," f[3] "," seen[order[i]]
  }
}' /tmp/flota_raw.csv > /tmp/flota_consolidada.csv

Esto te deja un CSV con una fila por host, todos sus puertos concatenados en la última columna. El siguiente paso es cruzar contra tu CMDB real. En el 90% de las flotas Linux medianas el “CMDB” es una spreadsheet de Google compartida que alguien actualizó por última vez en 2023. La vamos a tratar como tal — no vamos a pelear con eso todavía.

# Bajamos el CMDB a CSV (manual o via API si lo tienes en Notion/Sheets)
# Asumimos columnas: hostname,owner_email,team,business_unit,last_seen
# Hacemos join en bash con awk, marcando hosts que NO están en el CMDB
awk -F',' 'BEGIN { OFS="t"; print "ipthostnametosfamilytservicestcmdb_ownertcmdb_teamtstatus" }
NR==FNR && $1 != "hostname" { cmdb[$1] = $2 "t" $4; next }
NR > 1 {
  owner = (cmdb[$2] ? cmdb[$2] : "MISSING")
  split(owner, parts, "t")
  status = (parts[1] == "MISSING") ? "UNOWNED" : "OWNED"
  print $1, $2, $3, $4, parts[1], parts[2], status
}' /tmp/cmdb_export.csv /tmp/flota_consolidada.csv > /tmp/ownership_audit.tsv

El archivo ownership_audit.tsv que sale de este pipeline es tu leading indicator. La columna status te dice OWNED o UNOWNED por host. Si el porcentaje de UNOWNED supera el 10%, las otras métricas que estás reportando no significan nada. Sharma es explícito en esto: por debajo del 90% de cobertura de ownership, todos los demás KPIs de vulnerabilidades son ficción.

Las tres reglas que propone Sharma para gobernar ownership

El artículo es opinion, no framework, y Sharma lo deja claro. Pero las tres reglas operativas que sugiere se pueden implementar literalmente en cualquier flota Linux mediana con un script y una política de cambio. Las reproducimos y comentamos una por una.

Regla 1: el dueño es una persona o un equipo permanente, nunca un departamento. “Infraestructura” no se puede paginar ni se le puede cobrar un incumplimiento de SLA. Si tu CMDB dice [email protected], no tienes dueño. El primer paso es reemplazar todos los owners departamentales por nombres o aliases de equipo con personas asignadas como responsables del SLA. En bash, esto es trivial de auditar:

# Detectar owners que son departamentos disfrazados de equipo
grep -E -i '^(infraestructura|infra|it|seguridad|sysadmin|plataforma|redes|devops)$' /tmp/cmdb_export.csv
# Salida esperada: lista de filas a corregir ANTES de seguir

Si la salida no está vacía, esos hosts no tienen dueño real. Cada fila debe reemplazarse por un alias de equipo con al menos dos personas en members.txt, o por una persona específica con backup.

Regla 2: el mapeo se mantiene, no se establece. Las reorgs invalidan el ownership cada tres a seis meses. Un host que en enero pertenecía al “equipo de pagos” puede pasar a “equipo de checkout” o “equipo de platform” después de una reorg, y nadie actualiza el CMDB. La solución no es comprar una herramienta de sincronización, es hacer que el chequeo sea parte del release:

# Hook pre-commit en el repo del CMDB (asumimos /srv/cmdb/)
cd /srv/cbdb
git add ownership.tsv
# Validar que ningún host quedó con owner=<departamento>
if grep -E -i 'owner=(infraestructura|infra|it|plataforma|seguridad)$' ownership.tsv; then
  echo "ERROR: hosts con owner departamental. Corregir antes de commit."
  exit 1
fi
# Validar que el archivo tiene un timestamp reciente
test $(find . -name 'ownership.tsv' -mtime -90 | wc -l) -gt 0 || {
  echo "ERROR: ownership.tsv tiene más de 90 días sin actualizar."
  exit 1
}
git commit -m "ownership audit $(date -I)"

El pre-commit hook vive en .git/hooks/pre-commit y rechaza el commit si alguien intenta subir un ownership.tsv con departamentos como dueños o con más de 90 días de antigüedad. Es feo, es bash puro, y es exactamente lo que mantiene la cobertura arriba del 90%.

Regla 3: un activo que nadie va a dueñar se reporta como hallazgo de gobernanza, separado de las vulnerabilidades que tiene encima. Esta es la regla que más cuesta implementar porque requiere coordinación con liderazgo de ingeniería. La idea es que un host zombie — prendido, con servicios, con CVE explotables, sin responsable — no se reporta como “1 host con 14 CVE”, se reporta como “1 hallazgo de governance: host sin dueño”. Sharma argumenta que esta separación produce dueños más rápido que cualquier cantidad de reportes de vulnerabilidades, porque el SLA de governance es distinto y la conversación es con gerencia, no con el técnico de turno.

Métricas alternativas que sí puedes calcular hoy en bash

El último bloque operacional del artículo es la trinidad de métricas que reemplaza al open-finding count. Las podemos calcular contra cualquier scanner que escupa JSON o CSV. Vamos con OpenSCAN/Nessus Tenable.io como referencia porque es lo que corre en la mayoría de flotas LATAM, pero el patrón aplica igual a Qualys, Rapid7 o Wiz.

Primero, MTTR segmentado por equipo. Asumimos que el export del scanner tiene columnas finding_id,asset_hostname,severity,discovered_at,closed_at,owner_team:

# MTTR (Mean Time To Remediate) por equipo, en días
awk -F',' 'NR > 1 && $5 != "" {
  split($4, d1, "T"); split($5, d2, "T");
  cmd_d1 = mktime(gensub(/[-:]/," ","3, "g, d1[1]" "substr(d1[2],1,8)));
  cmd_d2 = mktime(gensub(/[-:]/," ","3, "g, d2[1]" "substr(d2[2],1,8)));
  days = (cmd_d2 - cmd_d1) / 86400;
  sum[$6] += days;
  count[$6]++;
}
END {
  printf "%-20s %10s %10sn", "team", "findings", "MTTR_days";
  for (t in sum) printf "%-20s %10d %10.1fn", t, count[t], sum[t]/count[t];
}' /tmp/scan_export.csv | sort -k3 -n

El output te da una tabla de tres columnas: equipo, cantidad de hallazgos cerrados en el período, y promedio de días para cerrar. La fila con el MTTR más alto es donde tienes que tener la conversación con gerencia. El ordenamiento por la tercera columna te lo entrega ya priorizado.

Segundo, SLA compliance. Asumimos que el SLA es 30 días para severity crítica, 90 para alta, 180 para media. Si tu SLA es distinto, ajusta los thresholds:

awk -F',' 'NR > 1 && $5 != "" {
  split($4, d1, "T"); split($5, d2, "T");
  cmd_d1 = mktime(gensub(/[-:]/," ","3, "g, d1[1]" "substr(d1[2],1,8)));
  cmd_d2 = mktime(gensub(/[-:]/," ","3, "g, d2[1]" "substr(d2[2],1,8)));
  days = (cmd_d2 - cmd_d1) / 86400;
  sla = ($3 == "critical") ? 30 : (($3 == "high") ? 90 : 180);
  compliant[$6] += (days <= sla ? 1 : 0);
  total[$6]++;
}
END {
  printf "%-20s %10s %10s %8sn", "team", "compliant", "total", "rate_pct";
  for (t in total) printf "%-20s %10d %10d %7.1f%%n", t, compliant[t], total[t], compliant[t]*100/total[t];
}' /tmp/scan_export.csv | sort -k4 -n

Tercero y más importante: porcentaje del estate con dueño verificado. Este es tu leading indicator. La fuente de verdad es el ownership.tsv que mantuviste en git, cruzado contra el descubrimiento fresco de nmap:

awk -F't' 'NR == 1 { next }
{
  if ($7 == "OWNED") owned++; else missing++;
}
END {
  total = owned + missing;
  printf "Estate con dueño verificado: %.1f%% (%d/%d)n", owned*100/total, owned, total;
  if (owned*100/total < 90) {
    print "ALERTA: por debajo del 90%, las otras métricas no son accionables."
    exit 1
  }
}' /tmp/ownership_audit.tsv

Si el script termina con exit 1, tu programa de vulnerabilidades está midiendo ficción. Si pasa del 90%, recién ahí las métricas que reporta tu CISO tienen sentido.

Lo que NO hacer cuando empezás un programa de ownership

La tentación cuando se lee este tipo de artículo es comprar una plataforma de CMDB o asset management. No lo hagas primero. Comprá después, si la escala lo justifica. El error que vemos en programas LATAM con 50-300 servidores es saltar directo a la herramienta sin hacer el trabajo de gobernanza que la herramienta soporta. Terminan con un CMDB que nadie mantiene, un dashboard que nadie mira, y el mismo backlog abierto que al principio.

Lo que sí hacer, en orden:

1. Auditar con nmap + el pipeline de bash de arriba. Tener el ownership_audit.tsv en git.
2. Reemplazar todos los owners departamentales por personas específicas o aliases de equipo con miembros identificables.
3. Poner el pre-commit hook que rechaza ownership.tsv con dueños departamentales o con más de 90 días de antigüedad.
4. Reportar las tres métricas — MTTR, SLA compliance, % ownership — durante 90 días antes de comprar cualquier herramienta.
5. Si después de 90 días la cobertura de ownership sigue por debajo del 90%, ahí tienes un problema de gobernanza que ninguna herramienta va a resolver.

Conclusión: el problema no es del escáner, es del organigrama

Sharma termina el artículo con una frase que vale la pena repetir tal cual: “Your scanners are fine. Go find out who owns your servers.” La traducción operativa en una flota nuestra es la siguiente — corre el pipeline de descubrimiento hoy, mira el porcentaje de tu estate sin dueño, y dedica las próximas dos semanas a ponerle nombre y apellido a cada uno antes de mirar un solo CVE nuevo. El resto de las métricas de tu programa de vulnerabilidades dependen de esto.

Si tu scanner pasó de encontrar 200 hallazgos a 800 en un trimestre y nada se hizo menos seguro, no es que empeoraste. Es que dejaste de poder fingir que no sabías. El siguiente paso no es un scanner mejor. Es un CMDB que alguien mantiene.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux