A estratégia de segurança open source da Astral

 (astral.sh)
1 pontos por GN⁺ 19 일 전 | 1 comentários | Compartilhar no WhatsApp
  • A Astral, que desenvolve ferramentas como Ruff, uv e ty, usadas por desenvolvedores no mundo todo, mantém a segurança e a confiabilidade de todos os seus produtos como valor central
  • Em resposta ao recente aumento de ataques à cadeia de suprimentos, a empresa divulgou técnicas internas para reforçar a segurança em todo o processo de build, distribuição e release
  • Em pipelines de CI/CD baseados em GitHub Actions, aplica um sistema de proteção em múltiplas camadas, incluindo fixação por hash, privilégio mínimo e segregação de segredos
  • Na etapa de release, garante a integridade da distribuição com Trusted Publishing, Sigstore attestations e Immutable Releases
  • Com essa abordagem, a Astral busca elevar o nível de segurança de todo o ecossistema open source e construir um sistema de defesa sustentável

Abordagem de segurança open source da Astral

  • A Astral desenvolve ferramentas como Ruff, uv e ty, usadas por milhões de desenvolvedores no mundo todo, e mantém a segurança e a confiabilidade dessas ferramentas como valor central
  • Com o aumento recente de ataques à cadeia de suprimentos, incluindo casos como os hacks de Trivy e LiteLLM, a Astral divulgou técnicas internas de segurança para garantir a proteção de suas ferramentas e de seus processos de build e distribuição
  • Também compartilha boas práticas de segurança que podem servir de referência para usuários, mantenedores de open source e desenvolvedores de sistemas CI/CD

Segurança em CI/CD

  • A Astral automatiza desenvolvimento e distribuição por meio de amplos workflows de CI/CD baseados em GitHub Actions, usando-os como componente central de segurança
    • Isso garante que builds e testes sejam executados em um ambiente controlado e observável, e não em ambientes locais
  • Reconhecendo que as configurações padrão de segurança do GitHub Actions são frágeis, a empresa adota as seguintes medidas de reforço
    • proibição total de triggers perigosos como pull_request_target e workflow_run
    • fixação de todas as actions em um hash de commit específico (SHA), com validação cruzada para verificar a presença de impostor commits
    • uso conjunto das ferramentas de auditoria unpinned-uses e impostor-commit do zizmor, além de políticas do GitHub
    • fixação por hash de todo o grafo de dependências, incluindo actions indiretas em que a fixação por hash não é possível diretamente
  • Como apenas fixar hashes não é suficiente, a Astral também faz revisão manual para detectar falhas de imutabilidade e, quando necessário, trabalha com projetos upstream para corrigi-las
    • Exemplo: mapear URLs de download de binários e seus hashes para embuti-los em estado imutável
  • As permissões dos workflows são limitadas por padrão a somente leitura, e cada job recebe apenas os privilégios mínimos necessários
  • GitHub Secrets são gerenciados como variáveis de ambiente de deploy separadas por ambiente, impedindo que tarefas de teste e lint acessem segredos de release
  • Como ferramentas auxiliares, a Astral usa zizmor (análise estática) e pinact (fixação automática por hash)

Segurança de repositório e organização

  • Dentro da organização Astral, o número de contas com privilégios de administrador é minimizado, e a maioria dos membros tem apenas permissões de leitura e escrita nos repositórios de que realmente precisa
  • Todos os membros são obrigados a usar autenticação forte em dois fatores (2FA), com no mínimo métodos no nível de TOTP
    • Se o GitHub passar a permitir apenas métodos resistentes a phishing (WebAuthn, Passkeys), a migração será imediata
  • Regras de proteção de branch são aplicadas em toda a organização
    • a branch main não permite force push, e toda mudança só pode entrar via PR
    • é proibida a criação de certos padrões de branch, como advisory-* e internal-*
  • Regras de proteção de tags garantem que tags só possam ser criadas após a conclusão bem-sucedida da distribuição de uma release
    • modificação e exclusão de tags são proibidas, e releases só podem ocorrer a partir da branch main
  • Nem administradores do repositório podem contornar as regras de proteção; toda proteção é imposta no nível da organização
  • A Astral publicou esse conjunto de regras em um gist, para que outros projetos possam usá-lo como referência

Automação

  • Com GitHub Actions, não é possível executar com segurança certas tarefas, como deixar comentários em PRs de terceiros
  • Para isso, a Astral usa o GitHub App astral-sh-bot para tratar eventos com segurança fora do Actions
    • O GitHub App recebe os mesmos dados de evento, mas executa em um ambiente onde código e dados ficam separados
  • Ainda assim, o App não elimina credenciais sensíveis
    • Vulnerabilidades como SQLi e prompt injection ainda podem existir, portanto ele deve ser desenvolvido com o mesmo nível de segurança exigido de um software comum
    • Usar um App não significa, por si só, garantia de segurança na execução de código não confiável
  • A abordagem com GitHub App é vantajosa em segurança, mas aumenta a complexidade
    • é necessário desenvolver e hospedar o App, o que pode ser um peso para desenvolvedores individuais ou projetos pequenos
    • o framework Gidgethub para Python simplifica o desenvolvimento
  • A Astral pretende publicar o astral-sh-bot como open source e recomenda como referência o tutorial da Mariatta

