Segurança em CI/CD: a importância de estudar, auditar e aprender com pipelines de bons projetos

Fri, 30 Oct 2026 12:10:32 +0000

Pipelines de CI/CD são frequentemente tratados como simples mecanismos de automação: executam testes, compilam aplicações, geram artefatos e realizam deploys. Entretanto, eles também representam uma das superfícies de ataque mais importantes de um ambiente de desenvolvimento moderno.

Um pipeline possui acesso a repositórios, tokens, credenciais, registries, ambientes de produção, dependências externas e, em muitos casos, permissões para modificar recursos de infraestrutura. Isso significa que uma falha na configuração de um workflow pode ultrapassar os limites do processo de build e comprometer toda a cadeia de entrega de software.

Por esse motivo, estudar a segurança de pipelines deve fazer parte da rotina de engenharia, assim como revisar código, analisar dependências e avaliar configurações de infraestrutura.

Mais importante do que simplesmente executar ferramentas de análise é compreender por que determinada configuração representa um risco, em quais condições ela pode ser explorada e quais mecanismos realmente mitigam esse risco.

1. Por que estudar pipelines é tão importante?

Um pipeline inseguro pode transformar uma alteração aparentemente simples em um vetor de comprometimento.

Considere alguns exemplos:

Um Pull Request pode introduzir código executado em um runner que possui acesso a credenciais.
Uma interpolação insegura de contextos do GitHub pode permitir injeção de comandos no shell.
Uma dependência comprometida pode executar código durante a instalação.
Um token com permissões excessivas pode permitir alterações não autorizadas no repositório.
Uma publicação sem mecanismos adequados de autorização pode disponibilizar uma versão não aprovada de um pacote.
Um workflow mal configurado pode executar código de terceiros com privilégios superiores aos necessários.

Esses cenários demonstram que o pipeline não é apenas uma ferramenta operacional. Ele faz parte da infraestrutura de segurança da organização.

A segurança precisa considerar todo o ciclo de execução: desde o evento que dispara o workflow até as permissões disponíveis, dependências instaladas, artefatos produzidos e operações realizadas.

2. Utilize scanners, mas não terceirize o julgamento técnico

Existem ferramentas especializadas em identificar configurações inseguras em workflows.

Algumas opções relevantes que eu utilizo no dia a dia para scans do pipeline:

zizmor: analisa workflows do GitHub Actions e identifica problemas como template injection, permissões inadequadas, uso inseguro de eventos e instalações de dependências fora de manifests.
Checkov: realiza análise estática de configurações de infraestrutura como código e também identifica problemas em configurações de CI/CD.
actionlint: valida a sintaxe, expressões, referências e possíveis problemas estruturais em workflows do GitHub Actions.
OpenSSF Scorecard: avalia práticas de segurança de projetos e repositórios, incluindo dependências, permissões, manutenção e configuração de workflows.
Trivy: além de analisar imagens e dependências, consegue avaliar configurações e arquivos de infraestrutura.

Essas ferramentas são importantes porque automatizam a identificação de padrões conhecidos de risco.

Entretanto, existe uma diferença fundamental entre encontrar uma configuração potencialmente insegura e demonstrar que ela é explorável.

Um scanner identifica padrões. O engenheiro precisa compreender o contexto.

Exemplo: template injection

Considere:

- name: Check changelog
  run: scripts/check-changelog-frozen.sh "origin/${{ github.base_ref }}"

O scanner pode identificar uma possível injeção de comandos porque o contexto é interpolado diretamente no código executado pelo shell.

O risco existe porque o GitHub Actions realiza a expansão da expressão antes de executar o script.

Entretanto, é necessário entender a origem do dado.

github.base_ref representa a branch de destino do Pull Request, enquanto github.head_ref representa a branch de origem.

Um colaborador externo normalmente controla o nome da própria branch, mas não controla livremente a branch de destino.

Portanto, embora exista um padrão vulnerável, a explorabilidade depende das permissões e das condições do workflow.

A correção recomendada é transportar o valor por uma variável de ambiente:

- name: Check changelog
  env:
    BASE_REF: ${{ github.base_ref }}
  run: scripts/check-changelog-frozen.sh "origin/$BASE_REF"

O valor passa a ser tratado como dado, em vez de ser inserido diretamente no código interpretado pelo shell.

Esse exemplo demonstra por que é necessário estudar os findings: o scanner identifica corretamente o padrão, mas a análise de impacto exige conhecimento sobre os contextos do GitHub Actions.

3. Aprenda a diferenciar vulnerabilidades reais de findings parcialmente mitigados

Nem todo alerta representa uma vulnerabilidade diretamente explorável.

Um exemplo interessante é a instalação de dependências durante o pipeline.

Considere:

env:
  CLAUDE_CODE_VERSION: "2.1.296"
  CODEX_VERSION: "0.162.1"

E posteriormente:

- name: Install CLIs
  run: |
    npm install --global \
      "@anthropic-ai/claude-code@${CLAUDE_CODE_VERSION}" \
      "@openai/codex@${CODEX_VERSION}"

Um scanner como o zizmor pode identificar o padrão adhoc-packages, pois os pacotes são instalados globalmente sem um manifesto e lockfile controlando a instalação.

Entretanto, existe uma particularidade: as versões principais já estão explicitamente fixadas.

Isso significa que o workflow não está simplesmente instalando a última versão disponível a cada execução.

Ainda existe uma fragilidade: a árvore completa de dependências não está necessariamente reproduzível, pois as dependências transitivas não são controladas por um lockfile versionado.

