Pipeline seguro — SAST, DAST, SCA no CI/CD e gates de qualidade

Um pipeline seguro não é um pipeline com mais etapas — é um pipeline onde cada etapa tem critérios claros de aprovação e falha. SAST, DAST e SCA são as três ferramentas centrais que transformam um CI/CD comum em uma barreira de segurança automatizada.

SAST — Análise Estática de Segurança

Analisa o código-fonte sem executá-lo. Detecta padrões inseguros como injeção SQL, XSS, uso de funções perigosas.

# GitHub Actions — Semgrep SAST
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: "p/owasp-top-ten"
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_TOKEN }}

Ferramentas populares: Semgrep, SonarQube, Checkmarx, CodeQL (GitHub nativo).

SCA — Análise de Composição de Software

Verifica dependências de terceiros em busca de CVEs conhecidos.

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy SCA
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: "fs"
          scan-ref: "."
          severity: "HIGH,CRITICAL"
          exit-code: "1"   # falha o pipeline se encontrar HIGH/CRITICAL

Exemplo de saída SCA:
  lodash@4.17.15  CVE-2021-23337  CRITICAL  Prototype Pollution
  log4j@2.14.0    CVE-2021-44228  CRITICAL  RCE (Log4Shell)
  → pipeline bloqueado até atualização das dependências

DAST — Análise Dinâmica de Segurança

Testa a aplicação em execução, simulando ataques reais. Executa em ambiente de staging, nunca em produção.

  dast:
    runs-on: ubuntu-latest
    needs: [deploy-staging]
    steps:
      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.10.0
        with:
          target: "https://staging.example.com"
          rules_file_name: ".zap/rules.tsv"
          fail_action: true

O que o DAST encontra que o SAST não encontra:
  - Falhas de configuração do servidor (headers ausentes)
  - Lógica de autenticação bypassável em runtime
  - Exposição de endpoints não documentados
  - Problemas de CORS e CSP mal configurados

Gates de qualidade (Quality Gates)

Gates são critérios automáticos que bloqueiam o avanço do pipeline:

Exemplo de política de gate:
  SAST   → nenhuma vulnerabilidade CRITICAL ou HIGH
  SCA    → nenhum CVE CRITICAL; HIGH aceito com exceção documentada
  DAST   → nenhum alerta de risco ALTO na baseline
  Secrets → zero segredos detectados no diff
  Coverage → cobertura de testes ≥ 80%

Se qualquer gate falhar → merge bloqueado, PR anotado com os achados.

Ordem recomendada no pipeline

push → pre-commit hooks (local)
     → secrets scan (rápido, < 30s)
     → SAST (paralelo com testes unitários)
     → SCA (paralelo com build)
     → build da imagem
     → scan da imagem (Trivy)
     → deploy em staging
     → DAST
     → aprovação manual (opcional, para prod)
     → deploy em produção

Exceções e falsos positivos

Ferramentas de análise produzem falsos positivos. O processo de exceção deve ser rastreável:

1. Desenvolvedor abre issue documentando o falso positivo
2. Security team revisa e aprova
3. Regra adicionada ao arquivo de supressão (versionado no repo)
4. Exceção revisada a cada 90 dias

# .semgrepignore ou equivalente — nunca suprimir sem justificativa

Resumo

SAST encontra problemas no código. SCA expõe dependências vulneráveis. DAST valida o comportamento real da aplicação. Os três juntos, com gates claros, formam uma malha de segurança automatizada que não depende de revisão manual para funcionar.