Segurança de release

  • As ferramentas da Astral são distribuídas por vários canais além do GitHub, como PyPI, Homebrew e imagens Docker
  • Para evitar ataques à cadeia de suprimentos, a empresa adota as seguintes medidas
    • uso de Trusted Publishing para eliminar credenciais de registries
    • geração de attestations com base em Sigstore para garantir a vinculação criptográfica entre artefatos de build e workflows
      • uso do recurso Immutable Releases do GitHub para impedir alterações após a publicação
      • não utilização de cache de build, bloqueando ataques por contaminação de cache
      • isolamento do processo de release em um deployment environment dedicado
      • exigência de aprovação de outros membros da equipe para ativar o ambiente de release, evitando releases maliciosas por comprometimento de uma única conta
      • manutenção de aprovações em múltiplas etapas com o ambiente release-gate e encaminhamento de aprovação baseado em GitHub App
      • tags só podem ser criadas após o sucesso da release
      • o instalador standalone verifica a integridade dos binários com checksums embutidos
      • após a release, atualização de documentação, manifests de versão e hooks do pre-commit são feitas com uma conta de bot dedicada e PATs granulares
      • no futuro, está prevista a adição de assinatura de código para macOS e Windows

Segurança de dependências

  • A Astral usa Dependabot e Renovate para gerenciar atualizações de dependências e alertas de vulnerabilidade
  • Um período de cooldown é aplicado para adiar atualizações logo após novos releases, reduzindo o risco de ataques temporários à cadeia de suprimentos
    • o Renovate oferece suporte a configuração de cooldown por grupo, e essa flexibilização é aplicada às dependências próprias
  • A empresa mantém colaboração contínua e contribuições de segurança com projetos upstream importantes
  • Também coopera com a Python Packaging Authority e a Python Security Response Team para compartilhar informações de segurança
  • A inclusão de novas dependências é analisada com cautela, e há esforço para remover dependências desnecessárias
    • em especial, evita dependências que incluam blobs binários e desativa funcionalidades desnecessárias
  • Por meio do OSS Fund, fornece apoio financeiro a projetos open source essenciais

Conclusão e principais lições

  • A segurança em open source é uma combinação de problemas técnicos e sociais e exige resposta contínua
  • Princípios principais enfatizados pela Astral
    • reconhecer os limites do CI/CD e, quando inevitável, usar abordagens externas e isoladas, como GitHub Apps
    • eliminar e minimizar credenciais de longo prazo, usando Trusted Publishing e autenticação OIDC
    • fortalecer o processo de release, com regras de aprovação, tags, branches e Immutable Releases
    • manter consciência sobre dependências, reforçando também a segurança de projetos upstream por meio de ferramentas e colaboração
  • A Astral continuará avaliando e aprimorando essas técnicas, com a intenção de evoluir suas defesas conforme muda o comportamento dos atacantes

Resumo das notas

  • A PEP 740 do PyPI permite upload de attestations, mas no momento ainda não é compatível com a implementação de Trusted Publishing da Astral, por isso sua adoção está em espera
  • Embora checksums no script de instalação tenham efeito limitado quando executados diretamente com curl ... | bash, eles ainda são úteis ao fazer vendoring dentro de CI/CD

Leituras relacionadas

