Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O PyPI público verifica quem publicou um pacote, e não o que o pacote faz.
- O SecureChain verifica e recompila os pacotes antes que eles cheguem ao seu ambiente.
- Os artefatos recompilados possuem novos hashes; portanto, os arquivos de requisitos fixados precisam ser regenerados.
- A aplicação de patches continua após a instalação, abrangendo toda a árvore de dependências.
O PyPI público verifica se os arquivos enviados são autenticados e autorizados para o projeto e publica um hash para cada arquivo enviado. O que ele não faz é reconstruir esses arquivos para comprovar que seu conteúdo veio do repositório de origem ao qual eles apontam, nem verificar se o código é seguro para ser executado. Essa lacuna é o que geralmente leva as pessoas a procurarem uma alternativa ao PyPI — algo que avalie o que um pacote faz, em vez de apenas de onde ele veio.
Esta publicação explica em que pontos o SecureChain para Python realiza a verificação, a recompilação e a aplicação contínua de patches após a instalação, e onde essa cobertura termina.
O que o PyPI público verifica e o que uma alternativa ao PyPI oferece a mais
Quando o `pip` realiza a instalação a partir do PyPI público, apenas uma pequena lista de verificações é aplicada, e nenhuma delas analisa o que um pacote fará depois de ser instalado no seu ambiente.
Para publicar uma versão, é necessária uma conta de mantenedor autenticada. Cada arquivo enviado recebe um hash de publicação, e o pip compara o download com o hash fornecido pelo índice, o que permite detectar uma transferência corrompida. No entanto, esse hash acompanha o arquivo desde a mesma fonte; portanto, ele comprova que o artefato chegou intacto, e não que alguém tenha verificado seu conteúdo. Modo de verificação de hash é a opção mais restritiva, porque com --require-hashes Um hash fornecido pelo índice não pode atender a esse requisito. O artefato precisa corresponder a um hash que você aprovou localmente.
Os mantenedores que optarem pelo Trusted Publishing recebem credenciais OIDC de curta duração em vez de um token de API estático, e o PyPI pode fornecer atestados digitais que vinculam criptograficamente um artefato à sua identidade de publicação e, com a proveniência SLSA, à sua localização de origem. Esses são sinais úteis de proveniência, mas nenhum deles comprova que o próprio artefato seja inofensivo. Uma vez que uma credencial de publicação autorizada ou um fluxo de trabalho seja comprometido, a autenticação por si só não fornece nenhuma informação sobre o que ocorreu nesse caminho; além disso, o processo de notificação e quarentena do PyPI geralmente só entra em ação quando uma versão maliciosa já está pronta para instalação, em vez de fazer a triagem dos artefatos antes de eles serem disponibilizados.
Um espelho seguro do PyPI que apenas redireciona a origem de download dos pacotes herda essa mesma lacuna. Esse também não é um problema específico do Python. É o ponto cego que muitas ferramentas de cadeia de suprimentos nunca conseguem eliminar: um pacote é avaliado com base em um hash e em um feed de CVE, mas nunca em relação ao que ele realmente faz quando é executado.
Exames antes do parto, e não depois
O SecureChain analisa o código-fonte de um pacote antes mesmo de ele ser entregue a um agente de compilação ou a uma máquina pertencente a um desenvolvedor, sinalizando comportamentos suspeitos e bloqueando tudo o que não passar na inspeção. Esse é um ponto do pipeline diferente daquele em que a maioria das ferramentas atua. Um scanner que só detecta uma dependência depois que ela já foi resolvida ou instalada está relatando algo que já existe no ambiente. A triagem antes da entrega significa que um pacote que não passar na inspeção nunca chega ao ambiente de execução.
Três incidentes ocorridos em 2026 mostram por que esse momento é importante. O LiteLLM distribuiu um programa para roubo de credenciais em março depois que uma versão corrompida do Trivy em seu próprio pipeline de CI vazou o token PyPI do projeto. Em maio, tarefa duradoura, o Durable Task SDK da Microsoft foi comprometido por meio de um token de API extraído dos segredos do GitHub Actions. E, em junho, O Hades chegou ao PyPI com 37 artefatos maliciosos do wheel, contabilizados como 26 pacotes pelo Orca e 19 pelo Socket. Esses wheels usavam .pth ganchos de inicialização que são acionados quando o interpretador é iniciado, em vez de serem acionados na importação — o mesmo truque que uma das versões maliciosas do LiteLLM havia utilizado três meses antes.
Nenhum dos três precisava de um bug no aplicativo que utilizava o pacote. Cada um seguiu uma rota de publicação autorizada, e a autenticação pode confirmar que uma rota é autorizada sem dizer nada sobre se o artefato que por ela é transmitido é inofensivo. A mesma linhagem da campanha remonta à disseminação do Shai-Hulud pelo npm, e esse é justamente o ponto. Esse padrão é o que a triagem pré-entrega existe para detectar, independentemente do ecossistema em que ele venha a aparecer a seguir.
Recompilar a partir do código-fonte e o que isso realmente verifica
A maioria dos pacotes Python é instalada a partir de artefatos de distribuição que o PyPI não recompila de forma independente para comparar com o repositório de código-fonte do qual alegam ter origem. Um wheel pode apresentar um hash consistente, ser instalado sem problemas e, ainda assim, conter código que o repositório vinculado nunca viu, pois nada no sistema de empacotamento obriga um wheel a corresponder ao seu código-fonte.
O SecureChain recompila pacotes a partir de código-fonte verificado em um ambiente controlado; assim, o que é instalado pode ser rastreado até essa fonte, em vez de um binário opaco do desenvolvedor original. O que essa verificação comprova depende do tipo de pacote.
| Tipo de artefato | Contém | Fidelidade da reconstrução |
|---|---|---|
| Wheel em Python puro | Arquivos-fonte, sem compilação | É uma correspondência próxima, embora os metadados do zip e os carimbos de data/hora sejam diferentes |
| Wheel com extensões compiladas | Binários específicos para cada plataforma, compilados a partir de C, C++ ou Rust | Não é comparável em nível de byte, já que o mesmo código-fonte pode ser compilado de maneiras diferentes dependendo do conjunto de ferramentas |
| Distribuição do código-fonte | Árvore de código-fonte, além de metadados de empacotamento e compilação | É o que mais serve de referência para comparação, embora o backend de compilação possa executar código durante a compilação |
Um wheel puro do Python contém o código-fonte do Python e os metadados de empacotamento gerados, sem binários compilados; portanto, comparar uma recompilação com o wheel publicado é, em grande parte, um exercício no nível dos arquivos. Um wheel criado a partir de extensões em C, C++ ou Rust é um resultado compilado vinculado a uma única cadeia de ferramentas e a uma única plataforma, e sua recompilação produz um binário diferente, em vez de um que corresponda ao original. Essa é uma limitação real, e se aplica a uma parcela significativa do que uma equipe de dados ou de aprendizado de máquina instala. As distribuições de código-fonte ficam no meio termo, sendo menos comuns no dia a dia, mas expõem diretamente o código-fonte e os dados de compilação, o que oferece mais recursos para a recompilação trabalhar.
Portanto, a abordagem correta para o Python é em camadas, e não uniforme. É sólida para Python puro, estruturalmente útil para sdists e menos sólida para qualquer coisa que envolva extensões compiladas. Afirmar que é possível uma reconstrução exata, byte a byte, em todo o PyPI seria exagerar o que a reconstrução pode comprovar, uma vez que há saídas compiladas ou dependentes do ambiente na equação.
Como a reconstrução afeta seus hashes fixados
A restrição de hash limita cada dependência a um ou mais hashes de artefatos explicitamente aprovados.
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtEsses hashes estão vinculados a arquivos específicos. Como o SecureChain recompila pacotes a partir do código-fonte, em vez de disponibilizar novamente o artefato original do PyPI, um pacote recompilado gera um hash diferente daquele publicado pelo PyPI, mesmo quando o código-fonte subjacente corresponde exatamente. Portanto, a mudança implica uma etapa real de migração, já que cada pin que abrange um pacote recompilado pelo SecureChain precisa ser regenerado com base no novo índice.
Planeje isso antes de uma fase piloto, e não durante ela. Primeiro, gere novamente os arquivos de requisitos com base no novo índice em um único repositório; confirme se a instalação foi bem-sucedida e se o aplicativo se comporta da mesma forma; em seguida, defina o escopo da implantação com base no número de repositórios e pipelines que atualmente utilizam hashes fixados. É o tamanho dessa lista, e não o conceito de fixação de hashes, que determina a real magnitude da migração.
Um URL de índice, não dois
Para configurar o pip no SecureChain, basta uma única configuração, utilizando o endpoint que o SecureChain fornece para a sua conta:
pip config set global.index-url https://<your-securechain-endpoint>/simple/Utilização index-url, não extra-index-url. O pip não leva em conta de qual índice um pacote deve vir. Se ambos os índices oferecerem candidatos compatíveis para o mesmo nome de pacote, o pip os avalia em conjunto e pode escolher o candidato público com a versão mais alta, o que representa exatamente o risco de confusão de dependências --extra-index-url cria.
Verifique o que está realmente configurado em um executor de CI, em vez de confiar apenas na documentação. PIP_INDEX_URL e PIP_EXTRA_INDEX_URL definir no ambiente para substituir silenciosamente pip.conf, e uma imagem base herdada de outra equipe é uma forma comum de algo assim passar despercebido.
pip config list
pip config get global.index-urlCorreções aplicadas após a instalação, não apenas verificadas antes
A verificação abrange o estado de um pacote no momento em que ele é entregue. A maior parte do ciclo de vida de uma dependência ocorre depois disso, e descobrir mais tarde que algo está errado é uma tarefa diferente de ter uma compilação corrigida da versão que você está realmente executando.
Um único pacote de nível superior pode trazer dezenas de dependências transitivas por meio do resolvedor do pip, a maioria das quais não foi revisada diretamente por ninguém da equipe, e qualquer uma delas pode introduzir código executável e novas vulnerabilidades no ambiente. O SecureChain aplica a mesma verificação, triagem e aplicação de patches em todo o gráfico de dependências, não apenas no que aparece em requirements.txt.
Novas vulnerabilidades (CVEs) são divulgadas em relação a pacotes que já fazem parte de uma pilha de produção, em um cronograma que ninguém controla. Existem diversas ferramentas que informam sobre elas. O SecureChain monitora essas divulgações e fornece correções alinhadas às versões já fixadas, que é justamente a parte que a saída do pip-audit e a análise manual dos alertas deixam por conta sua.
Eventualmente, um mantenedor deixa de lançar novas versões. O PyPI público continua hospedando as versões existentes, mas nada novo recebe correções a partir desse momento, independentemente do que venha a surgir posteriormente. O Suporte de Ciclo de Vida Infinito da TuxCare dá suporte ao SecureChain nesse aspecto, fazendo o backport de correções para pacotes já presentes no catálogo, de modo que uma equipe não precise escolher entre uma dependência sem correções e uma reescrita que ninguém havia planejado.
Comparando o SecureChain com sua própria pilha de Python
Gere sua própria árvore de dependências, calcule qual a proporção entre código Python puro e extensões compiladas e verifique quantos repositórios já operam no modo de verificação de hash. Essa é a verdadeira dimensão do que a migração para o SecureChain para Python significaria para sua pilha de tecnologia, e não uma estimativa genérica.
Avaliar o SecureChain como uma ferramenta de segurança para pacotes Python significa comparar esses detalhes com o seu próprio fluxo de trabalho, em vez de se basear em uma ficha técnica. Se as lacunas abordadas aqui corresponderem ao que foi identificado na sua última análise de incidentes, solicite um orçamento para o SecureChain para Python e obtenha uma resposta direta sobre a cobertura do catálogo para a sua árvore de dependências.
Perguntas frequentes
O que é uma alternativa ao PyPI?
Um índice que disponibiliza pacotes Python diretamente aos desenvolvedores e sistemas de compilação, em vez de recorrer diretamente ao PyPI público. Algumas opções se limitam a espelhar ou armazenar em cache os pacotes originais, enquanto outras adicionam controles, como triagem e recompilação, o que elimina as lacunas que o simples espelhamento deixa em aberto.
O comando `pip install` pode executar código malicioso?
Sim. A instalação de uma distribuição de código-fonte pode executar código de back-end de compilação controlado pelo pacote durante a compilação do pacote, e um pacote instalado pode executar código posteriormente, no momento da importação ou por meio de mecanismos de inicialização, como um executável .pth arquivo, que era o alvo dos ataques do Hades Wheels. O SecureChain analisa o código-fonte de um pacote antes da entrega, identificando comportamentos suspeitos e bloqueando pacotes maliciosos antes que cheguem a um ambiente.
Um pacote recompilado ainda corresponde à sua fonte original?
Isso depende do tipo de pacote. Os wheels em Python puro não contêm binários compilados; portanto, uma recompilação pode ser comparada ao wheel publicado de forma bastante direta, no nível dos arquivos. Wheels com extensões compiladas em C, C++ ou Rust são resultados de compilação específicos da plataforma, e recompilar um deles produz um binário diferente, em vez de um que corresponda, mesmo quando o código-fonte é idêntico.
A mudança para o SecureChain vai comprometer meus hashes fixados?
Sim, para qualquer pacote que seja recompilado. O SecureChain disponibiliza pacotes recompilados em vez de disponibilizar novamente o artefato original do PyPI; portanto, os hashes diferem daqueles publicados no PyPI público, mesmo quando o código-fonte é o mesmo. A regeneração dos arquivos de requisitos fixados é uma etapa real da migração, não um caso isolado.
O SecureChain abrange dependências transitivas, e não apenas o que consta no arquivo requirements.txt?
Sim. Uma única dependência direta pode trazer dezenas de pacotes que ninguém revisou diretamente, e esses pacotes podem introduzir código executável e vulnerabilidades no ambiente. O SecureChain aplica verificação, triagem e aplicação de patches em todo o gráfico de dependências, em vez de apenas nos pacotes de nível superior listados por uma equipe.
O que acontece quando um pacote do Python chega ao fim de sua vida útil?
Nada, e esse é o problema. O PyPI público não remove o pacote nem o marca como sem suporte, e as versões antigas geralmente continuam disponíveis para download, a menos que sejam retiradas ou colocadas em quarentena por algum outro motivo. O que para é o desenvolvedor original, que deixa de produzir correções de segurança para o pacote assim que os mantenedores se afastam. O SecureChain continua aplicando patches aos pacotes catalogados mesmo após esse ponto; portanto, o fato de um pacote chegar ao fim da vida útil não significa automaticamente que ele permanecerá vulnerável ou que será necessário correr para substituí-lo.
