Caro CNA do Linux Kernel, o que vocês fizeram?

Papel e Significado dos CVEs

• Vários comentários ressaltam que os CVEs foram concebidos principalmente como identificadores únicos para que as pessoas falem do mesmo problema, e não como uma lista completa ou autoritativa de bugs de segurança “reais”.
• Outros contrapõem que, na prática, reguladores, empresas e ferramentas passaram a tratar “tem um CVE” como sinônimo de “vulnerabilidade de segurança conhecida”, quer isso tenha sido ou não o projeto original.
• Esse descompasso entre o uso pretendido e o uso no mundo real é visto como a tensão central.

Abordagem do Kernel Linux: “Todo Bug é um Bug de Segurança”

• A postura de longa data da comunidade do kernel: muitas vezes é impossível separar de forma confiável bugs “de segurança” de bugs “não de segurança”, então assume-se que todos os bugs podem ser relevantes para segurança.
• Tornar-se uma CNA e emitir CVEs para praticamente todos os bugfixes é visto por alguns como uma extensão lógica dessa postura; por outros, como um movimento deliberado de “queimar o sistema” para expor falhas no processo de CVE.

Regulação, Conformidade e Ônus para o Downstream

• Muitos temem que uma enxurrada de CVEs do kernel gere dor de cabeça de conformidade: mais triagem, mais ciclos obrigatórios de correção e potenciais riscos de segurança/estabilidade em sistemas regulados ou de longa vida útil.
• Alguns argumentam que normas (PCI-DSS, ISO, SOC2, CRA) exigem sobretudo processos para descobrir e lidar com vulnerabilidades exploráveis, e não aplicar patches cegamente em todos os CVEs. Um comentarista afirma que o CRA exclui explicitamente OSS upstream e foca na explorabilidade.
• Uma visão recorrente: grandes empresas que se beneficiam do Linux deveriam financiar sua própria triagem em vez de esperar que desenvolvedores do kernel, sem remuneração, classifiquem bugs para elas.

Resultados de Segurança e Perspectiva do Atacante

• Defensores acreditam que mais CVEs melhoram a transparência e empurram os retardatários para atualizações contínuas, que é a única forma realista de manter kernels seguros.
• Críticos afirmam que CVEs vagos, sem pontuação e gerados a posteriori — além da ausência de CVEs para bugs não corrigidos — podem prolongar a vida útil de exploits e complicar a defesa, especialmente em sistemas legados que não conseguem fazer upgrade completo.

Problemas de Qualidade, Pontuação e Ferramentas

• Muitos veem a pontuação CVSS como subjetiva, passível de manipulação e muitas vezes enganosa, embora reconheçam que ferramentas e regulações foram construídas em torno de CVE+CVSS.
• Há preocupação de que os muitos CVEs do Linux, minimamente descritos e sem pontuação, quebrem ou desvalorizem a automação existente e os processos de segurança por “checklist”.

Respostas e Mitigações Propostas

• As sugestões incluem:
  • Tratar CVEs apenas como entradas de triagem, e não como requisitos rígidos.
  • Pagar fornecedores para entregar “feeds limpos” curados e atualizações testadas.
  • Reduzir a exposição desativando componentes do kernel não usados e automatizando merges de versões menores.
• Alguns argumentam que organizações que fazem conformidade ingênua CVE por CVE “só têm a si mesmas para culpar” e precisam evoluir seus processos.