1 comentários

 
GN⁺ 19 일 전
Opiniões no Hacker News

  • Parece que há etapas demais para usar o CI do GitHub com segurança
    Com uma estrutura assim, acho impossível operar de forma segura do ponto de vista de segurança
    Dá a sensação de que não dá para construir segurança de cadeia de suprimentos sobre um sistema que nem segue princípios básicos como separação de privilégios ou isolamento

    • Penso de forma parecida. Recentemente estudei como executar com segurança código escrito por agentes no GitHub Actions, e tive algum sucesso com sandbox-action
      Mas a configuração é tão delicada que não parece uma abordagem escalável. Se os padrões fossem mais seguros, isso já ajudaria muito
    • Fico curioso se alguém já viu algum sistema de build alternativo que valha a pena usar no lugar desse CI complexo do GitHub
      Depois de ler tudo, fiquei pensando se essa complexidade talvez seja um problema inerente dessa área
    • Na verdade, isso não é diferente do problema dos registries de pacotes em geral
      A maioria não oferece suporte a releases imutáveis e, mesmo quando oferece, a estrutura de puxar automaticamente versões novas continua vulnerável a ataques
      Para ser realmente seguro, seria preciso gerenciar dependências verificadas em versões fixas num registry próprio, mas isso é algo que só uma empresa como o Google consegue fazer

  • O binário uv do stagex que nossa equipe criou é o único no mundo construído com bootstrap completo a partir do código-fonte e artefatos determinísticos com múltiplas assinaturas
    Ele usa um sistema de assinaturas com smartcard ligado a uma rede de confiança de 25 anos e mais de 5.000 chaves
    Mesmo assim, é frustrante ver voluntários levando esse tipo de segurança de cadeia de suprimentos mais a sério

    • O mercado já deu a resposta. As pessoas querem conveniência, não segurança
      Mesmo que ferramentas como OpenClaw façam vazar chaves e segredos, os usuários continuam usando
      Você tenta reduzir a superfície de ataque, mas o mercado está ampliando ela
    • Na verdade, isso não é motivo para irritação. Você está criando uma distribuição Linux reproduzível, e parceiros vendem serviços de suporte em cima disso
      Sem voluntários, projetos como o Debian também não existiriam. Em vez de reclamar, é melhor competir com resultados melhores
    • (Sou o autor do texto) A quantidade ou a idade das chaves não é uma medida de confiança
      No fim, se você está fornecendo artefatos construídos por terceiros, não está claro qual é o modelo de ameaça
      Todos os builds do uv saem de resolução travada e fornecem artefatos assinados. O valor de commits assinados por outro conjunto de identidades não é claro
    • A própria licença open source foi desenhada para que empresas possam usar de graça
      Não há motivo para a OpenAI gastar dinheiro reforçando a segurança da cadeia de suprimentos
    • A aquisição aconteceu há só algumas semanas; se a OpenAI já tivesse mudado o processo de build, isso seria até mais estranho
      Entendo a crítica técnica, mas pela linha do tempo acho forçado jogar isso nas costas da OpenAI

  • Para referência, o Trusted Publishing do PyPI foi implementado em conjunto por William Woodruff e a equipe da Trail of Bits

  • Queria perguntar à equipe da Astral como ela lida com uma dependência tão grande do próprio GitHub, mesmo com todo esse esforço
    Como vocês responderiam se o GitHub fosse comprometido ou se uma configuração mudasse por causa de um bug?

    • Nós também nos comunicamos diretamente com o GitHub. Como eles são infraestrutura crítica, monitoramos com atenção mudanças na plataforma
    • O GitHub realmente tem muitos bugs. É comum até workflow falhar ao clonar branches do próprio repositório

  • O ecossistema open source é resiliente, mas ainda faltam soluções de sandbox para código de terceiros
    Sempre que uso o uv, destacam como é fácil gerenciar várias versões de Python, mas isso também significa que ele é executado na máquina host sem isolamento, o que me deixa desconfortável

    • Eu sempre uso o uv dentro de Docker. Nesse caso, ele é bem prático

  • Um grande problema atual da cadeia de suprimentos é que muitas ferramentas e dependências são baixadas sem verificação de procedência
    Por isso estou desenvolvendo o asfaload, uma solução open source de autenticação de arquivos com multissig
    É uma estrutura que pode evitar incidentes como o do axios

    • Esse não é exatamente o objetivo das release attestations? Veja a documentação relacionada
    • A direção da abordagem parece correta. Só que, como o código ou produto ainda não está público, é difícil avaliar
    • Acho melhor inspecionar todo o código com ferramentas automáticas de auditoria de código do que focar em verificar autores específicos

  • Mesmo fixando o GitHub Actions por commit SHA, ainda há risco se a action puxar outras dependências
    A solução de verdade é posse direta do código no pipeline de CI, ou então fazer fork e manter internamente

    • O artigo também fala disso. Nós adotamos uma abordagem de defense in depth
      Auditamos todas as actions e, se houver dependências mutáveis, nós as corrigimos ou substituímos (sou da Astral)
    • Segurança sempre envolve trade-offs
      Gerenciar toda a stack por conta própria é o mais seguro, mas não é realista
      Fixar por hash é um reforço de segurança que quase sai de graça
      No fim, o importante é ter clareza sobre até onde vai sua confiança
    • De qualquer forma, ao usar actions de terceiros, você precisa ler e verificar o código por conta própria. Fazer fork por si só não resolve

  • Vendo os casos recentes do Trivy e do litellm, fica claro que um guia de segurança para processos de release é realmente necessário
    O conselho deste texto é prático e pode ser aplicado imediatamente
    No fundo, a segurança da cadeia de suprimentos depende de quão seguras são as configurações padrão das plataformas das quais dependemos

  • Excelente visão geral. Parece que pode servir como material de referência útil para outros projetos open source

  • Eu mantenho o repomatic, uma CLI em Python e ferramenta de workflow reutilizável
    Ela já inclui por padrão a maior parte das práticas de segurança citadas neste texto
    O objetivo é criar um ambiente em que segurança seja o padrão
    Depois de ler o texto, adicionei uma verificação de política de aprovação de PRs de forks
    Mais detalhes no repositório no GitHub