É importante distinguir:

Versão principal fixada: controla qual versão direta será solicitada.
Manifesto: declara as dependências do projeto.
Lockfile: registra a resolução das dependências e suas integridades.
Instalação reproduzível: utiliza a resolução registrada para reconstruir o ambiente.

A ausência de lockfile continua sendo um finding válido, mas não significa automaticamente que existe uma instalação de versão flutuante ou que um pacote esteja comprometido.

O objetivo da análise não é eliminar alertas indiscriminadamente, mas determinar quais riscos permanecem e quais controles já existem.

4. Estude como projetos maduros resolvem problemas de segurança

Uma das formas mais eficientes de evoluir na segurança de pipelines é estudar workflows de projetos open source bem mantidos.

Em vez de começar sempre do zero, investigue como projetos com grande exposição pública estruturam seus processos de CI/CD.

Alguns exemplos interessantes para estudo:

Kubernetes: organização de workflows, testes, automação e governança de contribuições.
Terraform: validação, testes, releases e publicação de artefatos.
Trivy: análise de segurança, integração de scanners e automação de releases.
OpenTelemetry: testes distribuídos, validação de componentes e publicação de versões.
actions/checkout: implementação e manutenção de GitHub Actions.
Sigstore: assinatura, verificação e estabelecimento de confiança em artefatos.

Ao estudar esses projetos, não observe apenas quais actions são utilizadas. Investigue as decisões arquiteturais.

Pergunte:

Como o workflow é disparado?
Ele aceita Pull Requests de forks?
Quais permissões são concedidas ao GITHUB_TOKEN?
Existem secrets disponíveis durante a execução?
Como as dependências são instaladas?
As GitHub Actions são referenciadas por tags ou hashes SHA completos?
Como os artefatos são assinados e verificados?
Como as publicações são autorizadas?
Existem ambientes protegidos e aprovações humanas?
Como o projeto separa testes, validação e publicação?

O objetivo é compreender o motivo de cada decisão, e não simplesmente copiar configurações.

Uma configuração segura em determinado contexto pode ser inadequada em outro.

5. Construa uma rotina de auditoria de pipelines

A análise não deve acontecer somente quando um scanner encontra um problema.

Uma rotina de auditoria pode ser incorporada ao próprio processo de engenharia.

Uma abordagem prática:

Etapa 1 — Inventário

Mapear todos os workflows existentes:

CI.
CD.
Release.
Publicação de pacotes.
Provisionamento de infraestrutura.
Automação de dependências.
Segurança e compliance.

Etapa 2 — Análise automatizada

Executar ferramentas como:

zizmor .github/workflows

actionlint

checkov -d .github/workflows

scorecard --repo=github.com/ORG/REPOSITORY

Os comandos devem ser ajustados à versão e à forma de instalação de cada ferramenta.

Etapa 3 — Investigação dos findings

Para cada alerta:

Identificar o trecho responsável.
Entender a regra acionada.
Identificar a origem dos dados.
Verificar se existe controle compensatório.
Avaliar a possibilidade de exploração.
Determinar o impacto potencial.
Definir a correção ou justificar uma exceção.

Etapa 4 — Correção

Priorizar problemas que permitam execução de código não confiável, exposição de credenciais, elevação de privilégios e comprometimento de releases.

Etapa 5 — Prevenção

Incorporar os scanners ao próprio CI para impedir que configurações inseguras sejam introduzidas novamente.

6. Crie um laboratório utilizando projetos reais

Uma estratégia especialmente interessante é escolher projetos open source e realizar auditorias independentes em seus workflows.

Não é necessário encontrar uma vulnerabilidade para que o estudo seja útil.

O exercício consiste em:

Selecionar um repositório ativo e bem mantido.
Baixar ou clonar seus workflows.
Executar os scanners.
Investigar os findings.
Consultar a documentação das regras acionadas.
Comparar a implementação com as recomendações oficiais.
Identificar controles compensatórios.
Propor correções.
Registrar os resultados em um pequeno relatório técnico.

É possível inclusive comparar diferentes projetos para entender como cada equipe resolve o mesmo problema.

Por exemplo: como diferentes projetos implementam Trusted Publishing, como controlam dependências de terceiros ou como protegem workflows executados por Pull Requests externos.

Esse exercício desenvolve uma habilidade importante: sair da posição de alguém que apenas corrige alertas e passar a compreender a arquitetura de segurança do processo de entrega.

Segurança de CI/CD exige conhecimento sobre GitHub Actions, shell, permissões, autenticação, dependências, infraestrutura e supply chain security.

É justamente por isso que estudar workflows de projetos maduros é tão valioso: eles oferecem exemplos concretos de decisões de engenharia, problemas reais e estratégias de mitigação que podem ser adaptadas a outros ambientes.

Conclusão

Scanners são instrumentos de diagnóstico, não substitutos do conhecimento técnico.

Executar um scanner e aplicar todas as correções sugeridas sem entender os findings pode gerar configurações desnecessárias, exceções mal justificadas e até novos problemas.

O caminho mais consistente é combinar análise automatizada, estudo da documentação, investigação técnica e comparação com implementações de projetos reconhecidos.

Estudar pipelines de bons projetos é uma forma de aprender com decisões de engenharia que já foram colocadas à prova.

Afinal, um pipeline seguro não é aquele que simplesmente passa em todas as verificações. É aquele cuja arquitetura foi compreendida, cujos riscos são conhecidos e cujos mecanismos de proteção foram implementados de maneira consciente.

Coder Legion - Recent posts tagged pipeline