Dependências: decidir a entrada antes de confiar no lockfile

Identidade antes de integridade

A apresentação institucional de 7 de março de 2024 da OpenSSF sobre o trabalho com a CISA descreve o framework de segurança de repositórios de pacotes, versão 0.1. Inclui prevenção de typosquatting e ferramentas capazes de fixar dependências por versão ou hash. É uma referência técnica histórica, não uma nova obrigação nem um incidente ocorrido nesta edição.

A SLSA v1.2 recomenda verificar a assinatura da proveniência, o digest do artefacto e as expectativas sobre builder, repositório de origem e parâmetros. A mesma página declara que não cobre enganar o consumidor para escolher um pacote não pretendido, como no typosquatting. Uma verificação bem-sucedida não corrige uma escolha inicial errada.

Três perguntas que não devem ser fundidas

O OSV permite consultar vulnerabilidades conhecidas por versão de pacote ou commit e usa um formato que relaciona avisos com esses identificadores. Isso torna a consulta útil depois de identificar a dependência exata. Não é um certificado de que o pacote é legítimo nem de ausência de defeitos desconhecidos.

Perspetiva Velqory: separe admissão, integridade e vulnerabilidades. Primeiro confirme que é o componente pretendido; depois confronte o artefacto com a origem esperada; finalmente avalie avisos aplicáveis. Um lockfile deve ser evidência do conjunto aprovado, não o argumento único para o aprovar.

Uma receita de revisão para o próximo pedido

Propomos estes critérios para um pedido que introduza ou atualize dependências. Adapte os mecanismos ao gestor de pacotes; o procedimento não foi executado num repositório de cliente para este artigo.

• O autor do pedido identifica a necessidade, o nome exato com namespace, o registo e a página oficial do projeto que confirma esse nome. Uma sugestão de IA ou um nome plausível não substituem essa ligação.
• O revisor compara manifesto e lockfile: entradas novas, versões alteradas, origens resolvidas e dependências transitivas. Mudanças sem relação explicada com o objetivo regressam ao autor antes de aprovação.
• Quando existir proveniência, verifique-a contra expectativas previamente aprovadas. Guarde o resultado, o digest e a identidade esperada do builder; não aceite qualquer assinatura como equivalente à identidade certa.
• Consulte avisos para os identificadores e versões efetivamente resolvidos. Registe a data, o resultado e o responsável pela análise. Se a consulta falhar, marque «desconhecido», não «sem vulnerabilidades».
• Ensaie a instalação e os testes num ambiente descartável, sem credenciais de produção, segundo a configuração aprovada. Compare o conjunto obtido com o aprovado e interrompa perante alterações inesperadas.
• A exceção urgente deve ter componente, versão, motivo, proprietário e validade. Preserve a versão anterior e um caminho de reconstrução conhecido; reverter só o manifesto pode não reproduzir a instalação anterior.

A evidência que permite fechar o pedido

A nossa proposta de aceitação é um pequeno pacote de evidência: necessidade aprovada, identidade confirmada, diferença do conjunto resolvido, verificações executadas e resultado dos testes. O responsável pela aplicação aceita a alteração; segurança intervém nas dúvidas de origem ou nas exceções relevantes.

Não transforme popularidade, idade ou número de downloads num veredito automático. Se a origem continua por esclarecer, o pedido permanece por aprovar mesmo que compile. Se um aviso exige uma atualização urgente, trate a urgência explicitamente, sem remover os outros controlos por silêncio.

Limites e condição de revisão

O âmbito são equipas que consomem pacotes de terceiros, incluindo equipas portuguesas. Não atribuímos ataques, não identificamos um pacote como malicioso e não garantimos segurança de um ecossistema. A receita é uma recomendação editorial apoiada nos referenciais citados.

Reabra a decisão quando mudar nome, namespace, registo, origem, builder ou dependência transitiva relevante, e quando surgir um aviso aplicável. A prevenção começa antes de aceitar o componente e continua depois da primeira instalação.