Seu servidor roda software com vulnerabilidades conhecidas?

Um scan de site vê o que o servidor mostra ao mundo: cabeçalhos, arquivos expostos, TLS. Ele não consegue ver que um pacote Composer três níveis abaixo, uma dependência npm do build ou a biblioteca Python de um worker em segundo plano tem uma CVE publicada — e é exatamente isso que os atacantes procuram assim que um exploit se torna público.

A única forma confiável é listar o que está realmente instalado e comparar com as bases de dados de vulnerabilidades. É o que esta verificação faz, com base no OSV e na lista da CISA de vulnerabilidades exploradas ativamente (KEV).

O servidor é lido como uma stack, de baixo para cima:

1. Sistema operacional: a distribuição e o kernel.
2. Bibliotecas do sistema e software instalado: openssl, nginx, docker, redis…
3. Linguagens e frameworks: PHP com Laravel, JavaScript com Vue, Python…
4. Bibliotecas das linguagens: os pacotes Composer, npm e PyPI de cada aplicação, diretos e transitivos.

Com --docker, cada contêiner em execução também é lido, no próprio lugar, sem exportar a imagem.

O wpsbom é um único binário open source para Linux e macOS. Ele apenas lê arquivos e não envia nada, a menos que você peça.

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

Ele não tem como adivinhar onde está o seu código, então indique cada diretório de aplicação com --path, quantos forem necessários:

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

Alguns segundos depois, scans/ contém um arquivo para o servidor e um para cada imagem de contêiner. Em seguida, entre na sua conta, abra Meu servidor no menu da conta, dê um nome ao projeto, escolha Servidor e solte o arquivo:

• Apenas as bibliotecas das aplicações, sem os pacotes do SO: --no-os.
• Uma única imagem: wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json.
• Arquivos do syft, Trivy ou cdxgen também funcionam (JSON CycloneDX ou SPDX).

A stack de software resume o servidor: cada bloco mostra seus pacotes e as vulnerabilidades em aberto por severidade, e a borda esquerda assume a cor da mais grave. Clique em um bloco para ver só essa parte.

A lista de vulnerabilidades segue o mesmo agrupamento. Localização indica a qual aplicação um pacote pertence e se ele é uma dependência direta ou transitiva; Corrigido em mostra a versão e o comando para copiar.

1. Exploradas (KEV) e Críticas: estão sendo usadas contra servidores reais; atualize hoje.
2. Dependências diretas das suas aplicações: atualizá-las normalmente traz versões corrigidas das transitivas.
3. Pacotes dev (ferramentas de build) importam menos em um servidor de produção, a menos que o build rode nele.

Depois de atualizar, escaneie e envie novamente: a lista mostra o que falta. Para mantê-la em dia sem fazer isso à mão, crie um token de API em Integrações e deixe o wpsbom enviar o scan, por exemplo a partir de um cron job diário:

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

O Watchpost se conecta ao meu servidor? Não. Quem executa o scan é você; apenas o arquivo que você envia é lido.

O que é enviado? Nomes e versões de pacotes e os caminhos dos arquivos de lock. Nada de código-fonte, configuração ou segredos. O nome do host é substituído por um hash, o arquivo enviado em si não é guardado e os projetos ficam visíveis apenas para a sua conta.

Quais sistemas? O wpsbom lê pacotes Debian, Ubuntu e Alpine e bibliotecas Composer, npm / yarn, PyPI, Go e RubyGems; bibliotecas Maven e NuGet também são verificadas quando o arquivo vem de outra ferramenta. Os pacotes do SO são listados, mas ainda não são comparados com as vulnerabilidades.

Kubernetes? O wpsbom k8s roda no cluster e vincula cada workload ao scan da sua imagem.