DevSecOps: segurança shift-left no pipeline de CI/CD

Por muito tempo, segurança foi a última etapa antes do deploy: um pentest agendado, um relatório com dezenas de achados e uma corrida para corrigir tudo antes de subir. O problema é estrutural — quanto mais tarde uma vulnerabilidade é encontrada, mais caro e arriscado é corrigi-la, porque o código já foi escrito, revisado e integrado a outros componentes. O movimento DevSecOps propõe inverter isso: trazer a verificação de segurança para o começo do ciclo, junto com o código. É o que chamamos de shift-left.

O que significa shift-left

Imagine o ciclo de desenvolvimento numa linha da esquerda (código) para a direita (produção). "Shift-left" é deslocar as atividades de segurança para a esquerda — para o momento em que o desenvolvedor abre o editor, faz o commit e abre o pull request. Em vez de depender de uma auditoria pontual no fim, você integra checagens automatizadas ao pipeline de CI/CD, de forma que cada mudança seja avaliada continuamente.

Isso não elimina o pentest nem o trabalho de um time de segurança. O que muda é a distribuição do esforço: a maioria dos problemas triviais e repetitivos (dependência vulnerável, segredo commitado, configuração de infra insegura) passa a ser detectada por automação, deixando o time humano livre para análise de ameaças mais sofisticadas.

Os tipos de scan que importam

Não existe um único scanner que cubra tudo. Cada técnica enxerga uma camada diferente do problema, e um pipeline maduro combina vários.

SAST (Static Application Security Testing) analisa o código-fonte sem executá-lo, procurando padrões inseguros: SQL injection, uso de funções perigosas, fluxo de dados não sanitizado. Roda cedo, no commit ou no PR. Ferramentas comuns incluem Semgrep, SonarQube e CodeQL. A contrapartida do SAST é a taxa de falsos positivos, que exige curadoria das regras.

DAST (Dynamic Application Security Testing) faz o oposto: testa a aplicação rodando, atacando endpoints como faria um agente externo. Encontra problemas que só aparecem em runtime, como falhas de autenticação ou cabeçalhos mal configurados. O OWASP ZAP é a referência aberta aqui. Por exigir um ambiente de aplicação no ar, normalmente roda em estágios posteriores do pipeline.

SCA (Software Composition Analysis) examina suas dependências de terceiros em busca de CVEs conhecidos. Como a maior parte do código de uma aplicação moderna vem de bibliotecas open source, esse é um dos scans de maior retorno. Trivy, Snyk e o OWASP Dependency-Check são opções amplamente usadas; o GitHub Dependabot também cobre esse caso.

Secret scanning procura credenciais, tokens e chaves que vazaram para o repositório. O gitleaks e o TruffleHog varrem tanto o working tree quanto o histórico do git. Vale rodar como hook de pre-commit e também no CI, porque um segredo no histórico continua exposto mesmo depois de removido do HEAD.

IaC scanning verifica infraestrutura como código (Terraform, CloudFormation, Kubernetes manifests, Dockerfiles) contra configurações inseguras: bucket público, security group aberto, container rodando como root. Trivy (que também faz isso), Checkov e tfsec são ferramentas correntes.

Container image scanning inspeciona a imagem final em busca de pacotes vulneráveis no sistema operacional base e nas camadas. Novamente o Trivy aparece, junto com Grype. O ponto-chave é escanear a imagem que realmente vai para produção, não só o código.

Um pipeline de exemplo

Veja como esses scans se encaixam num workflow de GitHub Actions, rodando em paralelo onde possível:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Secret scanning
      - name: gitleaks
        uses: gitleaks/gitleaks-action@v2

      # SCA + IaC + imagem, tudo com Trivy
      - name: Trivy filesystem (deps + IaC)
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: HIGH,CRITICAL
          exit-code: '1'

      # SAST
      - name: Semgrep
        uses: semgrep/semgrep

Dois detalhes valem atenção aqui. Primeiro, o exit-code: '1' combinado com severity: HIGH,CRITICAL: o build quebra apenas em achados de alta severidade. Começar bloqueando tudo gera fadiga e faz o time desabilitar o scan. A recomendação prática é introduzir os scanners em modo não-bloqueante, calibrar o ruído e só então transformar achados graves em gate obrigatório.

Segundo, fixe as versões das actions e confira a licença antes de adotar. O gitleaks-action, por exemplo, exige uma licença (GITLEAKS_LICENSE) para varrer repositórios pertencentes a uma organização — a CLI gitleaks em si é livre, mas o wrapper de Action tem essa exigência. E actions que avançam de versão major (foi o caso do próprio gitleaks-action) podem trazer breaking changes, então prefira pinar tags ou commits em vez de depender de master/latest.

Supply chain: SBOM e SLSA

Escanear o que você escreve não basta se você não sabe exatamente o que está entregando. Os ataques de cadeia de suprimentos — comprometimento de uma dependência, de um build server ou de um artefato em trânsito — tornaram a procedência do software uma preocupação central.

O SBOM (Software Bill of Materials) é o inventário completo de tudo que compõe um artefato: bibliotecas, versões e licenças. Os formatos padronizados são o CycloneDX (mantido pela OWASP) e o SPDX (originado na Linux Foundation). Gerar um SBOM a cada build permite responder rapidamente "estou usando a versão afetada?" quando um novo CVE aparece — como ficou evidente no episódio do Log4Shell. Ferramentas como Syft e o próprio Trivy geram SBOM:

trivy image --format cyclonedx --output sbom.json minha-app:1.0

O SLSA (Supply-chain Levels for Software Artifacts), proposto originalmente pelo Google e hoje mantido sob a OpenSSF, é um framework de níveis crescentes de garantia sobre a integridade do build. Em vez de uma checklist única, ele define requisitos progressivos e cumulativos — por exemplo, builds em ambiente isolado e geração de proveniência assinada que comprova de onde o artefato veio e como foi produzido. Assinar artefatos e proveniência com Sigstore/cosign é uma forma concreta de avançar nesses níveis.

Por onde começar

DevSecOps não se implanta de uma vez. Um caminho razoável é: ative secret scanning e SCA primeiro — são os de maior retorno e menor ruído. Em seguida, adicione SAST e IaC scanning em modo de alerta, calibre as regras e promova os achados críticos a gate. Por fim, incorpore geração de SBOM e assinatura de artefatos ao build. Os relatórios anuais sobre o estado do DevOps vêm tratando segurança automatizada no pipeline como prática cada vez mais comum entre times de alta performance — não como uma etapa separada, mas como parte natural do fluxo de entrega.

O objetivo final do shift-left não é acumular dashboards de vulnerabilidades, e sim tornar a decisão segura a opção mais fácil para quem escreve o código.