Astral, criadora do Ruff e do uv, revela em detalhes sua estratégia de segurança open source
(astral.sh)A Astral cria ferramentas das quais milhões de desenvolvedores no mundo todo dependem (Ruff, uv, ty) e, após os recentes incidentes de comprometimento da cadeia de suprimentos envolvendo Trivy e LiteLLM, divulgou como coloca suas práticas de segurança em ação. O público-alvo se divide em três grupos: usuários, outros mantenedores de open source e desenvolvedores de sistemas de CI/CD.
1. Segurança de CI/CD
As configurações padrão de segurança do GitHub Actions são frágeis, e incidentes de comprometimento como os da Ultralytics, tj-actions e Nx tiveram origem em gatilhos arriscados como pull_request_target. A forma como a Astral responde a isso é a seguinte:
Proibição total de gatilhos perigosos
A organização proíbe por completo gatilhos como pull_request_target e workflow_run, que são quase impossíveis de usar com segurança. Muitos projetos acham que precisam desses gatilhos, mas na prática, na maioria dos casos, um gatilho pull_request com menos privilégios ou simples logs de workflow já bastam.
Fixação por hash de commit das Actions (Hash Pinning)
Em vez de usar tags ou branches (que podem mudar), a Astral fixa tudo em um SHA de commit específico e faz validação cruzada para garantir que esse commit corresponde de fato ao estado do release, evitando "commits impostores". Ela usa zizmor junto com políticas nativas do GitHub, e o hash pinning também é aplicado a todas as actions aninhadas chamadas indiretamente.
Princípio do menor privilégio
No nível da organização, as permissões padrão são configuradas como somente leitura, e todos os workflows começam com permissions: {}, adicionando apenas as permissões necessárias no nível de job. Os segredos também são isolados por ambiente de implantação, em vez de ficarem no nível da organização ou do repositório, para que jobs de teste não consigam acessar segredos de release.
2. Segurança de repositório e organização
O número de administradores e contas com alto privilégio é mantido no mínimo, e a maioria dos membros da organização tem apenas permissões de leitura e escrita nos repositórios de que realmente precisa. O 2FA exige pelo menos TOTP, algo mais forte que o padrão do GitHub (qualquer método), e no futuro a ideia é endurecer isso para permitir apenas WebAuthn e passkeys.
A branch main é protegida com regras que impedem force push e exigem pull requests, enquanto tags de release só podem ser criadas após o sucesso da implantação. Em especial, a organização aplica essas regras no nível organizacional para que nem mesmo administradores do repositório consigam contorná-las.
3. Automação (uso de GitHub App)
Tarefas que não podem ser feitas com segurança no GitHub Actions, como deixar comentários em PRs de terceiros, são separadas para o GitHub App astral-sh-bot. Ainda assim, a Astral ressalta que GitHub Apps também não são isentos de vulnerabilidades, e que, quando houver necessidade de executar código não confiável, o gatilho pull_request deve ser usado obrigatoriamente.
4. Segurança de release
Para publicar no PyPI, crates.io e NPM, a Astral usa Trusted Publishing, o que permite fazer deploy sem credenciais de longo prazo. Para binários e imagens Docker, ela anexa attestations baseadas em Sigstore, criando uma ligação criptográfica entre os artefatos de release e os workflows.
Ela também usa o recurso de releases imutáveis (immutable releases) do GitHub para impedir adulteração posterior de builds já publicados e proíbe o uso de cache durante builds de release, bloqueando ataques de cache poisoning.
O próprio processo de release tem proteção dupla: ativar o ambiente de release exige aprovação manual de pelo menos outro membro autorizado da organização. Em outras palavras, para realizar um release malicioso, seria necessário comprometer ao mesmo tempo duas contas com 2FA forte.
5. Segurança de dependências
A Astral usa Dependabot e Renovate para gerenciar atualizações de dependências e alertas de vulnerabilidades conhecidas, mas também adota uma política de "cooldown", evitando atualizar imediatamente após um novo release. O objetivo é minimizar o impacto de dependências comprometidas temporariamente. Esse recurso já vem embutido no uv.
Ela também mantém conexões sociais com projetos e grupos de trabalho próximos, como a Python Packaging Authority (PyPA) e o Python Security Response Team, para compartilhar informações — por exemplo, quando um problema relatado no pip também afeta o uv. A adição de novas dependências é tratada com cautela, dependências com blobs binários são evitadas e recursos desnecessários são desativados.
Para ajudar na sustentabilidade dos projetos dos quais depende, a empresa também faz contribuições financeiras por meio do OSS Fund.
Resumo das principais recomendações
A Astral destaca quatro princípios centrais: reconhecer os limites do CI/CD e abandonar sem hesitação tarefas que não podem ser feitas com segurança ou separá-las em um GitHub App; eliminar credenciais de longo prazo sempre que possível e isolá-las ao escopo mínimo; reforçar o processo de release com ambientes de implantação, aprovações e tags imutáveis; e acompanhar continuamente a saúde de toda a árvore de dependências.
Implicações
Para quem acompanha de perto PyPI e a segurança da cadeia de suprimentos, este texto vai além de um simples guia de segurança: é um caso prático de como projetar a estrutura de confiança de todo o ecossistema open source. Em especial, Trusted Publishing, a política de cooldown e o processo de release com dupla aprovação são referências úteis para projetos open source de maior porte.
Original: Astral Blog, 2026.04.08
Ainda não há comentários.