Priorização de vulnerabilidades: como decidir o que corrigir primeiro

Porque é que a gravidade por si só não funciona

O habitual é ordenar por CVSS e ir descendo a partir das críticas. Parece objetivo, e falha por três razões:

• O CVSS mede a gravidade, não o risco. Descreve quão grave seria uma vulnerabilidade se fosse explorada. Não diz se alguém a está a explorar, nem se importa no seu produto.
• Demasiadas entradas da lista são urgentes. Muitas CVE publicadas têm pontuação alta ou crítica, pelo que uma fila ordenada por CVSS coloca centenas de conclusões no topo e não dá forma de escolher entre elas.
• A lista só é tão boa quanto o inventário. Um scanner que lê um lockfile reporta dependências de desenvolvimento que nunca são distribuídas, e não vê pacotes que o build descarregou fora do gestor de pacotes. Ambos distorcem a classificação antes de esta começar.

A priorização acrescenta as perguntas em falta: está a ser explorada, qual a probabilidade de o vir a ser, e o que lhe acontece se for.

Os sinais

Sinal	A que pergunta responde	Fonte
CVSS	Quão grave é se for explorada? Pontuação de 0 a 10.	FIRST (a norma); a NVD e os fornecedores publicam pontuações
EPSS	Qual a probabilidade de exploração nos próximos 30 dias? Uma probabilidade de 0 a 1.	FIRST, atualizado diariamente, gratuito
CISA KEV	Já está a ser explorada no terreno?	Catálogo Known Exploited Vulnerabilities da CISA
SSVC	Tendo em conta a exploração, o impacto e a sua missão, o que deve fazer: acompanhar, dar atenção ou agir?	Árvores de decisão do CERT/CC e da CISA
O seu contexto	A versão vulnerável é distribuída? Está exposta? Qual a importância do produto? Existe uma correção?	O seu inventário, arquitetura e registos de ativos

Os sinais públicos descrevem a vulnerabilidade. Só o seu contexto descreve o seu risco, e é a parte que a maioria das equipas obtém da fonte menos fiável.

Um método prático de priorização

A maioria dos programas acaba com alguma versão destes níveis. Defina os prazos conforme o que a sua política e os seus clientes exigem.

1. Corrigir já: exploração conhecida, em software que distribui. Tudo o que conste da lista KEV, ou tenha outras provas de exploração, e esteja presente num build lançado. Para comparação, a BOD 26-04 da CISA dá às agências federais dos EUA apenas 3 dias para uma entrada KEV num sistema exposto publicamente.
2. Corrigir a seguir: exploração provável e gravidade elevada. Uma pontuação EPSS alta combinada com um CVSS alto ou crítico, num componente distribuído e exposto. Escolha um limiar EPSS que dê uma fila que a sua equipa consiga realmente esvaziar.
3. Corrigir de forma rotineira: tudo o resto que é distribuído. Agrupe-o em atualizações regulares de dependências em vez de tratar cada conclusão como um incidente.
4. Documentar: não afetado. O pacote vulnerável está presente mas o código vulnerável não é usado, ou o componente não é distribuído. Registe o raciocínio como uma declaração VEX, para que a mesma conclusão não volte a ser revista e para que os clientes que perguntem possam ver porquê.

Depois, volte a ordenar continuamente. Uma vulnerabilidade que estava no nível três pode passar para o nível um de um dia para o outro quando é adicionada ao KEV ou a sua pontuação EPSS dispara.

As vulnerabilidades que nunca chega a classificar

Todos os métodos de priorização classificam as conclusões que têm à frente. Um pacote vulnerável que o scanner nunca viu não produz nenhuma conclusão, pelo que nunca recebe uma pontuação CVSS, uma pontuação EPSS ou uma correspondência no KEV. Não fica mal classificado. Não fica classificado de todo, e é distribuído na mesma.

