GitHub Lança Releases Imutáveis: Nova Era de Segurança na Supply Chain

Olá HaWkers, o GitHub acaba de lançar uma das features de segurança mais importantes dos últimos anos: releases imutáveis, agora disponíveis para todos em 28 de outubro de 2025.

Essa funcionalidade protege assets e tags de manipulação após publicação, garantindo que o software que você publica - e seus usuários consomem - permanece seguro e confiável. Mas o que isso significa na prática?

O Problema que Releases Imutáveis Resolvem

Antes de entender a solução, precisamos entender o problema crítico de segurança que existe no ecossistema de software:

Ataques à Supply Chain de Software

Nos últimos anos, ataques à supply chain de software se tornaram uma das maiores ameaças de segurança:

Exemplos Reais:

Modificação de releases após publicação
Substituição de binários por versões maliciosas
Tags git movidas para commits diferentes
Assets adulterados sem deixar rastros
Versões "trojanizadas" de bibliotecas populares

Estatísticas Alarmantes:

Aumento de 742% em ataques à supply chain (2020-2023)
62% das empresas sofreram algum incidente relacionado
Custo médio de US$ 4.3 milhões por incidente
Tempo médio de detecção: 287 dias

🔥 Contexto: Um único pacote comprometido pode afetar milhões de aplicações que dependem dele, criando um efeito cascata devastador.

O Problema Técnico

Antes dos releases imutáveis, era possível:

Cenários de Risco:

Modificar assets: Um atacante com acesso poderia substituir um .zip ou binário
Mover tags: Tags git podiam apontar para commits diferentes
Adicionar malware: Adicionar arquivos maliciosos a um release existente
Sem auditoria: Difícil detectar quando mudanças ocorreram
Zero confiança: Impossível garantir integridade sem verificações manuais

Como Funcionam os Releases Imutáveis

O GitHub implementou três componentes principais:

1. Assets Imutáveis

Uma vez publicado como imutável, o release não pode ser modificado:

Proteções:

Assets não podem ser adicionados após publicação
Assets existentes não podem ser modificados
Assets não podem ser deletados
Metadados do release ficam travados

Na Prática:

# Tentativa de modificar asset em release imutável
gh release upload v1.0.0 new-binary.zip
# Error: Cannot modify immutable release v1.0.0

# Tentativa de deletar asset
gh release delete-asset v1.0.0 binary.zip
# Error: Cannot delete asset from immutable release

2. Proteção de Tags

Tags associadas a releases imutáveis são protegidas:

Garantias:

Tag não pode ser deletada
Tag não pode ser movida para outro commit
Mantém referência permanente ao código exato

Exemplo:

# Tag de release imutável
git tag -d v1.0.0
# Error: tag 'v1.0.0' is protected by immutable release

# Tentativa de mover tag
git tag -f v1.0.0 abc123
# Error: Cannot move tag associated with immutable release

3. Attestations (Atestações)

Releases imutáveis recebem attestations assinados:

Como Funciona:

GitHub gera uma assinatura criptográfica do release
Usa formato Sigstore bundle (padrão da indústria)
Permite verificação de autenticidade e integridade
Compatível com ferramentas CI/CD existentes

Verificação:

# Verificar attestation usando GitHub CLI
gh attestation verify v1.0.0 \
  --owner myorg \
  --repo myrepo

# Verificar usando Sigstore tooling
cosign verify-blob \
  --bundle attestation.json \
  --certificate-identity "https://github.com/myorg/myrepo" \
  binary.zip

# Output mostra:
# ✓ Signature verified
# ✓ Certificate identity matches
# ✓ Timestamp valid
# ✓ Release is immutable

Habilitando Releases Imutáveis

A configuração é simples e pode ser feita em diferentes níveis:

Nível de Repositório

# Settings > Code security and analysis > Immutable releases
- Navigate to repository settings
- Enable "Immutable releases"
- All new releases become immutable automatically

Comportamento:

Novos releases são imutáveis por padrão
Releases antigos permanecem mutáveis (até serem republicados)
Desabilitar não afeta releases já imutáveis

Nível de Organização

Para aplicar a todos os repositórios:

# Organization Settings > Code security > Immutable releases
- Navigate to organization settings
- Enable for all repositories
- Optionally: allow repositories to override

Vantagens:

Política centralizada de segurança
Garante consistência em todos os projetos
Reduz erro humano

Integração com CI/CD

Exemplo de workflow GitHub Actions:

name: Release Imutável
on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      attestations: write

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          make build
          tar -czf release.tar.gz dist/

      - name: Create Immutable Release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          immutable: true  # Release será imutável

      - name: Upload Assets
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./release.tar.gz

      - name: Generate Attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: './release.tar.gz'

Benefícios Para Diferentes Públicos

Para Mantenedores de Open Source

Vantagens:

Proteção contra conta comprometida
Usuários podem confiar que releases não mudam
Reduz responsabilidade em caso de ataque
Demonstra comprometimento com segurança

Caso de Uso:

## Segurança dos Nossos Releases

Todos os releases deste projeto são imutáveis:
- ✓ Assets não podem ser modificados após publicação
- ✓ Tags são protegidas contra alteração
- ✓ Attestations verificáveis para cada release
- ✓ Conformidade com supply chain security best practices

Verifique qualquer release:
`gh attestation verify <version> --owner <org> --repo <repo>`

Para Empresas e Times de Segurança

Conformidade:

Atende requisitos de SLSA (Supply chain Levels for Software Artifacts)
Facilita auditorias de segurança
Reduz superfície de ataque
Permite rastreamento completo de provenance

Políticas de Segurança:

Requisito	Sem Imutabilidade	Com Imutabilidade
Verificação de integridade	Manual, complexa	Automática
Auditoria de mudanças	Difícil rastrear	Impossível mudar
Compliance SLSA	Nível 1-2	Nível 3+
Confiança em releases	Baixa	Alta
Resposta a incidentes	Reativa	Preventiva

Para Desenvolvedores Consumidores

Confiança:

Saber que o código não foi alterado desde publicação
Verificação criptográfica de autenticidade
Proteção contra man-in-the-middle
Reprodutibilidade de builds

Verificação Simples:

# Antes de usar uma dependência, verificar
gh attestation verify v2.1.0 \
  --owner popular-lib \
  --repo awesome-package

# Se verificar, você tem garantias:
# 1. Assets não foram modificados
# 2. Tag aponta para commit original
# 3. Release foi publicado por mantenedor legítimo
# 4. Provenance está documentado

Comparação: Antes vs Depois

Cenário de Ataque: Conta Comprometida

Sem Releases Imutáveis:

1. Atacante obtém acesso à conta de mantenedor
2. Modifica assets de release v1.0.0 popular
3. Substitui binário por versão com backdoor
4. Milhares de usuários baixam versão comprometida
5. Ataque não é detectado por semanas
6. Dano massivo ao ecossistema

Com Releases Imutáveis:

1. Atacante obtém acesso à conta de mantenedor
2. Tenta modificar release v1.0.0
3. GitHub bloqueia: "Cannot modify immutable release"
4. Atacante tenta criar novo release malicioso
5. Usuários verificam attestation
6. Attestation falha: assinatura inválida
7. Ataque é imediatamente detectado e bloqueado

Integração com Sigstore

Um dos aspectos mais poderosos é a compatibilidade com Sigstore:

O que é Sigstore?

Sigstore é um padrão open source para assinatura e verificação de software:

Componentes:

Cosign: ferramenta de assinatura
Rekor: log de transparência
Fulcio: autoridade certificadora

Por que Importa:

Padrão da indústria
Adotado por Kubernetes, npm, PyPI, etc.
Verificação independente do GitHub
Auditável publicamente

Verificação Offline

Você não precisa confiar apenas no GitHub:

# Baixar attestation bundle
gh attestation download v1.0.0 \
  --owner myorg \
  --repo myrepo \
  --output attestation.json

# Verificar localmente usando cosign
cosign verify-blob \
  --bundle attestation.json \
  --certificate-identity-regexp ".*github.com/myorg/myrepo.*" \
  myapp.tar.gz

# Verificar no log público Rekor
rekor-cli search \
  --artifact myapp.tar.gz

Adoção e Melhores Práticas

Estratégia de Migração

Para Projetos Existentes:

Fase 1: Preparação (Semanas 1-2)

Documente processo atual de release
Identifique dependências e integrações
Comunique mudanças para usuários

Fase 2: Teste (Semanas 3-4)

Habilite em repositório de teste
Valide processo de release
Teste verificação de attestations

Fase 3: Rollout (Semanas 5-6)

Habilite em repositórios de produção
Próximo release será imutável
Atualize documentação

Fase 4: Evangelização (Contínuo)

Ensine usuários a verificar releases
Promova adoção da prática
Compartilhe sucessos

Checklist de Implementação

Antes de habilitar releases imutáveis:

Pré-requisitos:

Time entende o que é imutabilidade
Processo de release está documentado
CI/CD suporta attestations
Plano de comunicação está pronto
Rollback strategy está definido

Pós-habilitação:

Primeiro release imutável publicado com sucesso
Attestation pode ser verificado
Documentação atualizada
Usuários sabem como verificar
Monitoramento em funcionamento

Limitações e Considerações

O que Releases Imutáveis NÃO Fazem

É importante entender os limites:

Não Protege:

Código malicioso no commit original
Vulnerabilidades não descobertas
Dependências comprometidas
Chaves de assinatura roubadas

Requer:

Práticas de segurança no desenvolvimento
Code review rigoroso
Análise de dependências
Rotação de credenciais

Quando NÃO Usar

Situações onde imutabilidade pode não ser ideal:

Releases em desenvolvimento ativo (use drafts)
Projetos internos sem requisitos de segurança
Protótipos e experimentos
Casos onde releases precisam ser corrigidos rapidamente

Alternativa: Crie novo release corrigido em vez de modificar o existente.

O Futuro da Supply Chain Security

Releases imutáveis são parte de uma tendência maior:

Iniciativas Relacionadas

SLSA (Supply chain Levels for Software Artifacts):

Framework de segurança desenvolvido por Google
Define níveis de maturidade (1-4)
Releases imutáveis ajudam a alcançar nível 3+

SBOM (Software Bill of Materials):

Documentação completa de componentes
GitHub está integrando com releases
Transparência total de dependências

Verificação Automatizada:

Ferramentas verificam automaticamente attestations
Integração em gerenciadores de pacotes
Bloqueio de packages não verificados

Conclusão

O lançamento de releases imutáveis pelo GitHub marca uma evolução significativa na segurança de software. Não é apenas uma feature nova, mas uma mudança fundamental em como pensamos sobre distribuição de software.

Para mantenedores de projetos, especialmente open source, habilitar releases imutáveis é uma das formas mais simples e efetivas de proteger seus usuários. Para empresas, é um passo essencial em direção a uma supply chain mais segura e auditável.

A melhor parte? A implementação é simples, o custo é zero, e os benefícios são imensos. Com ataques à supply chain crescendo exponencialmente, adotar medidas preventivas não é mais opcional - é essencial.

Se você quer entender mais sobre como grandes empresas estão lidando com segurança em escala, recomendo que dê uma olhada em outro artigo: Cloudflare Reescreve Sistema Principal em Rust onde você vai descobrir como segurança e performance podem andar juntas.