PyPI: como aceitar um arquivo com evidências de origem
A nova aba Security facilita consultar a origem dos arquivos no PyPI. A decisão de aceitação precisa seguir a distribuição que será entregue e os limites da evidência disponível.
Read in EnglishPor Pentesty
O que mudou e o que continua exigindo revisão
No anúncio de 6 de novembro de 2026, o PyPI apresentou a conclusão da reformulação das páginas de projeto. A aba Security reúne sinais sobre a origem dos arquivos. Atestações já existiam desde 2024: a novidade facilita encontrá-las e interpretar avisos, sem transformar o repositório em certificador da segurança do código.
Para empresas, o resultado útil é uma decisão documentada sobre a distribuição que será entregue. Um registro de versão aprovado pode coexistir com arquivos destinados a plataformas diferentes. A equipe precisa saber qual deles chegou ao artefato de produção e quais informações sustentaram sua aceitação.
Comece pelo arquivo que será consumido
Escolha um pacote usado por um serviço sob sua responsabilidade. Registre projeto, versão, nome exato do arquivo, plataforma de destino e responsável pela aprovação. Na aba Release Files, localize essa distribuição e consulte seu estado de proveniência. Guarde a data da consulta e a referência consultada, sem instalar um arquivo apenas para examiná-lo.
Depois compare os demais arquivos da mesma versão. Proveniência completa significa que todos possuem atestações; proveniência incompleta exige examinar os arquivos sem elas. Ausência de atestação não demonstra malware. Registre a lacuna e a justificativa da decisão, em vez de atribuir ao pacote uma conclusão que os dados não permitem.
Separe integridade, identidade e segurança
A documentação de integridade explica como comparar o SHA-256 do arquivo com o registro do PyPI. Essa comparação liga os bytes obtidos ao arquivo publicado. Ela não demonstra que o código é confiável nem substitui a avaliação do canal pelo qual o hash foi obtido.
Defina quais identidades e campos sua política realmente exige. Se o registro não trouxer o commit exigido pelo processo, trate a lacuna como decisão pendente. Documente quem pode aceitar uma exceção e seu prazo. Avalie também a separação entre produzir e aprovar: o processo que gera o arquivo não deve autorizar sozinho qualquer nova origem. Entregue ao aprovador uma comparação com o valor previamente aceito e conserve os dados usados para chegar à decisão.
Investigue avisos com uma comparação própria
Conforme a documentação de proveniência, arquivos podem ter origens inconsistentes ou mudar de repositório ou workflow. Essas situações também podem ter explicações legítimas. Compare a identidade observada com a configuração aprovada e com as notas públicas do projeto; documente a migração esperada antes de aceitar a mudança.
Os avisos de mudança e perda de proveniência usam comparação com releases dos 14 dias anteriores. Por isso, preserve também seu próprio histórico de artefatos aceitos. A ausência de um aviso na interface não comprova continuidade histórica. Tampouco uma visita à aba implementa verificação automática de atestações no instalador ou na esteira.
Defina um teste sem executar código desconhecido
Em um ambiente autorizado, prepare registros sintéticos de duas distribuições do mesmo pacote interno. Defina uma identidade de publicação aceita e uma segunda origem que deve exigir revisão. Verifique se a regra avalia cada arquivo e registra a decisão esperada, incluindo uma exceção deliberada para metadados ausentes. Não use amostras de campanhas reais.
O relatório deve ligar arquivo, hash, atestação consultada, resultado da verificação e responsável pela liberação. Se a empresa adotar verificação criptográfica automatizada, valide sua política de identidade e seus resultados conforme as instruções oficiais de consumo de atestações. Uma regra permissiva que aceita qualquer emissor não satisfaz uma política sobre a origem esperada.
Leve a evidência até o ambiente entregue
Conecte a distribuição aceita ao build e ao serviço que a recebeu. A análise sobre PolinRider e execução de dependências complementa esse acompanhamento: aquisição, execução e acesso são evidências diferentes. Após mudanças na esteira, repita os casos permitido e bloqueado e confirme que a operação legítima continua possível.
Inclua um controle negativo adicional: mantenha o nome de uma distribuição fictícia, mas altere seus bytes em uma cópia de laboratório. A política deve identificar a divergência antes de liberar o consumo, mesmo que exista um registro anterior com aquele nome. Preserve hash esperado, hash observado, etapa da rejeição e resultado do caso válido. Essa evidência permite ao responsável avaliar se uma mudança de cache, mirror ou etapa de empacotamento manteve o controle previsto. Ela não substitui a revisão do código nem demonstra a segurança de uma dependência real.
Perguntas frequentes
Proveniência completa garante que o pacote seja seguro?
Não. Defina o critério de aceitação do arquivo e avalie separadamente código, ambiente e autoridade do aprovador.
Sem atestação significa que há malware?
Não. Defina quem revisa a lacuna e qual evidência autoriza uma exceção para o arquivo necessário.
A aba Security faz o instalador bloquear releases automaticamente?
Não. A interface apresenta informações. A empresa precisa definir e verificar uma política de consumo e seus controles de execução.
Por que guardar o nome exato do arquivo?
Uma versão pode conter várias distribuições com proveniências diferentes. O registro precisa identificar a que foi efetivamente entregue ao serviço.
Fontes e referências
Análise original da Pentesty, publicada em 10 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.