Quais verificações em pull requests de atualização automática de dependências já detectaram uma versão maliciosa ou defeituosa, e quais só geram ruído?

Pergunta em aberto

Os bots de atualização abrem um pull request para cada nova versão de dependência, e equipes pequenas costumam mesclar quando o build está verde, porque ler todos os diffs do upstream não escala. Existem várias verificações adicionais. A documentação do npm descreve declarações de proveniência (provenance) que ligam um pacote publicado ao seu repositório de origem e às instruções de build, além de um comando npm audit signatures, que informa as assinaturas do registry e os atestados verificados. Outros candidatos: comparar o conteúdo descompactado do pacote em vez de apenas o número da versão, inspecionar scripts de instalação e novos binários, ler o diff do lockfile em busca de dependências transitivas inesperadas, recusar versões publicadas há menos tempo que um período de espera, verificar se a tag da versão existe no repositório de origem e fixar dependências por digest. Cada verificação tem um custo em tempo de pipeline e em atenção de quem revisa, e cada uma gera algum ruído. O que falta é um registro de quais dessas verificações, na prática, bloquearam uma versão que depois se confirmou comprometida ou defeituosa, em qual ecossistema, e qual foi a taxa de ruído. A verificação que detectou algo também disparou em muitas versões inofensivas? A detecção veio de uma verificação automática ou de uma pessoa que leu um diff sinalizado pela verificação? As verificações de proveniência já foram o sinal decisivo alguma vez, ou a ausência de proveniência ainda é comum demais para servir de base para uma decisão?

O que uma resposta útil contém

O ecossistema (npm, PyPI, crates.io, módulos Go, imagens de contêiner) e o número de pull requests de atualização no período. Por verificação: como foi implementada, quantos pull requests bloqueou ou sinalizou, quantos deles foram depois julgados problemas reais e como esse julgamento foi feito (aviso público, reversão no upstream, análise própria). Para cada detecção real, se o mesmo problema teria sido pego apenas pelos testes do CI. O período de espera usado, se houver, e qualquer versão que o período de espera tenha atrasado e que depois se revelou uma correção de segurança importante. A proporção de dependências que chegam a publicar proveniência, já que uma verificação que se aplica a poucos pacotes prova pouco. Se as verificações mudaram o comportamento de mesclagem da equipe (mais ou menos atualizações mescladas) e se alguma atualização chegou a ser mesclada com uma verificação reprovada por ela ser considerada ruído. Relatos de zero detecções ao longo de um período longo são úteis e devem indicar quantos pull requests foram cobertos.