Segurança em pipelines de CI/CD: protegendo segredos e artefatos

1. Fundamentos da segurança em pipelines de CI/CD

1.1. O que são pipelines de CI/CD e por que eles são um alvo crítico

Pipelines de CI/CD (Integração Contínua e Entrega Contínua) são o coração da automação moderna de software. Eles compilam, testam, empacotam e implantam código automaticamente. Por concentrarem acesso a repositórios, credenciais de produção e artefatos finais, tornam-se alvos prioritários para atacantes. Um pipeline comprometido pode resultar em vazamento de dados sensíveis, injeção de backdoors em artefatos ou implantação de código malicioso em produção.

1.2. Principais ameaças

  • Vazamento de credenciais: chaves de API, senhas e tokens expostos em logs, variáveis de ambiente ou código-fonte.
  • Injeção de código malicioso: dependências comprometidas, scripts maliciosos em arquivos YAML ou adulteração de imagens de contêiner.
  • Adulteração de artefatos: binários ou pacotes modificados durante o armazenamento ou transporte.

1.3. Modelo de confiança zero aplicado a pipelines

O princípio "nunca confie, sempre verifique" deve ser aplicado em cada etapa: autenticação de cada job, verificação de integridade de artefatos, validação de fontes de dependências e isolamento de runners.

2. Gerenciamento seguro de segredos no pipeline

2.1. Uso de cofres de segredos

Nunca armazene segredos diretamente no código ou em variáveis de ambiente do pipeline. Utilize serviços dedicados:

  • AWS Secrets Manager: rotação automática de credenciais.
  • HashiCorp Vault: política de acesso dinâmico e segredos efêmeros.
  • Azure Key Vault: integração nativa com Azure DevOps.

Exemplo de integração com HashiCorp Vault em um job:

jobs:
  deploy:
    steps:
      - name: Obter segredo do Vault
        run: |
          curl -H "X-Vault-Token: $VAULT_TOKEN" \
            https://vault.exemplo.com/v1/secret/data/credenciais-api | \
            jq -r '.data.data' > .env
      - name: Usar segredo no deploy
        run: ./deploy.sh --env-file .env

2.2. Integração em tempo de execução

Segredos devem ser injetados apenas no momento da execução, nunca expostos em logs ou artefatos intermediários. Utilize variáveis de ambiente criptografadas oferecidas pela plataforma (GitHub Actions Secrets, GitLab CI/CD Variables).

2.3. Práticas para evitar hardcoding

Scanners automáticos devem ser executados em cada commit:

  • git-secrets: impede commits com padrões de credenciais.
  • truffleHog: detecta segredos em históricos de repositórios.
  • Políticas de commit: hooks que rejeitam push contendo tokens ou senhas.

Exemplo de configuração de hook pré-commit:

#!/bin/bash
# .git/hooks/pre-commit
git diff --cached --name-only | while read file; do
  if grep -qE "(password|secret|api_key|token)" "$file"; then
    echo "ERRO: Possível segredo encontrado em $file"
    exit 1
  fi
done

3. Proteção de artefatos durante o build e armazenamento

3.1. Assinatura digital de artefatos

Utilize ferramentas como cosign (parte do Sigstore) para assinar imagens de contêiner e binários. A assinatura garante que o artefato não foi adulterado entre o build e o deploy.

Exemplo de assinatura com cosign:

cosign sign --key cosign.key registry.exemplo.com/minha-app:v1.0
cosign verify --key cosign.pub registry.exemplo.com/minha-app:v1.0

3.2. Armazenamento seguro em registries privados

Configure registries com RBAC (Role-Based Access Control) para limitar quem pode fazer push, pull ou deletar artefatos. Utilize políticas de imutabilidade para versões já publicadas.

3.3. Verificação de checksums

Antes de qualquer deploy, valide o checksum SHA-256 do artefato contra um valor conhecido e assinado:

sha256sum artifact.tar.gz > artifact.sha256
# Verificação
sha256sum -c artifact.sha256

4. Controle de acesso e autenticação no pipeline

4.1. Autenticação multifator (MFA)

Exija MFA para acesso a runners auto-hospedados, repositórios críticos e consoles de gerenciamento do pipeline.

4.2. Uso de tokens de curta duração e OIDC

Substitua tokens estáticos por autenticação OIDC. O provedor de CI/CD troca um token JWT por credenciais temporárias da nuvem:

- name: Configurar credenciais AWS via OIDC
  uses: aws-actions/configure-aws-credentials@v2
  with:
    role-to-assume: arn:aws:iam::123456789:role/CI-CD-Role
    role-session-name: pipeline-session
    aws-region: us-east-1

4.3. Princípio do menor privilégio

Cada job do pipeline deve ter permissões mínimas. No GitHub Actions, defina permissões explicitamente:

jobs:
  build:
    permissions:
      contents: read
      packages: write
    steps:
      - run: echo "Permissão apenas para ler código e escrever pacotes"

5. Auditoria e monitoramento contínuo de segurança

5.1. Logs centralizados

Todos os eventos do pipeline (início de build, falhas, acesso a segredos) devem ser enviados para um sistema centralizado de logs.

5.2. Alertas em tempo real

Configure alertas para atividades suspeitas: múltiplas tentativas de acesso a segredos, falhas de verificação de assinatura, alterações em configurações do pipeline.

5.3. Integração com SIEM

Ferramentas como Splunk ou ELK Stack podem correlacionar logs do pipeline com outros eventos de segurança para análise forense.

6. Mitigação de ataques comuns em pipelines

6.1. Proteção contra injeção de dependências

  • Dependency confusion: utilize nomes de pacotes com escopo privado e resolva sempre de registries confiáveis.
  • Typosquatting: bloqueie pacotes com nomes similares a dependências legítimas.

Configure um arquivo de bloqueio de dependências:

# .npmrc
registry=https://registry.npmjs.org/
@minha-empresa:registry=https://npm.pkg.github.com/

6.2. Prevenção de adulteração de código

Exija assinatura GPG para todos os commits em branches protegidos:

git commit -S -m "Commit assinado"
git verify-commit HEAD

6.3. Isolamento de runners

Utilize runners efêmeros conteinerizados que são destruídos após cada execução, impedindo persistência de malware entre builds:

runs-on: ubuntu-latest
container:
  image: node:18-alpine
  options: --rm

7. Boas práticas para compliance e conformidade

7.1. Políticas de retenção e destruição segura

Defina políticas claras: artefatos antigos devem ser deletados após 90 dias; logs de auditoria retidos por 1 ano; segredos rotacionados a cada 30 dias.

7.2. Documentação de trilhas de auditoria

Mantenha registros imutáveis de quem aprovou cada deploy, quais artefatos foram implantados e em qual ambiente. Esses registros são essenciais para certificações SOC 2 e ISO 27001.

7.3. Testes periódicos de penetração

Realize pentests específicos para pipelines de CI/CD, simulando ataques de injeção de dependências, escalonamento de privilégios em runners e vazamento de segredos.

Referências