A cadeia de suprimentos de software se tornou um dos vetores de ataque mais explorados em 2025 e 2026. O ataque ao XZ Utils em 2024 — onde um contribuidor comprometeu deliberadamente uma biblioteca de compressão presente em praticamente todas as distribuições Linux — mostrou a escala do risco: uma única dependência comprometida pode afetar milhões de sistemas simultaneamente.

Projetos de código aberto são infraestrutura crítica. A maioria é mantida por voluntários com recursos limitados, tornando a implementação de boas práticas de segurança um desafio real. Este artigo cobre 10 estratégias concretas para proteger repositórios e pipelines de projetos open source.

1. Habilitar proteção de branch principal com revisão obrigatória

Nunca permita push direto para a branch principal (main/master). Configure proteção de branch que exija pelo menos uma revisão de código aprovada antes de qualquer merge, proíba force push e exija que a branch esteja atualizada com a principal antes do merge.

No GitHub, isso é configurado em Settings > Branches > Branch protection rules. Em projetos críticos, exija revisão de dois mantenedores independentes — o padrão adotado pelo kernel Linux e pela maioria dos projetos de infraestrutura de alto impacto.

2. Assinar commits com GPG ou SSH

Assinatura de commits cria uma trilha auditável e verificável de autoria. Sem assinatura, qualquer pessoa com acesso ao repositório pode fazer commits se passando por outro contribuidor — a identidade no git config é facilmente falsificável.

git config --global commit.gpgsign true
git config --global user.signingkey <KEY_ID>

O GitHub exibe um badge "Verified" em commits assinados com chave registrada na conta. Habilite "Vigilant mode" na conta GitHub para marcar commits não-assinados como "Unverified" — sinal visual imediato de commit suspeito.

3. Implementar revisão de dependências (Dependency Review)

Cada nova dependência adicionada ao projeto é um vetor de ataque potencial. O GitHub Dependency Review verifica automaticamente se pull requests adicionam dependências com vulnerabilidades conhecidas, comparando contra o banco de dados do GitHub Advisory Database.

Configure o workflow de Dependency Review no repositório para bloquear merge de PRs que adicionem dependências com CVEs críticos ou altos sem justificativa documentada.

4. Habilitar Dependabot para atualizações automáticas

O Dependabot monitora as dependências do projeto e abre pull requests automaticamente quando versões com correções de segurança são publicadas. Configurar o Dependabot elimina o risco de dependências desatualizadas passarem despercebidas.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

5. Usar SAST no pipeline de CI/CD

SAST (Static Application Security Testing) analisa o código-fonte em busca de vulnerabilidades sem executá-lo. Integrar SAST ao pipeline de CI garante que cada pull request seja verificado automaticamente antes do merge.

Ferramentas gratuitas para projetos open source: CodeQL (GitHub, gratuito para projetos públicos), Semgrep (versão community), Bandit (Python), gosec (Go). O CodeQL tem suporte oficial do GitHub e cobre C/C++, Java, JavaScript, Python, Go e Ruby.

6. Publicar uma política de segurança (SECURITY.md)

Um arquivo SECURITY.md na raiz do repositório define como pesquisadores de segurança devem reportar vulnerabilidades — qual canal usar, qual informação incluir e qual o prazo de resposta esperado. Sem essa política, vulnerabilidades são reportadas em issues públicas, expondo usuários antes de uma correção estar disponível.

O GitHub exibe um botão "Report a vulnerability" automaticamente quando o repositório tem uma política de segurança e o Private Security Reporting habilitado. Este canal permite que pesquisadores abram relatórios privados, visíveis apenas para mantenedores.

7. Assinar releases com checksums verificáveis

Cada release publicado deve incluir checksums SHA-256 dos artefatos e, idealmente, assinatura GPG do mantenedor. Isso permite que usuários verifiquem que o arquivo baixado não foi alterado após a publicação — proteção contra ataques de mirror comprometido.

sha256sum release-v1.2.3.tar.gz > SHA256SUMS
gpg --detach-sign SHA256SUMS

Em 2026, o padrão Sigstore (sigstore.dev) emergiu como a solução mais acessível para assinatura de releases em projetos open source, com suporte nativo no npm, PyPI, Maven e outros registros de pacotes.

8. Limitar permissões de tokens de CI/CD

Tokens de acesso usados em pipelines de CI/CD devem ter permissões mínimas necessárias — não tokens com acesso de administrador ao repositório. Cada workflow do GitHub Actions deve declarar explicitamente as permissões que precisa.

permissions:
  contents: read
  pull-requests: write

Tokens com escopo excessivo comprometidos em um workflow podem ser usados para modificar o repositório, publicar releases maliciosas ou acessar segredos. Limitar permissões reduz o impacto de um workflow comprometido.

9. Auditar contribuidores e acessos periodicamente

O ataque ao XZ Utils envolveu um contribuidor que ganhou confiança ao longo de dois anos antes de introduzir código malicioso. Revisão periódica de quem tem acesso de write e admin ao repositório, remoção de acessos de ex-mantenedores inativos e uso de 2FA obrigatório para todos os colaboradores são práticas básicas frequentemente negligenciadas.

GitHub Organizations permitem configurar MFA obrigatório para todos os membros e auditar logins e ações via o Audit Log da organização. A gestão de identidades digitais é tão relevante em projetos open source quanto em ambientes corporativos.

10. Participar do OpenSSF e adotar o Scorecard

O OpenSSF (Open Source Security Foundation) mantém o Scorecard, uma ferramenta que avalia automaticamente práticas de segurança de um repositório em uma escala de 0 a 10. A análise cobre branch protection, assinatura de commits, CI/CD, licença, SAST, dependências e mais de 15 outros critérios.

docker run -e GITHUB_AUTH_TOKEN=<TOKEN>   gcr.io/openssf/scorecard:stable   --repo=github.com/<org>/<repo>

Publicar o badge do Scorecard no README é um sinal de transparência para usuários e contribuidores — e um roteiro claro de melhorias para os mantenedores. Para projetos com impacto de segurança significativo, a gestão de falhas em código aberto deve ser um processo contínuo, não reativo.

Construa segurança em software com formação técnica sólida

A IBSEC forma profissionais para implementar segurança em pipelines de desenvolvimento e infraestrutura de software: