Verificador de vulnerabilidades SBOM

Solte um lockfile ou uma SBOM e verifique cada versão fixada em busca de vulnerabilidades conhecidas — analisado localmente, comparado com o banco de dados OSV.

Um lockfile é a lista exata das versões que o seu build realmente instala — e cada versão fixada é uma aposta de que ninguém encontrou uma falha nela desde então. Este verificador lê essa lista (package-lock.json, requirements.txt, go.mod ou uma SBOM CycloneDX / SPDX), envia apenas os pares de nome e versão para o banco de dados público de vulnerabilidades OSV.dev e informa quais pacotes têm vulnerabilidades conhecidas, qual é a gravidade delas, qual versão corrige cada uma e se algum dos CVEs está na lista de vulnerabilidades conhecidamente exploradas da CISA. O guia complementar seu lockfile está escondendo vulnerabilidades? explica o que os resultados provam — e o que não provam. Se a verificação sinalizar um CVE, o painel Bulk CVE Triage coloca-o no contexto de exploração.

Última atualização:

Seu lockfile ou SBOM

Aceitos: package-lock.json, requirements.txt, go.mod, CycloneDX JSON, SPDX JSON. Tamanho máximo do arquivo: 5 MB.

O formato é detectado a partir do nome do arquivo e do conteúdo; você também pode escolhê-lo abaixo.

🔒 Seu lockfile é analisado no seu navegador e nunca é enviado. Apenas os nomes e as versões dos pacotes vão para o OSV.dev; apenas os identificadores CVE vão para o nosso próprio verificador, para a sinalização KEV.

Resultados da verificação

Nenhuma verificação ainda. Envie ou cole um lockfile ou uma SBOM acima e pressione “Verificar vulnerabilidades”.

Seu lockfile nunca sai desta página

A análise acontece inteiramente no seu navegador: o arquivo que você solta — ou o texto que você cola — é lido localmente e nunca é enviado para lugar nenhum. Apenas os nomes e as versões extraídos dos pacotes são enviados, para o banco de dados público de vulnerabilidades OSV.dev (sem conta, sem chave), para que ele possa compará-los com vulnerabilidades conhecidas. Os identificadores CVE das correspondências são então enviados ao verificador próprio deste site para uma consulta à lista KEV da CISA. Nada mais sai da página: nem o conteúdo do arquivo, nem caminhos, nem nomes de projetos.

Limites da verificação

No máximo 500 pacotes são verificados por execução — os extras são listados como não verificados. No máximo 200 detalhes de vulnerabilidades são buscados. Os resultados vêm do banco de dados OSV para as versões exatas do seu arquivo; uma versão de pacote que o banco de dados nunca viu não retorna correspondência, o que não é o mesmo que um atestado de boa saúde.

Os limites, com honestidade

“Nenhuma vulnerabilidade encontrada” significa nenhuma no banco de dados OSV para essas versões exatas. Não significa que o código seja seguro: vulnerabilidades que ninguém relatou ainda, pacotes maliciosos, nomes typosquat e versões comprometidas são todos invisíveis para uma verificação por correspondência de versão.

Uma correspondência é exata por versão. Se o seu arquivo fixa um intervalo em vez de uma versão exata, ele é ignorado e listado como tal — o verificador não vai adivinhar qual versão você realmente instalou. O mesmo vale para pacotes cujo ecossistema o verificador não consegue mapear: eles são listados como ignorados, nunca descartados em silêncio.

As sinalizações KEV vêm de uma única consulta ao verificador próprio deste site (dados KEV da CISA, atualizados diariamente). Se essa consulta falhar ou for limitada por taxa, a verificação ainda é concluída — a coluna KEV simplesmente diz “desconhecido” em vez de bloquear os seus resultados.

Por que a versão fixada é a superfície de ataque

Um lockfile existe porque “latest” não é uma versão. Ele registra a árvore exata que o seu build instalou, para que cada máquina e cada deploy recebam o mesmo código. Esse determinismo também é o que torna o lockfile verificável: um banco de dados de vulnerabilidades é indexado por pacote e versão exatos, então uma versão fixada pode ser julgada em uma única consulta, enquanto um intervalo flutuante não pode. A verificação, portanto, só é tão boa quanto o arquivo — faça commit do lockfile, mantenha-o atualizado, e o verificador poderá dizer a verdade sobre o que você entrega.

A verificação em si é deliberadamente restrita. O OSV.dev agrega registros de vulnerabilidades dos avisos do GitHub, do NVD e dos ecossistemas de linguagens, e os compara com as suas versões. O que ele não consegue fazer é julgar o código: um pacote sem CVE conhecido ainda pode ser malicioso, abandonado ou um sósia de um pacote que você pretendia instalar. A correspondência de versões é um primeiro filtro rápido e barato — aquele que pega o lodash que você esqueceu de atualizar — não uma auditoria de segurança.

Por que uma sinalização KEV vale mais do que uma pontuação CVSS alta

Uma pontuação CVSS mede o quão grave uma vulnerabilidade seria se fosse explorada. O catálogo de vulnerabilidades conhecidamente exploradas da CISA mede outra coisa: se ela está realmente sendo explorada, na prática, agora mesmo. Um CVE de gravidade média na lista KEV merece um patch esta semana; um CVE crítico que ninguém transformou em arma muitas vezes pode esperar pela próxima atualização planejada. É por isso que este verificador marca as linhas KEV separadamente e por isso os resultados são ordenados primeiro pela pior gravidade — mas o selo KEV é aquele em que se deve agir primeiro.

As versões corrigidas trazem seu próprio risco. A correção de uma vulnerabilidade geralmente é uma versão secundária ou de patch, mas “corrigido em 4.17.21” também pode significar uma mudança de comportamento que quebra o seu build, e algumas vulnerabilidades não têm nenhuma versão corrigida — o verificador diz isso claramente em vez de inventar uma. Corrija primeiro os itens KEV, depois os críticos com uma correção publicada e então agende o restante; fixe as novas versões, faça commit do lockfile e verifique novamente. O mesmo ciclo pertence ao CI, onde ele roda a cada pull request em vez de uma vez por trimestre.

Licenças nesta SBOM

As licenças listadas aqui vêm apenas dos campos de licença contidos na própria SBOM. Lockfiles (package-lock.json, requirements.txt, go.mod) não contêm dados de licença, então nada é exibido para eles — esta página não consulta licenças por pacote, porque nenhum banco de dados público as fornece de forma confiável.

Termos de lockfile e SBOM, definidos com precisão

Lockfile. Um arquivo que registra a versão exata de cada pacote que um build instala — package-lock.json para npm, requirements.txt com fixações == para Python, go.mod/go.sum para Go — para que as instalações sejam reproduzíveis.

SBOM. Software Bill of Materials: um inventário legível por máquina de cada componente de um software, geralmente em formato CycloneDX ou SPDX. É o lockfile generalizado para toda a cadeia de suprimentos.

OSV.dev. O banco de dados público de vulnerabilidades do Google, que agrega avisos do GitHub, do NVD e dos ecossistemas de linguagens, e pode ser consultado por nome exato de pacote, ecossistema e versão.

GHSA. Um identificador de aviso de segurança do GitHub (GHSA-xxxx-xxxx-xxxx). A maioria das vulnerabilidades de npm, PyPI e Go no OSV tem um, geralmente junto com um identificador CVE.

CVE. Common Vulnerabilities and Exposures: o esquema de numeração compartilhado (CVE-YYYY-NNNNN) que permite que todos os bancos de dados, verificadores e fornecedores falem sobre a mesma vulnerabilidade.

CVSS. Common Vulnerability Scoring System: uma pontuação de 0 a 10 para o quão grave uma vulnerabilidade seria se fosse explorada. 9,0 ou mais é CRITICAL, 7,0 ou mais HIGH, 4,0 ou mais MEDIUM, abaixo de 4,0 LOW.

KEV. O catálogo de vulnerabilidades conhecidamente exploradas da CISA: vulnerabilidades com exploração confirmada na prática, cada uma com uma data limite de correção. Uma sinalização KEV significa “corrija agora”, diga o que disser o CVSS.

Fixed version. A primeira versão de um pacote na qual uma vulnerabilidade já não está presente, obtida dos eventos de intervalo afetado do aviso. Algumas vulnerabilidades ainda não têm nenhuma publicada.

Purl. Package URL (pkg:npm/[email protected]): uma forma padrão de nomear um pacote com seu ecossistema e versão. As SBOMs trazem purls, e é assim que o verificador sabe a qual ecossistema um componente pertence.

Perguntas frequentes

Meu lockfile sai do meu navegador?

Não. O arquivo é analisado localmente e nunca é enviado. Apenas os nomes e as versões extraídos dos pacotes são enviados ao OSV.dev, um banco de dados público de vulnerabilidades, e apenas os identificadores CVE das correspondências são enviados ao verificador próprio deste site para a consulta KEV. O conteúdo do arquivo, os caminhos e os nomes de projetos nunca saem da página.

Por que um pacote aparece como “ignorado”?

Por três motivos: a linha não é uma fixação exata (um intervalo como ~= ou >=, uma inclusão -r, uma diretiva replace), o ecossistema não pode ser mapeado para um que o OSV.dev suporte, ou a verificação atingiu o limite de 500 pacotes. As entradas ignoradas são sempre listadas com o motivo — nada é descartado em silêncio.

“Nenhuma vulnerabilidade encontrada” — estou seguro?

Não necessariamente. Significa que nenhuma vulnerabilidade foi relatada para essas versões exatas no banco de dados OSV. Vulnerabilidades não relatadas, pacotes maliciosos ou typosquat e versões comprometidas não aparecem em nenhum banco de dados de vulnerabilidades. Trate a verificação como um primeiro filtro, não como um atestado de boa saúde.

O que devo corrigir primeiro?

Comece por tudo que traz um selo KEV — essas vulnerabilidades estão sendo exploradas agora, e a CISA define uma data limite para cada uma. Depois, as linhas CRITICAL e HIGH que têm uma versão corrigida publicada, começando pelos pacotes que o seu aplicativo realmente importa. Use o painel Bulk CVE Triage para o contexto de exploração de cada CVE.

Uma vulnerabilidade não tem versão corrigida. E agora?

Primeiro verifique se existe uma versão mais recente que o aviso ainda não registrou — os avisos ficam atrás das versões. Se realmente não houver correção, as suas opções são remover a dependência, substituí-la ou mitigar o caminho de código vulnerável (por exemplo, parar de passar entrada não confiável para a função afetada) e acompanhar o aviso para ver se é atualizado. Verifique novamente após qualquer mudança.