¿Sabes realmente qué software está instalado en todos tus servidores Linux? La respuesta suele parecer sencilla hasta que una vulnerabilidad crítica afecta a OpenSSL, OpenSSH, glibc, Apache, PostgreSQL, una biblioteca de Python o alguna dependencia utilizada por una aplicación.
En ese momento aparece la pregunta que puede consumir horas de trabajo: ¿qué servidores tienen instalada la versión vulnerable?
Linux permite automatizar este problema combinando los gestores de paquetes tradicionales con herramientas open source como Syft, Grype y Trivy. El resultado puede convertirse en un inventario actualizado de servidores, paquetes, versiones, bibliotecas, contenedores y vulnerabilidades conocidas.
La idea es pasar de administrar servidores preguntando manualmente qué tienen instalado a disponer de algo mucho más útil:
Servidor Software Versión Vulnerabilidad
web-01 openssl 3.x Sin hallazgos
web-02 nginx x.x CVE-XXXX-XXXX
db-01 postgresql x.x Revisar
app-01 log4j-core x.x CVE-XXXX-XXXX
app-02 requests x.x Actualización disponibleY, todavía mejor, hacer que ese inventario se regenere automáticamente.
Puede leer también | Las mejores herramientas de código abierto para proteger su servidor Linux
El primer problema de seguridad: no saber qué tienes instalado
Antes de parchear una vulnerabilidad hay que responder una pregunta aparentemente trivial:
¿dónde está instalado el software afectado?
En cinco servidores puede comprobarse manualmente.
En cincuenta comienza a ser incómodo.
En quinientos puede convertirse en un verdadero problema de gestión.
Imagine que se publica una vulnerabilidad grave en una biblioteca determinada. El equipo de seguridad necesita saber inmediatamente:
- Qué servidores utilizan ese componente.
- Qué versión tiene cada uno.
- Qué sistema operativo lo instaló.
- Si procede del repositorio oficial o de otra fuente.
- Si existe una versión corregida.
- Qué aplicaciones dependen de él.
- Qué equipos deben priorizarse.
Sin un inventario actualizado, cada incidente comienza prácticamente desde cero.
Inventario no significa únicamente listar paquetes RPM o DEB
Un administrador puede pensar que basta con ejecutar:
dpkg -lo:
rpm -qapero un servidor moderno puede contener software instalado mediante muchas vías diferentes.
| Origen | Ejemplos |
|---|---|
| Paquetes del sistema | DEB, RPM, APK, paquetes Arch |
| Python | pip, virtualenv, Poetry |
| JavaScript | npm, yarn, pnpm |
| Java | JAR, Maven, Gradle |
| PHP | Composer |
| Rust | Cargo |
| Go | Binarios y módulos |
| Contenedores | Docker, Podman, OCI |
| Instalaciones manuales | /opt, /usr/local, binarios descargados |
Por ello, el verdadero objetivo debería ser disponer de un inventario de composición de software y no solamente de la salida del gestor de paquetes.
Primer nivel: inventariar los paquetes nativos de Linux
Antes de incorporar herramientas adicionales podemos obtener rápidamente una fotografía básica del sistema.
Debian y Ubuntu
dpkg-query -W -f='${binary:Package}\t${Version}\n'Podemos guardarla:
dpkg-query -W -f='${binary:Package}\t${Version}\n' > paquetes-debian.txtRHEL, Rocky Linux, AlmaLinux y Fedora
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n'Y guardar el resultado:
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' > paquetes-rpm.txtArch Linux
pacman -QAlpine Linux
apk info -vEstos comandos proporcionan una excelente primera fotografía.
Pero continúan teniendo una limitación: solo conocen correctamente lo que administra su propio gestor de paquetes.
El verdadero salto: crear un SBOM del servidor
Un Software Bill of Materials o SBOM puede entenderse como la lista de ingredientes del software.
En lugar de limitarse a indicar que existe una aplicación, intenta identificar sus componentes, nombres, versiones y otros metadatos de manera estructurada.
Dos de los formatos más conocidos son:
- CycloneDX
- SPDX
Esto permite almacenar el inventario en un formato que otras herramientas pueden analizar automáticamente.
La diferencia conceptual es importante.
ANTES -------------------------------- Servidor -> lista de paquetes AHORA -------------------------------- Servidor | v Inventario automático | v SBOM | +---- paquetes +---- versiones +---- bibliotecas +---- componentes | v Motor de vulnerabilidades | v CVE y acciones de remediación
Syft: generar automáticamente el inventario
Syft es una herramienta open source desarrollada por Anchore para generar SBOM a partir de sistemas de archivos, imágenes de contenedores y otros artefactos.
Puede identificar paquetes del sistema y numerosos ecosistemas de desarrollo.
Una vez instalado, una primera prueba puede realizarse con:
sudo syft scan dir:/Esto analiza el sistema de archivos y muestra los paquetes detectados.
Para guardar el resultado como CycloneDX:
sudo mkdir -p /var/lib/software-inventory
sudo syft scan dir:/ \
-o cyclonedx-json=/var/lib/software-inventory/$(hostname)-$(date +%F).cdx.jsonDespués de ejecutarlo podríamos tener algo como:
/var/lib/software-inventory/
web-01-2026-10-03.cdx.jsonEse archivo ya puede almacenarse, compararse, centralizarse o analizarse con otra herramienta.
¿Qué puede encontrar Syft?
Syft dispone de diferentes catalogadores capaces de identificar software procedente de múltiples ecosistemas.
Entre ellos se encuentran paquetes:
- DEB.
- RPM.
- APK.
- Arch Linux.
- Python.
- Java.
- JavaScript.
- Go.
- Ruby.
- Rust.
- PHP.
- Binarios conocidos.
Esto permite construir un inventario mucho más útil que una simple lista generada por dpkg o RPM.
Ahora viene la segunda parte: ¿cuáles son vulnerables?
Un SBOM nos dice qué tenemos.
Pero todavía necesitamos responder:
¿alguno de esos componentes aparece asociado a una vulnerabilidad conocida?
Aquí puede entrar Grype.
Grype: comparar el inventario contra vulnerabilidades conocidas
Grype es otro proyecto open source de Anchore.
Puede analizar:
- Sistemas de archivos.
- Imágenes de contenedores.
- SBOM previamente generados.
Si ya tenemos el archivo creado con Syft:
grype sbom:/var/lib/software-inventory/web-01-2026-10-03.cdx.jsonGrype comparará los componentes identificados con su base de datos de vulnerabilidades conocidas.
El resultado puede incluir información similar a:
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY package-a 1.2.3 1.2.5 CVE-XXXX-XXXX High package-b 4.5.0 4.5.1 CVE-YYYY-YYYY Critical
Esto cambia completamente la utilidad del inventario.
Ya no sabemos solamente qué paquetes existen.
Ahora podemos comenzar a priorizar cuáles necesitan atención.
Syft y Grype forman una combinación especialmente útil
La arquitectura puede quedar así:
SERVIDOR LINUX
|
v
Syft
|
v
SBOM CycloneDX
|
v
Grype
|
v
Vulnerabilidades
|
v
Informe / alerta
Además, el SBOM puede conservarse independientemente del análisis.
Esto significa que no es necesario volver a inspeccionar todo el servidor cada vez que queremos analizar nuevamente la misma composición de software.
Una alternativa muy práctica: Trivy
Trivy es otra herramienta open source ampliamente utilizada para análisis de vulnerabilidades.
Puede trabajar con imágenes de contenedores, sistemas de archivos, hosts y proyectos.
Para analizar paquetes del sistema operativo instalados en un host Linux puede utilizarse:
sudo trivy rootfs --pkg-types os --scanners vuln /Este comando está orientado específicamente a identificar paquetes administrados por el sistema operativo y compararlos con fuentes de vulnerabilidades correspondientes a la distribución.
¿Por qué es importante que Trivy conozca la distribución?
Porque comparar únicamente números de versión puede producir conclusiones incorrectas.
Distribuciones empresariales y de soporte prolongado suelen aplicar backports de parches de seguridad.
Imagine:
Proyecto upstream: versión corregida 3.2.5 Distribución Linux: 3.2.1-ubuntu4.8
El número puede parecer antiguo, pero el proveedor podría haber incorporado el parche de seguridad sin actualizar a la versión upstream completa.
Por eso un buen escáner debe considerar los avisos de seguridad específicos del proveedor y no comparar versiones de manera ingenua.
Trivy utiliza precisamente fuentes de seguridad correspondientes a distribuciones como Debian, Ubuntu, Red Hat, AlmaLinux, Rocky Linux y otras.
Puede leer también | Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
Trivy también puede buscar dependencias de aplicaciones
Cuando necesitamos revisar un proyecto alojado en el servidor podemos utilizar:
trivy fs /ruta/de/la/aplicacionTrivy puede localizar archivos de dependencias utilizados por diferentes ecosistemas.
Por ejemplo:
package-lock.json Pipfile.lock poetry.lock Cargo.lock Gemfile.lock
Esto resulta importante porque las vulnerabilidades de una aplicación no siempre proceden de los paquetes instalados por Linux.
Un servidor puede estar actualizado y una aplicación seguir siendo vulnerable
Este escenario es extremadamente habitual.
El administrador ejecuta:
apt update
apt upgradey concluye que el servidor está completamente actualizado.
Sin embargo, dentro de:
/var/www/aplicacion/podría existir:
node_modules/ vendor/ venv/ libs/
con dependencias antiguas administradas por npm, Composer, pip u otro gestor.
Por eso el inventario debe analizar dos niveles:
| Nivel | Ejemplos |
|---|---|
| Sistema operativo | openssl, ssh, systemd, glibc, nginx |
| Aplicaciones | npm, pip, Composer, Maven, Go, Rust |
OSV-Scanner puede complementar la revisión de proyectos
Para repositorios y aplicaciones también puede utilizarse OSV-Scanner.
El proyecto analiza dependencias y las compara con vulnerabilidades registradas en OSV.
Por ejemplo:
osv-scanner scan -r /var/www/mi-aplicacion/OSV-Scanner puede trabajar con numerosos archivos utilizados por los ecosistemas modernos, incluyendo:
package-lock.json yarn.lock pnpm-lock.yaml go.mod Cargo.lock composer.lock poetry.lock requirements.txt Gemfile.lock pom.xml
Para dependencias es preferible analizar archivos de bloqueo cuando estén disponibles porque reflejan con mayor precisión las versiones realmente seleccionadas.
No olvides los contenedores
Otro error frecuente consiste en inventariar perfectamente el host y olvidar que gran parte del software real está dentro de Docker o Podman.
Puede existir un servidor Linux con solamente veinte paquetes relevantes y, sobre él, veinte contenedores que contienen miles de componentes adicionales.
Con Syft podemos analizar una imagen:
syft nginx:latestO generar su SBOM:
syft nginx:latest -o cyclonedx-json=nginx.cdx.jsonCon Grype:
grype nginx:latestY con Trivy:
trivy image nginx:latestEn producción, lo apropiado es analizar las versiones o digest concretos realmente desplegados y no confiar únicamente en etiquetas variables como latest.
¿Qué debería contener el inventario central?
Como mínimo resulta útil registrar:
| Campo | Ejemplo |
|---|---|
| Servidor | web-prod-01 |
| Dirección | 10.10.20.15 |
| Distribución | Ubuntu / Debian / Rocky Linux |
| Versión del SO | Versión instalada |
| Paquete | openssl |
| Versión | Versión instalada |
| Origen | DEB / RPM / pip / npm / binario |
| CVE | CVE-AAAA-NNNN |
| Severidad | Critical / High / Medium / Low |
| Corrección disponible | Sí / No |
| Fecha del análisis | 2026-10-03 |
Automatizar el inventario diariamente
Una vez que Syft y Grype funcionan manualmente, podemos automatizar el proceso.
Por ejemplo, creamos:
/usr/local/sbin/inventario-software.shcon el siguiente contenido:
#!/bin/bash
set -euo pipefail
HOST="$(hostname -s)"
FECHA="$(date +%F)"
DIRECTORIO="/var/lib/software-inventory"
mkdir -p "$DIRECTORIO"
SBOM="$DIRECTORIO/${HOST}-${FECHA}.cdx.json"
VULN="$DIRECTORIO/${HOST}-${FECHA}-vulnerabilidades.txt"
syft scan dir:/ \
-o cyclonedx-json="$SBOM"
grype "sbom:$SBOM" \
> "$VULN"Asignamos permisos:
sudo chmod 750 /usr/local/sbin/inventario-software.shY podemos probarlo:
sudo /usr/local/sbin/inventario-software.shAl finalizar tendremos:
web01-2026-10-03.cdx.json web01-2026-10-03-vulnerabilidades.txt
Automatizarlo con systemd timer
En lugar de depender únicamente de cron podemos crear una unidad systemd.
Archivo:
/etc/systemd/system/software-inventory.serviceContenido:
[Unit]
Description=Inventario y analisis de vulnerabilidades del servidor
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/inventario-software.shLuego creamos:
/etc/systemd/system/software-inventory.timercon:
[Unit]
Description=Ejecutar inventario de software diariamente
[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=30m
[Install]
WantedBy=timers.targetActivamos:
sudo systemctl daemon-reload
sudo systemctl enable --now software-inventory.timerY comprobamos:
systemctl list-timers software-inventory.timer¿Por qué utilizar RandomizedDelaySec?
Cuando tenemos cien servidores no resulta ideal que todos comiencen simultáneamente un escaneo a medianoche.
Con:
RandomizedDelaySec=30msystemd distribuye el inicio dentro de una ventana temporal.
Esto reduce picos simultáneos de CPU, disco, red y consultas a fuentes externas.
El siguiente paso: centralizar los resultados
Generar cien SBOM almacenados únicamente dentro de cien servidores soluciona solo la mitad del problema.
Lo ideal es enviarlos a una ubicación central.
Servidor 01 ----\
Servidor 02 -----\
Servidor 03 ------> Repositorio central
Servidor 04 -----/ |
Servidor 05 ----/ v
Análisis
|
v
Dashboard
Ese repositorio puede estar en:
- Un servidor de gestión.
- Almacenamiento de objetos.
- Un repositorio protegido.
- Una plataforma especializada de gestión de SBOM.
El acceso debe restringirse porque un inventario detallado de software también proporciona información valiosa sobre la infraestructura.
Ansible puede inventariar decenas o cientos de servidores
Cuando ya existe Ansible, no es necesario conectarse manualmente por SSH a cada servidor.
Podemos ejecutar comandos sobre un grupo completo.
Por ejemplo:
ansible linux_servers -m shell -a \
'dpkg-query -W -f="${binary:Package}\t${Version}\n"' \
--becomeEn entornos RPM podría utilizarse:
ansible rpm_servers -m shell -a \
'rpm -qa --qf "%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n"' \
--becomeUna arquitectura más madura puede instalar Syft mediante Ansible, generar el SBOM localmente y recuperar los resultados hacia un servidor central.
Una arquitectura práctica para una empresa
ANSIBLE
|
+----------------+----------------+
| | |
v v v
web-01 db-01 app-01
| | |
Syft Syft Syft
| | |
+-------- SBOM --+------ SBOM ----+
|
v
Repositorio central
|
+--------+---------+
| |
v v
Grype Trivy
| |
+--------+---------+
|
v
Vulnerabilidades
|
v
Ticket / Alerta
El inventario deja así de ser un documento estático elaborado una vez al año.
Se convierte en información que puede regenerarse continuamente.
No todas las vulnerabilidades detectadas tienen el mismo riesgo
Otro error común es recibir 500 CVE y comenzar simplemente por el que tenga el número CVSS más alto.
La priorización debería considerar también:
| Factor | Pregunta |
|---|---|
| Severidad | ¿Qué impacto técnico tiene? |
| Exposición | ¿El servicio está accesible desde Internet? |
| Uso real | ¿El componente vulnerable se ejecuta realmente? |
| Exploit conocido | ¿Existe explotación activa o código disponible? |
| Criticidad | ¿Qué proceso empresarial soporta el servidor? |
| Corrección | ¿Existe ya un paquete actualizado? |
Un CVE crítico en un paquete que no se utiliza puede tener una prioridad distinta de una vulnerabilidad alta en un servicio público explotado activamente.
Un hallazgo del escáner no debe convertirse automáticamente en verdad absoluta
Las herramientas automatizadas son fundamentales, pero necesitan interpretación.
Pueden existir:
- Falsos positivos.
- Falsos negativos.
- Paquetes parcheados mediante backport.
- Software instalado desde repositorios de terceros.
- Binarios compilados manualmente.
- Componentes que el escáner no puede identificar.
Por ello, cualquier vulnerabilidad crítica debería verificarse contra el aviso oficial de seguridad de la distribución o del proveedor correspondiente.
El inventario debe registrar también el sistema operativo
Conviene capturar:
cat /etc/os-releaseTambién resulta útil conocer:
uname -ry la arquitectura:
uname -mUna vulnerabilidad puede afectar únicamente a determinadas versiones de una distribución, kernel o arquitectura.
No olvides detectar sistemas fuera de soporte
Un servidor puede no mostrar una larga lista de CVE simplemente porque su distribución dejó de recibir información y actualizaciones de seguridad.
Por eso el inventario debería indicar también:
SO soportado -> OK SO próximo a EOL -> Planificar migración SO fuera de soporte -> Riesgo alto
Un sistema operativo fuera de soporte debe tratarse como un problema de seguridad incluso cuando aparentemente siga funcionando perfectamente.
¿Cada cuánto generar el inventario?
Para servidores empresariales, una frecuencia diaria suele resultar razonable.
También puede generarse cada vez que ocurra alguno de estos eventos:
- Después de instalar paquetes.
- Después de aplicar parches.
- Después de desplegar una aplicación.
- Después de actualizar un contenedor.
- Después de modificar una imagen base.
En pipelines CI/CD, lo ideal es generar el SBOM durante el proceso de construcción y conservarlo junto con el artefacto desplegado.
Guardar históricos permite detectar cambios inesperados
Supongamos que ayer el servidor tenía:
1.248 paquetes
y hoy aparecen:
1.291 paquetes
Puede existir una explicación perfectamente válida.
Pero también puede ser una señal de que alguien instaló software sin pasar por el procedimiento habitual.
Conservar históricos permite comparar:
inventario lunes
|
v
inventario martes
|
v
+43 paquetes
|
v
¿Quién los instaló y por qué?
El inventario puede convertirse así también en una herramienta de control de cambios.
Un SBOM no reemplaza un escáner de red
Herramientas como Greenbone/OpenVAS cumplen otra función.
Un SBOM y un escáner como Grype intentan comprender principalmente la composición del software.
Un escáner de vulnerabilidades de red observa los servicios expuestos y cómo se comportan desde otra perspectiva.
Ambos enfoques son complementarios:
SBOM / SCA
"¿Qué software tengo?"
+
Escáner de red
"¿Qué servicios están expuestos?"
+
Configuración
"¿Cómo están configurados?"
=
Visión mucho más completa
Puede leer también | Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos
¿Qué herramienta elegir?
| Herramienta | Uso recomendado |
|---|---|
| dpkg-query / rpm / pacman / apk | Inventario rápido de paquetes del sistema |
| Syft | Generar SBOM e identificar componentes |
| Grype | Analizar SBOM y localizar vulnerabilidades |
| Trivy | Hosts, proyectos, contenedores y vulnerabilidades |
| OSV-Scanner | Dependencias de proyectos y repositorios |
| Ansible | Automatizar el proceso en muchos servidores |
| Greenbone/OpenVAS | Evaluación de vulnerabilidades desde la red |
Stack recomendado completamente open source
Para una empresa que quiera empezar sin desplegar una plataforma excesivamente compleja:
Inventario del host
|
Syft
|
v
CycloneDX / SPDX
|
+---------> Grype
|
+---------> Archivo histórico
|
v
Repositorio central
Aplicaciones ----------> Trivy / OSV-Scanner
Automatización --------> Ansible + systemd timers
Este esquema permite comenzar con pocos servidores y escalar gradualmente.
Checklist para implementar un inventario real de software Linux
- Identificar todos los servidores Linux.
- Registrar distribución, versión y arquitectura.
- Inventariar paquetes administrados por el sistema.
- Buscar software instalado por otros gestores.
- Inventariar aplicaciones y dependencias.
- Analizar imágenes de contenedores.
- Generar un SBOM por servidor o aplicación.
- Centralizar los SBOM.
- Compararlos contra bases de vulnerabilidades.
- Clasificar hallazgos por severidad y exposición.
- Verificar los hallazgos críticos contra fuentes oficiales.
- Definir responsables de remediación.
- Aplicar los parches.
- Generar nuevamente el inventario.
- Conservar históricos.
- Automatizar todo el ciclo.
Recomendamos
- Las mejores herramientas de código abierto para proteger su servidor Linux
- Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
- Wolfi: una versión de Linux con medidas de seguridad para la cadena de suministro de software
- Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos
En resumen
No se puede gestionar correctamente una vulnerabilidad si primero no sabemos dónde está instalado el software afectado.
Los gestores tradicionales como dpkg, RPM, pacman y apk proporcionan una primera capa de inventario, pero los servidores modernos también contienen dependencias Python, Java, JavaScript, PHP, Rust, Go, contenedores y software instalado manualmente.
Herramientas como Syft permiten generar un SBOM estructurado del entorno. Grype puede utilizar posteriormente ese inventario para detectar vulnerabilidades conocidas. Trivy permite analizar tanto paquetes del sistema como aplicaciones y contenedores, mientras OSV-Scanner ofrece otra vía para revisar dependencias de proyectos.
Con Ansible, systemd timers y un repositorio central puede automatizarse todo el proceso para decenas o cientos de servidores.
Conclusión editorial
El mayor problema de muchas organizaciones no es que tengan software vulnerable. Es que descubren demasiado tarde dónde lo tienen instalado.
Cuando aparece una vulnerabilidad crítica, el equipo de seguridad no debería comenzar enviando mensajes para preguntar quién utiliza determinada biblioteca.
Debería poder consultar inmediatamente un inventario y responder:
37 servidores analizados 8 contienen el componente 3 tienen una versión afectada 2 están expuestos a Internet 1 soporta un servicio crítico
Eso transforma completamente la gestión de vulnerabilidades.
Un inventario automatizado también permite detectar servidores olvidados, paquetes instalados sin autorización, versiones fuera de soporte y diferencias inesperadas entre sistemas que deberían ser iguales.
El concepto de SBOM lleva esta idea todavía más lejos: convierte la composición del software en información estructurada, reutilizable y comprensible por diferentes herramientas.
Con Linux y software libre, construir esta capacidad no requiere necesariamente adquirir una plataforma empresarial costosa.
Syft puede descubrir qué existe. Grype y Trivy pueden ayudar a determinar qué está afectado. Ansible puede ejecutar el proceso a escala. Y CycloneDX o SPDX permiten conservar un inventario estándar para volver a analizarlo cuando mañana aparezca una nueva vulnerabilidad.
Porque la mejor pregunta ante el próximo CVE crítico no debería ser:
“¿Tendremos ese software instalado en algún servidor?”
Sino:
“¿En cuáles está instalado, qué versión tienen y cuáles debemos corregir primero?”
Fuentes: Anchore Syft — SBOM Generation, Anchore Grype — Vulnerability Scanning, Trivy — Vulnerability Scanning, OSV-Scanner, CycloneDX y SPDX.
Etiquetas: Linux, servidores Linux, inventario de software, vulnerabilidades, CVE, Syft, Grype, Trivy, OSV-Scanner, SBOM, CycloneDX, SPDX, ciberseguridad, software libre, gestión de vulnerabilidades.
