¿Tu servidor ejecuta software con vulnerabilidades conocidas?

Un escaneo del sitio web ve lo que el servidor muestra al mundo: cabeceras, archivos expuestos, TLS. No puede ver que un paquete de Composer tres niveles más abajo, una dependencia npm del build o la biblioteca Python de un worker en segundo plano tiene un CVE publicado, y eso es justo lo que buscan los atacantes en cuanto se publica un exploit.

La única forma fiable es listar lo que realmente está instalado y compararlo con las bases de datos de vulnerabilidades. Eso es lo que hace esta comprobación, contra OSV y la lista de CISA de vulnerabilidades explotadas activamente (KEV).

El servidor se lee como una pila, de abajo arriba:

1. Sistema operativo: la distribución y el kernel.
2. Bibliotecas del sistema y software instalado: openssl, nginx, docker, redis…
3. Lenguajes y frameworks: PHP con Laravel, JavaScript con Vue, Python…
4. Bibliotecas de los lenguajes: los paquetes Composer, npm y PyPI de cada aplicación, directos y transitivos.

Con --docker también se lee cada contenedor en ejecución, en su sitio, sin exportar su imagen.

wpsbom es un único binario de código abierto para Linux y macOS. Solo lee archivos y no envía nada salvo que se lo pidas.

curl -fsSL https://raw.githubusercontent.com/ice-s/wpsbom/main/install.sh | sh

No puede adivinar dónde está tu código, así que indica cada directorio de aplicación con --path, tantos como necesites:

sudo wpsbom scan / --path /srv/shop --path /srv/worker --docker \
  --out-dir scans/ -o cyclonedx-json

Unos segundos después, scans/ contiene un archivo para el servidor y uno por cada imagen de contenedor. Luego inicia sesión, abre Mi servidor desde el menú de la cuenta, ponle nombre al proyecto, elige Servidor y suelta el archivo:

• Solo las bibliotecas de las aplicaciones, sin paquetes del sistema operativo: --no-os.
• Una sola imagen: wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json.
• También sirven archivos de syft, Trivy o cdxgen (CycloneDX o SPDX JSON).

La pila de software resume el servidor: cada bloque muestra sus paquetes y las vulnerabilidades abiertas por severidad, y su borde izquierdo toma el color de la más grave. Haz clic en un bloque para ver solo esa parte.

La lista de vulnerabilidades se organiza de la misma forma. Ubicación indica a qué aplicación pertenece un paquete y si es una dependencia directa o transitiva; Corregido en da la versión y el comando para copiar.

1. Explotadas (KEV) y Críticas: se están usando contra servidores reales; actualiza hoy.
2. Dependencias directas de tus aplicaciones: al actualizarlas normalmente se obtienen versiones corregidas de las transitivas.
3. Los paquetes dev (herramientas de build) importan menos en un servidor de producción, salvo que el build se ejecute allí.

Después de actualizar, vuelve a escanear y a subir el archivo: la lista muestra lo que queda. Para mantenerla al día sin hacerlo a mano, crea un token de API en Integraciones y deja que wpsbom envíe el escaneo, por ejemplo desde un cron job diario:

export WPSBOM_TOKEN=wp_…
sudo -E wpsbom push / --project demo-web-01 \
  --path /srv/shop --path /srv/worker --docker

¿Watchpost se conecta a mi servidor? No. Tú ejecutas el escaneo; solo se lee el archivo que subes.

¿Qué se envía? Nombres de paquetes, versiones y las rutas de los archivos de bloqueo (lock files). Nada de código fuente, configuración ni secretos. El nombre del host se reemplaza por un hash, el archivo subido no se conserva y los proyectos solo son visibles para tu cuenta.

¿Qué sistemas? wpsbom lee paquetes de Debian, Ubuntu y Alpine y bibliotecas de Composer, npm / yarn, PyPI, Go y RubyGems; las bibliotecas de Maven y NuGet también se cotejan cuando el archivo proviene de otra herramienta. Los paquetes del sistema operativo se listan, pero todavía no se cotejan con vulnerabilidades.

¿Kubernetes? wpsbom k8s se ejecuta en el clúster y vincula cada workload con el escaneo de su imagen.