Como reduzir o ruído na gestão de vulnerabilidades

De onde vem o ruído das vulnerabilidades

Pegue num backlog e ordene-o pela origem de cada conclusão. Os números abaixo são ilustrativos, não um benchmark, mas as categorias são as que as equipas encontram quando analisam uma amostra do seu próprio backlog.

Origem da conclusão	Em 1000 conclusões (ilustrativo)	Passo que a elimina
Componentes que não distribui: entradas de lockfiles e manifestos, camadas de build, ferramentas de desenvolvimento e de teste	300	1. Acertar o inventário
A mesma CVE reportada por várias ferramentas, ou uma vez por repositório	250	2. Contar cada conclusão uma só vez
Correspondências erradas: colisões de nomes CPE, backports das distribuições	80	1. Acertar o inventário
Conclusões verdadeiras que não podem ser exploradas no seu produto	150	4. Acrescentar contexto de explorabilidade
Conclusões verdadeiras ainda sem correção	70	5. Uma decisão de política com expiração
Conclusões sem responsável	50	5. Encaminhar para um responsável
O que resta para classificar e corrigir	100	Priorização

Uma distinção facilita o resto da página. Algumas destas conclusões são falsos positivos: a conclusão está errada, porque o componente não está lá ou a versão não é afetada. Outras são ruído: a conclusão está certa, mas não muda o que faz esta semana. Precisam de soluções diferentes, e confundi-las é o que leva as equipas a suprimir conclusões verdadeiras ou a discutir conclusões erradas.

Falso positivo: a conclusão está errada	Ruído: certa, mas não urgente
O componente não está no que distribui	O código vulnerável não pode ser alcançado nem acionado no seu produto
A correspondência está errada: uma colisão de CPE, ou uma correção com backport que o número de versão esconde	Ainda não existe correção, ou o produto é interno e não está exposto
Resolve-se corrigindo o inventário e a correspondência	Resolve-se com contexto, uma decisão registada e um responsável

Passo 1. Faça o inventário corresponder ao que distribui

Esta é a maior alavanca individual, porque cada passo seguinte multiplica os erros do inventário. Um componente que está listado mas nunca é distribuído produz uma conclusão em cada scanner, cada repositório e cada versão.

• Registe a partir do build. Construa o inventário a partir do que o build de lançamento realmente usou, e não a partir de manifestos ou de uma análise do artefacto final. Uma SBOM gerada durante o build contém o que o job descarregou, incluindo o que nenhum lockfile lista.
• Identifique os componentes com PURL. Um package URL como pkg:npm/[email protected] indica com exatidão o ecossistema, o pacote e a versão. Cruzar com avisos de segurança indexados por PURL, como os avisos dos ecossistemas no OSV, elimina as correspondências erradas que resultam de adivinhar um CPE a partir do nome de um produto.
• Use correspondência que conheça a distribuição para os pacotes do sistema operativo. O Debian e outras distribuições aplicam backports das correções de segurança à versão que distribuíram em vez de a atualizarem, pelo que o número de versão pode parecer mais antigo do que a correção a montante. Faça a correspondência com o security tracker da própria distribuição, não com os intervalos de versões a montante.
• Acompanhe a completude. Saiba quando o inventário não conseguiu ver algo, em vez de assumir que está completo. Um componente em falta é pior do que um ruidoso: não produz conclusão nenhuma.

Exemplo prático. O lockfile de um serviço Node.js inclui [email protected], uma biblioteca de correspondência de padrões glob de que dependem ferramentas de teste e de build. Uma análise do lockfile reporta a CVE-2024-4067, uma negação de serviço por expressão regular corrigida na 4.0.8. O job de lançamento instala apenas as dependências de produção, com npm ci --omit=dev, pelo que o micromatch nunca entra no build que é distribuído. Um registo desse build não o contém, e a conclusão nunca chega ao backlog. A CVE é real; para este produto, a conclusão é um falso positivo.

Passo 2. Conte cada conclusão uma só vez

A mesma CVE chega da ferramenta de SCA, do scanner de contentores e da plataforma de SBOM, e mais uma vez por cada repositório que usa a biblioteca. Deduplique com uma única chave: package URL, versão e CVE. Por exemplo, pkg:npm/[email protected] com a CVE-2024-45296 é uma conclusão, independentemente de quantas ferramentas a reportem.

• Conte uma conclusão por artefacto distribuído, não uma por scanner.
• Agregue entre builds e repositórios, para que a CVE de uma biblioteca partilhada seja uma decisão aplicada em todo o lado, não quarenta tickets.
• Consolide os scanners que se sobrepõem. Uma regra simples: as conclusões sobre dependências vêm de uma fonte de SCA ou de SBOM, as conclusões sobre imagens de um scanner de contentores, as conclusões no seu próprio código de uma ferramenta de SAST. Se duas ferramentas reportarem o mesmo sinal, mantenha a que está mais próxima do que é distribuído (SAST vs SCA).

