Uma porta para novas dependências
A resposta prática é tornar as alterações de dependência uma parte separada e executável da revisão do código. Uma solicitação pull que adiciona um pacote ou altera sua versão resolvida deve produzir uma diferença de dependência antes de poder ser mesclada. As verificações de vulnerabilidades conhecidas continuam úteis, mas são apenas uma entrada: indexed-btree não precisava de um CVE conhecido para ser perigoso. O portão também deve mostrar o nome exato do pacote, a versão, a procedência, quando disponível, e os arquivos publicados que realmente serão executados.
Para uma dependência existente que recebe uma atualização de rotina, as equipes podem aplicar sua política normal. Um novo nome, uma mudança para um pacote semelhante, uma mudança de editor ou um arquivo executável ou ofuscado inexplicável devem pausar a mesclagem para que um proprietário investigue. Essa é uma regra de decisão, não um pedido para que cada engenheiro leia cada linha do node_modules. Revise o artefato resolvido e sua alteração em relação à versão aprovada anteriormente; registre por que o pacote é necessário e onde ele será executado.
Use uma comparação de dependência automatizada para tornar isso visível em cada solicitação pull e, em seguida, exija o check-in da proteção do branch. A revisão de dependências do GitHub, por exemplo, pode impor verificações de vulnerabilidades conhecidas recentemente introduzidas e mostrar alterações de pacotes. Não certifica que um pacote sem aviso seja seguro. Adicione uma regra separada para identidades de pacotes novas ou inesperadas e encaminhe esses casos para um revisor designado. O resultado da fusão deve ser explícito: aprovar a versão exata para um uso definido, investigá-la ou rejeitá-la.