Isto acontece mais vezes do que parece, porque a maioria dos scanners determina o que está no seu software a partir de ficheiros: o lockfile, os manifestos ou o resultado do build. Tudo o que o build obtém e que nenhum lockfile lista é uma dependência oculta, e as ferramentas baseadas em ficheiros não a veem:

• Hooks de instalação. Código descarregado pelos scripts preinstall e postinstall do npm, a via usada pelo worm Shai-Hulud.
• Scripts de build. Por exemplo, scripts de build de Rust que descarregam código durante o build.
• Imagens base. A imagem base de um build de contentor e as respetivas camadas do sistema operativo.
• Caches. Pacotes restaurados de uma cache de CI em vez de instalados a partir do lockfile.

Analisar o resultado depois não fecha a lacuna. Um binário acabado, sobretudo código compilado como Rust, deixa o scanner a adivinhar o que entrou nele. E como os builds não são reprodutíveis por defeito, voltar a compilar o mesmo commit mais tarde não garante as mesmas dependências.

Uma SBOM registada durante o build começa pela outra ponta. O CRACI executa os seus jobs de GitHub Actions e vê o tráfego que entra em cada build, pelo que regista cada pacote que o job realmente trouxe, incluindo as dependências ocultas. Cada SBOM indica um estado de completude que diz quando algo não pôde ser visto. Na prática, o CRACI encontrou pacotes vulneráveis que o Snyk e o Aikido não reportaram, porque faltavam componentes nas análises destes. São exatamente as conclusões que um método de priorização nunca tem oportunidade de classificar.

Contexto: a parte que os scanners não conseguem pontuar por si

A versão vulnerável é realmente distribuída?

É a pergunta que elimina mais ruído. Uma framework de testes num lockfile, um pacote fixado numa branch que nunca é lançada, uma fase de contentor que é deitada fora: nada disto chega aos clientes. Uma SBOM registada durante o build responde à pergunta a partir do que o build de lançamento realmente usou, e não do que o repositório declara.

Que versões a contêm, e desde quando?

Uma conclusão num produto que distribui a clientes, com todas as versões desde a última primavera afetadas, passa à frente da mesma conclusão numa ferramenta interna. Conhecer o período de exposição indica-lhe também o que divulgar.

O código vulnerável pode ser alcançado?

A análise de alcançabilidade verifica se o seu código pode chamar a função vulnerável de uma dependência. Várias ferramentas de SCA oferecem-na, e é eficaz a empurrar as conclusões inalcançáveis para o fundo da lista. Trate-a como um dado entre outros: só vê os caminhos de código que a análise consegue seguir, e uma função alcançável não é o mesmo que uma função explorável.

Está exposta, e existe uma correção?

Um serviço exposto à internet fica acima de um job em lote numa rede privada. Uma vulnerabilidade com versão corrigida é mais barata de fechar do que uma que precisa de uma mitigação. Ambos mudam a ordem, não o facto de ser tratada.

Gestão de vulnerabilidades baseada no risco

A gestão de vulnerabilidades baseada no risco é o nome da mesma ideia ao nível do programa: ordenar por provas de exploração, probabilidade, gravidade e contexto de negócio, medir a rapidez com que as conclusões de maior risco são fechadas e aceitar que as de baixo risco possam ficar abertas. As métricas mudam com ela. Em vez do número total de vulnerabilidades abertas, acompanhe quantas vulnerabilidades com exploração conhecida estão abertas em software distribuído, e durante quanto tempo ficam abertas.

Ferramentas de priorização de vulnerabilidades

Três tipos de ferramentas fazem hoje a maior parte da classificação:

• Plataformas de gestão de vulnerabilidades de infraestrutura, como a Tenable, a Qualys e a Rapid7, pontuam hosts, endpoints e ativos de cloud com as suas próprias classificações de risco, assentes em informação sobre exploração.
• Ferramentas de SCA e de segurança aplicacional, como o Snyk, o Endor Labs e o Semgrep, ordenam as conclusões de dependências, várias delas com análise de alcançabilidade.
• Ferramentas open source, como o Grype, que reporta dados EPSS e KEV com as suas conclusões, e o Dependency-Track, que analisa SBOM continuamente.

