Segurança de CI/CD para projetos open source: controlando a execução

O Cilium adotou uma abordagem proativa e alinhada com os padrões mais rigorosos de segurança da cadeia de suprimentos, como o SLSA (Supply-chain Levels for Software Artifacts) nível 3 e as recomendações do NIST SP 800-204D. Ao restringir quem pode disparar workflows no GitHub Actions — limitando execuções a branches protegidos e pull requests de colaboradores com permissões explícitas — o projeto mitigou riscos de Envenenamento de Execução de Pipeline (PPE), um vetor crítico explorado em incidentes recentes como o sequestro do LiteLLM no PyPI e o typosquatting de forks do Trivy. A separação estrita entre código confiável (main, tags assinadas) e não confiável (forks externos, PRs de contribuidores não mantenedores) impede que código não auditado execute com privilégios elevados, enquanto o pinning de ações por hash imutável evita redirecionamentos silenciosos para versões comprometidas — prática confirmada como essencial pelo GitHub Security Lab e pela OWASP CI/CD Top 10.

A exigência de revisões de segurança para qualquer alteração na configuração do CI (ex.: arquivos .github/workflows/*.yml) reflete uma mudança cultural: o pipeline passa a ser tratado como código crítico, sujeito ao mesmo rigor de code review que o código-fonte. Isso é especialmente relevante em projetos CNCF como o Cilium, onde 97% dos aplicativos modernos dependem de código aberto (GitHub Octoverse 2023) e onde um único ponto fraco no CI pode impactar milhares de organizações — como demonstrado no caso SolarWinds, cujo malware permaneceu indetectado por 11 meses após a infecção do pipeline de compilação.

Essa estratégia importa porque ataques à cadeia de suprimentos de software cresceram 1.300% nos últimos anos (Sonatype State of the Software Supply Chain 2024), e 84% das bases de código analisadas contêm ao menos uma vulnerabilidade conhecida (Synopsys OSSRA 2024). O controle da execução em CI/CD é o primeiro e mais eficaz ponto de contenção: sem ele, credenciais privilegiadas, segredos de nuvem e chaves de assinatura de releases ficam expostos a código não confiável. Diferentemente de correções pós-comprometimento, medidas como pinning de hash, isolamento de credenciais e redução de permissões são preventivas, baratas de implementar e têm alto ROI — bloqueando vetores como injeção de comandos maliciosos em workflows, exfiltração de variáveis de ambiente e publicação de pacotes trojanizados no npm ou PyPI.

Para equipes de DevOps e segurança, isso significa que a governança do CI deixou de ser uma questão operacional secundária e tornou-se um requisito regulatório implícito. Frameworks como o NIST SSDF e a diretriz brasileira do CGU sobre segurança de software exigem rastreabilidade completa da proveniência do código executado — algo só possível com SBOM gerado continuamente, verificações de integridade criptográfica (ex.: sigstore/cosign) e registros auditáveis de quem acionou cada build e sob quais condições.

Para desenvolvedores e engenheiros de DevOps, as mudanças do Cilium representam um novo padrão operacional: workflows devem ser escritos com princípios de menor privilégio — sem permissions: write-all, usando pull_request_target apenas quando estritamente necessário e sempre com validação explícita de origem. Ferramentas como Trivy (para varredura de imagens e IaC), Gitleaks (detecção de segredos hardcoded) e Semgrep (análise estática personalizada) devem ser integradas como gateways obrigatórios antes de qualquer merge em branches protegidos. Além disso, o uso de ações pré-aprovadas em um repositório interno (com hashes fixados) substitui a dependência de ações públicas não auditadas — prática já adotada por times do Banco Central do Brasil e da Receita Federal em pipelines críticos.

O impacto prático inclui aumento leve de tempo de ciclo para contribuições externas (devido às revisões de segurança no CI), mas ganho substancial em confiança: releases assinadas com cosign, SBOM em CycloneDX gerado automaticamente e logs de execução imutáveis permitem auditorias rápidas e conformidade com LGPD, ISO/IEC 27001 e frameworks de cibersegurança do governo federal. Equipes que adotam esse modelo relatam redução de 70% em incidentes relacionados a dependências maliciosas (dados da Snyk 2024), pois o foco muda de 'corrigir depois' para 'nunca permitir a execução'.