Passo 3. Distribua menos

Cada dependência que não distribui é uma fonte de conclusões com que nunca terá de lidar.

• Remova as dependências não usadas. A maioria dos projetos carrega alguns pacotes que já nada importa.
• Atualize o pacote que traz os vulneráveis. O Express 4.19.2 fixa [email protected] e [email protected], que têm a CVE-2024-45590 e a CVE-2024-45296. Não é possível atualizá-los isoladamente sem overrides. O Express 4.20.0, lançado em setembro de 2024, depende das versões corrigidas, pelo que uma única atualização resolve ambas (dependências transitivas).
• Use imagens base mínimas. As imagens slim e distroless contêm menos pacotes do sistema operativo, pelo que se aplicam menos avisos de segurança. A análise de contentores trata as alavancas específicas das imagens.
• Fixe versões e atualize de forma deliberada. Os lockfiles e os digests tornam o inventário estável entre builds.
• Bloqueie builds que contenham uma versão vulnerável conhecida. Um policy gate que para o build mantém uma biblioteca vulnerável de fora antes de se tornar uma conclusão que alguém tenha de triar.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Passo 4. Acrescente contexto de explorabilidade

O que resta depois dos passos 1 a 3 é real. O contexto decide o que, disso, é urgente.

• VEX. Registe "não afetado" uma vez, com uma justificação, como declaração VEX, e reutilize-a entre versões e clientes. Quando os clientes reencaminham as suas próprias análises do seu produto, os mesmos registos respondem-lhes: consulte como escalar uma PSIRT e, para modelos de resposta, como responder aos clientes após um ataque à cadeia de abastecimento.
• A alcançabilidade, onde as suas ferramentas a oferecem, mostra se o seu código consegue chamar a função vulnerável. Ajuda, dentro de certos limites (análise de alcançabilidade).
• Sinais de exploração. O CISA KEV indica que uma vulnerabilidade está a ser explorada no terreno; o EPSS estima a probabilidade de exploração nos próximos 30 dias.
• Exposição. Um produto exposto à internet tem prioridade sobre uma ferramenta interna numa rede privada.

Passo 5. Encaminhe as conclusões para um responsável, com uma política

• Escreva os limiares como política. Defina limiares de gravidade e explorabilidade por produto ou repositório numa política, e não como um filtro de dashboard que uma pessoa aplicou.
• Atribua responsáveis por repositório ou equipa, para que cada conclusão tenha alguém que decide.
• Decida explicitamente "sem correção disponível": aceitar com data de expiração, mitigar ou substituir o componente. Uma conclusão sem correção não deve ficar aberta sem decisão.

Os programadores ignoram conclusões por quatro razões: sem responsável, sem contexto, sem prazo ou no canal errado. As equipas com quem falamos descrevem engenharias que desligam scanners porque o resultado tinha demasiado ruído para ser lido. Resolva cada razão: um responsável por repositório, o contexto do passo 4 anexado, um prazo definido pela política e a entrega onde a equipa já trabalha.

Reduzir o ruído vs esconder o risco

Um backlog mais pequeno só é melhor se tiver diminuído pelas razões certas.

• A supressão sem motivo nem expiração é dívida escondida. Volta a aparecer numa auditoria ou num incidente, sem ninguém que se lembre do porquê.
• Os limiares mínimos de gravidade escondem as conclusões erradas em vez de as eliminar. "Nada abaixo de CVSS 7" faz desaparecer um falso positivo com CVSS 6 e deixa ficar um com CVSS 9.
• Cada decisão de não corrigir precisa de um registo. Os clientes pedem-no, tal como regulamentos como o Cyber Resilience Act da UE, que espera que os fabricantes tratem as vulnerabilidades ao longo do período de suporte de um produto.

Como medir

• Conclusões por versão distribuída, não por análise.
• A proporção de conclusões tratadas: corrigidas, mitigadas ou decididas.
• Fechadas como não afetadas com um registo VEX, face às suprimidas sem ele.
• Tempo entre o build e o responsável: quanto tempo uma nova conclusão espera até alguém assumir a responsabilidade.
• A taxa de duplicados entre ferramentas.

Uma amostra de 50 conclusões que pode fazer numa tarde. Escolha 50 conclusões abertas ao acaso. Para cada uma, registe se o componente é distribuído na versão, se outra ferramenta ou repositório reporta a mesma conclusão, se a correspondência está correta, se é explorável no seu produto, se existe correção e quem é o responsável. As contagens dizem-lhe por que passo começar. Repita a mesma amostra um trimestre depois. Não citamos benchmarks do setor para estes números, porque nenhuma fonte primária sustenta um.