Ferramentas de gestão de vulnerabilidades comparadas analisa-as uma a uma.

Como o CRACI apoia a priorização

O CRACI começa onde a classificação falha mais vezes: o inventário. Executa os seus jobs de GitHub Actions e regista os pacotes que cada job realmente obteve, incluindo as dependências transitivas, os pacotes restaurados de caches e as dependências ocultas que nenhum lockfile lista.

• Conclusões sobre o que foi distribuído. As SBOM monitorizadas são continuamente reavaliadas, e as vistas da organização agregam as conclusões de todos os builds e repositórios. Cada pacote mostra os seus avisos de segurança com a gravidade e os pacotes que o trazem.
• Período de exposição. O histórico de builds mostra que builds anteriores continham uma dependência vulnerável, direta ou transitiva, para que saiba que versões foram afetadas e durante quanto tempo.
• Triagem e encaminhamento. As equipas de segurança fazem a triagem das conclusões e enviam cada uma para a equipa responsável pela correção. O CRACI suporta VEX para registar que uma vulnerabilidade não afeta o seu produto.
• Gates. Os policy gates podem bloquear um build com base em conclusões, incluindo um build que contenha uma CVE específica.

O CRACI não oferece análise de alcançabilidade. Se esse for o sinal de que mais precisa, escolha uma das ferramentas de SCA que a oferecem. Consulte acompanhamento de vulnerabilidades para a capacidade completa.

Priorização de vulnerabilidades: perguntas frequentes

O que é a priorização de vulnerabilidades?

A priorização de vulnerabilidades consiste em decidir que vulnerabilidades conhecidas corrigir primeiro, quais podem esperar e quais não o afetam de todo. Ordena as conclusões pela probabilidade de serem exploradas e pelos danos que isso causaria no seu ambiente, e não apenas pela gravidade.

Como se priorizam vulnerabilidades?

Comece por um inventário exato, para classificar vulnerabilidades em software que é realmente distribuído. Coloque primeiro tudo o que conste da lista Known Exploited Vulnerabilities da CISA e depois ordene o resto pela probabilidade de exploração (EPSS) e pela gravidade (CVSS), ajustadas ao seu contexto: exposição, importância do produto e existência de correção. Registe as que não o afetam como declarações VEX.

O CVSS é suficiente para priorizar vulnerabilidades?

Não. O CVSS mede a gravidade de uma vulnerabilidade, não a probabilidade de ser explorada nem o quanto importa para si. Ordenar apenas por CVSS marca uma grande parte do backlog como alta ou crítica, e a maioria dessas vulnerabilidades nunca é explorada.

O que é a gestão de vulnerabilidades baseada no risco?

A gestão de vulnerabilidades baseada no risco ordena e corrige as vulnerabilidades pelo risco que representam para a sua organização, combinando provas de exploração, probabilidade, gravidade e contexto de negócio, em vez de as tratar por pontuação CVSS ou por antiguidade.

Qual é a diferença entre EPSS e KEV?

O EPSS é uma previsão: a probabilidade estimada de uma CVE ser explorada nos próximos 30 dias. O KEV é um registo: o catálogo da CISA de vulnerabilidades com provas de exploração no terreno. Uma entrada KEV é um facto; uma pontuação EPSS é uma probabilidade. Use primeiro o KEV e, depois, o EPSS para ordenar tudo o resto.

A análise de alcançabilidade substitui a priorização?

Não, é mais um dado. A alcançabilidade verifica se o seu código pode chamar a função vulnerável de uma dependência. Elimina as conclusões que não podem ser desencadeadas, mas nada diz sobre a probabilidade de exploração e só cobre o código que a análise consegue seguir.