O único caso em que os dois lados coincidem é exatamente aquele em que o fornecedor enviou o CVSS ao NVD.

A causa não é ninguém escondendo nada: quando o fornecedor não envia a pontuação, a CISA-ADP atribui automaticamente uma nota com base no pior cenário, e a maioria das ferramentas SCA usa o valor do NVD. Isso não é um Bug, são os critérios de dois sistemas de avaliação distintos — mas o seu fluxo de resposta a incidentes está seguindo o 9.8.

E a segunda coisa: a versão que o fornecedor manda você atualizar pode nem existir para download

Teste real (com controle positivo, reexecutado a cada geração da tabela de regras):

Na tabela oficial de versões de correção, essas versões estão marcadas como Enterprise Support Only — disponíveis apenas para clientes com suporte comercial. Então, se você realmente for afetado, suas opções são: atualizar para uma versão principal diferente ou comprar suporte comercial.

Uso

Requer JDK 17+. Zero dependências em tempo de execução, sem conexão com a internet.

Código de saída: 0 versão não afetada · 2 versão afetada mas nenhuma condição de acionamento encontrada · 3 condições de acionamento também confirmadas.

Como é a saída

O outro lado — por que as outras 7 não diferem

A tabela acima pode dar a impressão de que "o NVD sempre pontua errado". Não é verdade. No mesmo lote de dados há outras 7 vulnerabilidades em que a classificação oficial e a do NVD são exatamente iguais:

Não há contraexemplos em nenhuma das duas direções, e este é o único julgamento causal que esta ferramenta se atreve a fazer:

• 7 vulnerabilidades com classificação consistente → a fonte da pontuação é sempre [email protected] (enviada pelo próprio fornecedor)
• 8 vulnerabilidades com classificação inconsistente → a fonte da pontuação é sempre CISA-ADP (fornecedor não enviou; um terceiro pontuou automaticamente pelo pior cenário)

O script de geração usa duas asserções para monitorar cada direção (ASSERT4 / ASSERT7); se qualquer contraexemplo aparecer, a tabela é recusada.

🔑 Por que validar as duas direções: o fato de que "as consistentes são todas autoavaliações do fornecedor" não exclui que "algumas inconsistentes também sejam autoavaliações do fornecedor". Se um item assim aparecesse, a causalidade teria um contraexemplo, e validar apenas uma direção ainda geraria a tabela inteira, toda verde. Uma asserção unilateral não prova causalidade.

Critérios — leia tudo antes de concluir

• "Não afetado" não significa "seguro". A condição de acionamento pode estar em uma biblioteca de terceiros da qual você depende, pode ser aplicada por variáveis de ambiente ou por um centro de configuração, ou você simplesmente pode não ter passado o diretório do código-fonte. O relatório sempre diz "não encontrado no seu código-fonte", nunca "você não é afetado".
• Cobre apenas os quatro lotes listados acima, num total de 15 vulnerabilidades; não é um scanner de vulnerabilidades abrangente e não substitui um SCA.
• A cobertura inclui a linha Spring Framework 5.3 (suporte OSS encerrado em 2024-08-31, versão final 5.3.39). Rodar com spring-core-5.3.39.jar acusará 11 vulnerabilidades, e para essas 11, nenhuma versão de correção oficial existe no Maven Central público (5.3.45 / 5.3.49 / 5.3.50, todas marcadas como Enterprise Support Only).
• Faz apenas correspondência de texto, não AST. Essa é uma escolha deliberada: os caminhos críticos precisam ser legíveis e verificáveis por humanos — um julgamento que ninguém entende não pode ser corrigido quando estiver errado.
• A diferença de classificação é uma leitura objetiva, não é "o fornecedor escondendo algo" nem "o NVD reportando errado".

De onde vêm os dados / como verificar você mesmo

A tabela de regras é gerada pelo tools/gen_rules.py a partir de quatro fontes primárias, sem transcrição manual:

Reexecutar é reverificar:

O script contém seis asserções; se alguma falhar, a tabela é recusada, e três delas monitoram diretamente as afirmações desta ferramenta:

• ASSERT2 Número de vulnerabilidades com divergência oficial⟷NVD —— se zerar, a afirmação perdeu a validade e o processo para na hora
• ASSERT3 Detecção no Central com controle positivo —— se o controle falhar, todos os 404 daquele lote são invalidados
• ASSERT4 Na vulnerabilidade consistente, a fonte da pontuação deve ser autoavaliação do fornecedor —— é a única evidência da "causa"

License

Apache-2.0