Verificar o que entra no lançamento

Pergunte se a dependência é necessária

Um agente pode sugerir um pacote que parece resolver um problema. A sugestão é uma proposta, não uma evidência de que o pacote existe ou é adequado. Antes da instalação, verifique o registry, o publicador, o nome do pacote e a versão exatos.

Num export CSV fictício, o ambiente de execução pode já fornecer o comportamento necessário. Um pacote novo pode ainda ser adequado, mas acrescenta manutenção e percursos de execução. Compare o esforço de implementação com as responsabilidades contínuas da dependência.

Reveja a licença e o ambiente de execução suportado. Examine a atividade de manutenção e os avisos de segurança relevantes. Um nome conhecido pode identificar um pacote diferente noutro registry. Uma instalação bem-sucedida demonstra apenas que a instalação terminou.

Examine o comportamento da instalação e do build

As dependências podem executar código durante a instalação ou o build. Limite as credenciais e o acesso à rede nesses ambientes. Não exponha segredos de produção a uma tarefa que processa um pull request não fiável.

Use um lockfile incluído no controlo de versões quando o ecossistema o suportar. Exija que o build respeite esse ficheiro. Reveja as alterações do lockfile juntamente com a alteração do código, incluindo pacotes transitivos inesperados. Fixar versões melhora a reprodutibilidade, mas não torna segura uma versão vulnerável.

O SSDF do NIST abrange a proteção do software e as práticas de desenvolvimento ao longo do ciclo de vida. Use essa perspetiva mais ampla ao conceber o ambiente de build. Leia o referencial.

Distinga inventário de proveniência

Uma software bill of materials, ou SBOM, regista os componentes do software. Ajuda a identificar os lançamentos afetados quando um componente passa a constituir uma preocupação. Por si só, não demonstra que os componentes são seguros.

A proveniência explica como foi produzido um artefacto. O SLSA define um formato de proveniência para informação sobre o build e as suas entradas. A verificação tem de ligar essa informação a um produtor fiável e ao artefacto que pretende usar. Um ficheiro chamado «provenance» não basta. Proveniência SLSA.

Para o serviço de exportação, registe uma cadeia que possa examinar:

1. O commit revisto identifica o código-fonte aceite.
2. O build identifica as suas entradas e o ambiente de execução.
3. O artefacto tem um digest estável.
4. As verificações identificam o artefacto ou o código-fonte que examinaram.
5. O deployment regista o artefacto colocado no ambiente de destino.

Evite repetir o build de forma diferente após a aprovação sem um processo de verificação definido. Uma tag mutável, como latest, pode passar a referir-se a outra imagem.

Decida o significado de uma vulnerabilidade encontrada

Uma vulnerabilidade encontrada exige contexto: a versão afetada, o comportamento que pode ser executado, a exposição, a correção disponível e as consequências. Registe as evidências que sustentam qualquer exceção temporária. Atribua-lhe um responsável, um prazo de validade e uma condição de revisão.

Não desative um scanner inteiro por um dos resultados não ser aplicável. Não apresente um resultado sem problemas quando a análise não tiver terminado. Um timeout, um pacote não suportado ou um feed de avisos indisponível representam falta de evidências.

Por fim, planeie as atualizações após o lançamento. Novos avisos podem afetar o artefacto aceite ontem. O responsável pelo serviço precisa de um inventário, de um processo de resposta e de capacidade para produzir um lançamento corrigido.

Continue com a gestão contínua de vulnerabilidades para ligar as análises repetidas a correções verificadas em produção.