Is your server running software with known vulnerabilities?

A website scan sees what the server shows to the world: headers, exposed files, TLS. It cannot see that a Composer package three levels down, an npm dependency of the build or the Python library of a background worker has a published CVE — and those are what attackers scan for as soon as an exploit is public.

The only reliable way is to list what is actually installed and compare it with the vulnerability databases. That is what this check does, against OSV and the CISA list of vulnerabilities exploited in the wild (KEV).

The server is read as a stack, from the bottom up:

1. Operating system: the distribution and kernel.
2. System libraries and installed software: openssl, nginx, docker, redis…
3. Languages and frameworks: PHP with Laravel, JavaScript with Vue, Python…
4. Language libraries: the Composer, npm and PyPI packages of each application, direct and transitive.

With --docker, every running container is read too, in place, without exporting its image.

wpsbom is a single open-source binary for Linux and macOS. It only reads files and sends nothing unless you ask it to.

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

It cannot guess where your code lives, so name each application directory with --path, as many as you need:

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

A few seconds later scans/ holds one file for the server and one per container image. Then sign in, open My Server from the account menu, name the project, choose Server and drop the file:

• Application libraries only, without OS packages: --no-os.
• A single image: wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json.
• Files from syft, Trivy or cdxgen work too (CycloneDX or SPDX JSON).

The software stack sums the server up: each block shows its packages and open vulnerabilities by severity, and its left edge takes the colour of the worst one. Click a block to see only that part.

The vulnerability list nests the same way. Location says which application a package belongs to and whether it is a direct or a transitive dependency; Fixed in gives the version and the command to copy.

1. Exploited (KEV) and Critical: these are being used against real servers; upgrade today.
2. Direct dependencies of your applications: upgrading them usually pulls fixed versions of the transitive ones.
3. dev packages (build tools) matter less on a production server, unless the build runs there.

After upgrading, scan and upload again: the list shows what is left. To keep it current without doing it by hand, create an API token under Integrations and let wpsbom send the scan, for example from a daily cron job:

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

Does Watchpost connect to my server? No. You run the scan; only the file you upload is read.

What is sent? Package names, versions and the paths of lock files. No source code, configuration or secrets. The host name is replaced by a hash, the uploaded file itself is not kept, and projects are visible to your account only.

Which systems? wpsbom reads Debian, Ubuntu and Alpine packages and Composer, npm / yarn, PyPI, Go and RubyGems libraries; Maven and NuGet libraries are matched too when the file comes from another tool. OS packages are listed but not matched against vulnerabilities yet.

Kubernetes? wpsbom k8s runs in the cluster and links each workload to the scan of its image.