Onde entra o CRACI

O CRACI trabalha nos passos 1 e 2, no gate do build do passo 3 e em parte dos passos 4 e 5, para software compilado em GitHub Actions.

• O inventário. O CRACI substitui os seus runners alojados no GitHub e regista os pacotes que cada job efetivamente obteve, com um PURL por componente e um estado de completude por SBOM. Cada componente de uma SBOM do CRACI esteve no build. Essa exatidão diz respeito aos componentes da SBOM; uma CVE correspondente pode, ainda assim, não afetar o seu produto. É para isso que serve o VEX, e o CRACI suporta VEX.
• Uma conclusão, muitos builds. As conclusões são agregadas entre builds e repositórios, e as SBOM monitorizadas são reavaliadas continuamente à medida que são publicadas novas vulnerabilidades.
• Gates. Os policy gates podem parar um build em tempo real com base em conclusões, incluindo um build que contenha uma CVE específica.
• Triagem e encaminhamento. As equipas de segurança fazem a triagem das conclusões no CRACI e encaminham cada uma para a equipa responsável pela correção.
• Notificações. O CRACI notifica as pessoas relevantes de uma vulnerabilidade e da sua gravidade.

O CRACI não oferece análise de alcançabilidade, SAST nem dashboards de MTTR. Consulte o acompanhamento de vulnerabilidades para conhecer a capacidade completa, ou veja o que os seus builds realmente contêm.

Quando o CRACI não é a resposta

• A maior parte do seu ruído são conclusões de SAST no seu próprio código. Isso é um problema de afinação do SAST.
• O seu backlog é sobretudo composto por conclusões verdadeiras e exploráveis em código distribuído. Isso é um problema de capacidade de remediação, não um problema de ruído.
• Precisa de contexto de runtime das cargas de trabalho em produção. Uma CNAPP ou uma ferramenta de segurança em runtime responde a isso.

Para o plano mais amplo, consulte o que automatizar quando o número de CVE não para de crescer e os números em tempo real nas tendências de publicação de CVE.

Reduzir o ruído das vulnerabilidades: perguntas frequentes

Como reduzo o número de alertas de vulnerabilidades?

Corte-os na origem, por ordem: faça o inventário corresponder ao que distribui, deduplique as conclusões por package URL, versão e CVE, distribua menos dependências, acrescente contexto de explorabilidade como VEX, KEV e EPSS, e encaminhe o que resta para um responsável ao abrigo de uma política escrita. Depois, priorize.

Porque é que o nosso scanner reporta milhares de vulnerabilidades, e quais importam?

Normalmente porque reporta componentes que não distribui, reporta a mesma CVE uma vez por ferramenta e por repositório, e adivinha mal algumas correspondências. As que importam estão em componentes que a sua versão realmente contém, são exploráveis no seu produto e são conhecidas ou prováveis de ser exploradas.

Como deduplico as conclusões de várias ferramentas de segurança?

Identifique cada conclusão pelo package URL, pela versão e pela CVE, e conte uma conclusão por artefacto distribuído. Agregue entre repositórios para que uma biblioteca partilhada seja uma só decisão. Depois, atribua cada tipo de sinal a uma única ferramenta, para que dois scanners deixem de reportar a mesma coisa.

Devemos suprimir as vulnerabilidades que não têm correção?

Não em silêncio. Tome uma decisão explícita: aceite o risco com um motivo escrito e uma data de expiração, mitigue-o ou substitua o componente. Depois, reveja-a quando surgir uma correção. Uma supressão sem motivo nem expiração é dívida escondida.

Uma vulnerabilidade que ninguém corrigiu durante um ano continua a ser ruído?

Não necessariamente. A idade nada diz sobre o risco. Se é distribuída e é explorável, precisa de uma decisão e de um responsável. Se não afeta o seu produto, registe-o como declaração VEX para que deixe de voltar. Em qualquer dos casos, não deve ficar aberta sem decisão.

Como evito que os programadores ignorem as conclusões de segurança?

Dê a cada conclusão um responsável, o contexto para agir, um prazo definido por uma política escrita, e entregue-a onde a equipa já trabalha. Elimine primeiro o ruído: os programadores deixam de ler um canal onde a maioria das conclusões não importa.

Qual é um bom número de vulnerabilidades em aberto?

Não existe um benchmark fiável, e a contagem bruta é a medida errada. Acompanhe as conclusões por versão distribuída, a proporção tratada, a proporção fechada com um motivo registado e quanto tempo as vulnerabilidades exploradas conhecidas ficam em aberto no software distribuído.