DevSecOps na prática: segurança no CI/CD sem travar o time

DevSecOps virou palavra de efeito, mas a ideia é simples: tratar segurança como parte do fluxo de entrega, com o mesmo rigor de automação que testes e deploy já têm. Na prática, muitas empresas instalam cinco scanners no pipeline, o build passa de 8 para 25 minutos, tudo quebra por alertas que ninguém entende, e o time aprende a pular as verificações.

Este guia mostra como montar a esteira de um jeito que o time de engenharia aceite, e até prefira.

Os três princípios

1. Rápido. Se a verificação de segurança for a etapa mais lenta do pull request, ela vai ser odiada. Análises incrementais, só dos arquivos alterados, rodando em paralelo aos testes.
2. No lugar certo. Cada técnica tem a fase em que é mais barata e mais útil. Rodar tudo em todo lugar só gera duplicação.
3. Bloqueia pouco, informa muito. O build falha só para o que é crítico, confirmado e corrigível. O resto é comentário, tarefa ou item de painel.

O mapa da esteira

Exemplo com GitHub Actions

Um pipeline enxuto combina a integração nativa da plataforma com o provedor Git (que comenta direto no PR) e uma etapa no CI para o que depende do build:

name: ci
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write        # identidade federada, sem chave estática de nuvem

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci --ignore-scripts
      - run: npm test
      - run: docker build -t app:${{ github.sha }} .
      - name: Analisar imagem e gerar SBOM
        run: transitax container scan app:${{ github.sha }} --sbom cyclonedx --fail-on critical --only-fixable

Repare em três detalhes: permissions mínimas no workflow, --ignore-scripts para reduzir o risco de pacotes maliciosos, e identidade federada no lugar de chaves de nuvem em secrets do repositório.

Políticas de bloqueio que funcionam

A pior política é "falhar em qualquer vulnerabilidade alta ou crítica". Ela bloqueia por CVEs em código não alcançável, por falhas sem correção disponível e por problemas antigos que o desenvolvedor do PR não introduziu. Uma política sensata:

• Bloqueia apenas achados novos (introduzidos pelo PR), críticos, alcançáveis e com correção disponível.
• Bloqueia sempre secrets válidos e pacotes maliciosos, sem exceção.
• Comenta achados altos e médios, com sugestão de correção.
• Registra o resto no painel, com SLA por severidade para o dono do repositório.
• Permite exceção com justificativa e prazo, aprovada por outra pessoa e registrada para auditoria.

Feedback onde o desenvolvedor está

O melhor alerta é o que aparece no contexto certo:

• No pull request: comentário na linha, com a explicação do risco e o diff da correção. A revisão de pull request com IA adiciona o que regras não pegam, como rotas sem verificação de permissão.
• Na IDE: a mesma regra do pipeline rodando localmente, antes do commit.
• No chat: só o que exige ação imediata, como um secret válido exposto. Canal de segurança com cem mensagens por dia vira ruído.

E, sempre que possível, entregue a correção pronta. O AutoFix abre o PR com o patch e roda os testes; o desenvolvedor só revisa.

Lidando com o backlog

Ativar um SCA num repositório antigo revela centenas de achados de uma vez. Não bloqueie o time por eles. Trate o histórico como projeto separado:

1. Filtre por alcançabilidade e exposição.
2. Agrupe atualizações de dependência em PRs por serviço.
3. Defina uma meta trimestral de redução, e não um prazo impossível.

Métricas que importam

Quantidade de alertas não é métrica de sucesso. Acompanhe:

• Tempo médio de correção por severidade (MTTR). É o indicador mais honesto de maturidade.
• Taxa de descarte: percentual de achados marcados como falso positivo. Acima de 30%, a configuração precisa de ajuste.
• Cobertura: percentual de repositórios, imagens, contas de nuvem e aplicações sob análise.
• Achados críticos abertos acima do SLA.
• Tempo de pipeline adicionado pelas verificações de segurança.

DevSecOps e conformidade

Uma esteira bem montada gera evidência como efeito colateral: cada PR analisado, cada exceção aprovada e cada correção feita viram registro para o controle 8.25 da ISO 27001, o CC8.1 do SOC 2 e o requisito 6 do PCI DSS.