Verifique o que entra no release

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 evidência de que o pacote existe ou é adequado. Verifique o registry, o publicador, o nome do pacote e a versão exatos antes da instalação.

Para uma exportação CSV fictícia, o runtime talvez já forneça o comportamento necessário. Um novo pacote ainda pode ser adequado, mas acrescenta manutenção e caminhos de execução. Compare o esforço de implementação com as responsabilidades contínuas da dependência.

Revise a licença e o runtime suportado. Inspecione a atividade de manutenção e os alertas relevantes. Um nome conhecido pode se referir a outro pacote em outro registry. Uma instalação bem-sucedida mostra apenas que a instalação foi concluída.

Inspecione o comportamento de instalação e build

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 um job que processa um pull request não confiável.

Use um lockfile versionado quando o ecossistema oferecer suporte. Exija que o build respeite esse arquivo. Revise as mudanças no lockfile junto com a alteração de 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 cobre a proteção de software e as práticas de desenvolvimento ao longo do ciclo de vida. Use essa perspectiva mais ampla ao projetar o ambiente de build. Leia o framework.

Diferencie inventário de proveniência

Uma lista de materiais de software, ou SBOM, registra os componentes de um software. Ela ajuda a identificar releases afetados quando um componente passa a exigir atenção. Não comprova, por si só, que os componentes são seguros.

Proveniência trata de como um artefato foi produzido. O SLSA define um formato de proveniência para informações sobre o build e suas entradas. A verificação deve vincular essas informações a um produtor confiável e ao artefato que você pretende usar. Um arquivo chamado “proveniência” não basta. Proveniência no SLSA.

Para o serviço de exportação, registre uma cadeia que possa inspecionar:

1. O commit revisado identifica o código-fonte aceito.
2. O build identifica suas entradas e seu ambiente de execução.
3. O artefato tem um digest estável.
4. As verificações identificam o artefato ou código-fonte examinado.
5. O deployment registra o artefato colocado no ambiente de destino.

Evite refazer o build de forma diferente após a aprovação sem um processo definido de verificação. Uma tag mutável como latest pode apontar para outra imagem mais tarde.

Decida o que um achado significa

Um achado de vulnerabilidade exige contexto: versão afetada, comportamento vulnerável que pode ser executado, exposição, correção disponível e consequência. Registre as evidências por trás de qualquer exceção temporária. Defina responsável, validade e condição de revisão.

Não desative um scanner inteiro porque um achado não se aplica. Não declare ausência de achados quando o escaneamento não foi concluído. Tempo limite excedido, pacote não suportado ou fonte de alertas indisponível são evidências ausentes.

Por fim, planeje atualizações após o release. Novos alertas podem afetar o artefato aceito ontem. O responsável pelo serviço precisa de um inventário, um processo de resposta e capacidade de produzir um release corrigido.

Continue com gestão contínua de vulnerabilidades para relacionar escaneamentos repetidos a correções verificadas em produção.