Il tuo server esegue software con vulnerabilità note?

Una scansione del sito web vede ciò che il server mostra al mondo: header, file esposti, TLS. Non può vedere che un pacchetto Composer tre livelli più in basso, una dipendenza npm della build o la libreria Python di un worker in background hanno una CVE pubblicata, ed è proprio ciò che gli attaccanti cercano non appena un exploit diventa pubblico.

L'unico metodo affidabile è elencare ciò che è effettivamente installato e confrontarlo con i database delle vulnerabilità. È ciò che fa questo controllo, usando OSV e l'elenco CISA delle vulnerabilità sfruttate attivamente (KEV).

Il server viene letto come uno stack, dal basso verso l'alto:

1. Sistema operativo: la distribuzione e il kernel.
2. Librerie di sistema e software installato: openssl, nginx, docker, redis…
3. Linguaggi e framework: PHP con Laravel, JavaScript con Vue, Python…
4. Librerie dei linguaggi: i pacchetti Composer, npm e PyPI di ogni applicazione, diretti e transitivi.

Con --docker viene letto anche ogni container in esecuzione, sul posto, senza esportarne l'immagine.

wpsbom è un singolo binario open source per Linux e macOS. Si limita a leggere i file e non invia nulla a meno che tu non lo chieda.

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

Non può indovinare dove si trova il tuo codice, quindi indica ogni directory applicativa con --path, tante quante ne servono:

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

Pochi secondi dopo scans/ contiene un file per il server e uno per ogni immagine di container. Poi accedi, apri Il mio server dal menu dell'account, assegna un nome al progetto, scegli Server e trascina il file:

• Solo librerie applicative, senza pacchetti del sistema operativo: --no-os.
• Una singola immagine: wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json.
• Funzionano anche i file generati da syft, Trivy o cdxgen (CycloneDX o SPDX JSON).

Lo stack software riassume il server: ogni blocco mostra i suoi pacchetti e le vulnerabilità aperte per gravità, e il suo bordo sinistro assume il colore della più grave. Fai clic su un blocco per vedere solo quella parte.

L'elenco delle vulnerabilità è annidato allo stesso modo. Posizione indica a quale applicazione appartiene un pacchetto e se è una dipendenza diretta o transitiva; Corretto in riporta la versione e il comando da copiare.

1. Sfruttate (KEV) e Critiche: vengono usate contro server reali; aggiorna oggi stesso.
2. Dipendenze dirette delle tue applicazioni: aggiornarle di solito porta con sé versioni corrette di quelle transitive.
3. I pacchetti dev (strumenti di build) contano meno su un server di produzione, a meno che la build non venga eseguita lì.

Dopo l'aggiornamento, scansiona e carica di nuovo: l'elenco mostra ciò che resta. Per mantenerlo aggiornato senza farlo a mano, crea un token API in Integrazioni e lascia che sia wpsbom a inviare la scansione, ad esempio da un cron job giornaliero:

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

Watchpost si connette al mio server? No. Sei tu a eseguire la scansione; viene letto solo il file che carichi.

Cosa viene inviato? Nomi dei pacchetti, versioni e percorsi dei lock file. Nessun codice sorgente, configurazione o segreto. Il nome host viene sostituito da un hash, il file caricato non viene conservato e i progetti sono visibili solo al tuo account.

Quali sistemi? wpsbom legge i pacchetti Debian, Ubuntu e Alpine e le librerie Composer, npm / yarn, PyPI, Go e RubyGems; anche le librerie Maven e NuGet vengono confrontate quando il file proviene da un altro strumento. I pacchetti del sistema operativo vengono elencati ma non ancora confrontati con le vulnerabilità.

Kubernetes? wpsbom k8s viene eseguito nel cluster e collega ogni workload alla scansione della sua immagine.