O Que é DevSecOps: Definição, Práticas e um Pipeline Real

DevSecOps significa que a segurança faz parte do pipeline, e não é um portão no final dele. O mesmo sistema de CI/CD que builda, testa e faz deploy do seu código também o escaneia em busca de vulnerabilidades, segredos vazados, dependências vulneráveis e configurações de infraestrutura arriscadas, a cada mudança. E quem escreve o código é responsável por corrigir o que o pipeline encontra.

Essa é a resposta curta para DevSecOps o que é. No resto do guia vemos como ele difere de DevOps, o que "shift-left" significa de verdade, as cinco práticas que formam um pipeline DevSecOps, um exemplo de GitHub Actions para adaptar e um jeito realista de começar em um time pequeno.

DevOps vs DevSecOps

DevOps derrubou o muro entre desenvolvimento e operações: mudanças pequenas, testes automatizados, entrega contínua, responsabilidade compartilhada sobre produção. Os times passaram a entregar muito mais rápido. O problema é que a segurança muitas vezes ficou no modelo antigo: um time separado, uma revisão ou pentest antes de um release grande, um PDF de achados semanas depois de o código ser escrito.

Quando você faz deploy várias vezes por dia, esse modelo não se sustenta. Ou a segurança vira gargalo, ou (o mais comum) é pulada. DevSecOps resolve isso aplicando o mesmo playbook do DevOps à própria segurança.

Shift-left: por que mais cedo é mais barato

"Shift-left" é mover as verificações de segurança para a esquerda da linha do tempo: para o editor, o pull request e o build de CI, em vez de auditorias pré-release ou incidentes em produção. O motivo é prático. Quando um scanner comenta em um pull request que você abriu há dez minutos, você ainda tem o contexto e a correção costuma ser uma linha. Quando o mesmo bug aparece seis meses depois em um relatório de pentest, alguém precisa redescobrir o código, a correção pode afetar outras features e ele ficou explorável esse tempo todo.

Shift-left não significa "só à esquerda". Você continua precisando de verificações contra a aplicação rodando e de testes humanos de vez em quando. Significa que as verificações baratas e automatizáveis acontecem o mais cedo possível.

As práticas principais do DevSecOps

1. SAST (Static Application Security Testing)

Analisa o código-fonte sem executá-lo, procurando padrões como SQL injection, desserialização insegura, verificações de autorização ausentes ou criptografia fraca. É rápido e aponta arquivo e linha exatos, o que o torna ideal para pull requests. O SAST tradicional baseado em regras é conhecido pelos falsos positivos; abordagens mais novas de SAST com IA tentam avaliar se um achado é realmente alcançável e explorável.

2. SCA (Software Composition Analysis)

A maior parte do código que você publica é open source que você não escreveu. O SCA lê seus lockfiles (package-lock.json, poetry.lock, Gemfile.lock, go.sum) e compara cada versão com bases de CVEs conhecidos. Isso ataca diretamente Software Supply Chain Failures, agora #3 no OWASP Top 10 2025.

3. Secret scanning

API keys, senhas de banco de dados e credenciais de cloud commitadas no git estão entre os caminhos mais rápidos para um vazamento. Um secret scanner precisa olhar todo o histórico do git, não só os arquivos atuais: apagar uma chave em um commit posterior não a remove do repositório. Se um segredo vazou, rotacione; o scan só avisa que aconteceu.

4. Scan de IaC

Infrastructure as Code (Terraform, manifestos de Kubernetes, Dockerfiles, workflows de CI) é código e pode ser mal configurado: buckets públicos, containers rodando como root, security groups abertos para 0.0.0.0/0, workflows com permissões de escrita que não precisam. Scanners de IaC pegam isso antes de ser aplicado.

5. DAST (Dynamic Application Security Testing)

Testa a aplicação rodando, de fora, como um atacante faria: headers de segurança ausentes, páginas de erro expostas, pontos de injeção, fraquezas de autenticação. Complementa o SAST, não o substitui; em SAST e DAST explicamos as diferenças. Para falhas de lógica de negócio que nenhum scanner encontra, você ainda precisa de pentest, manual ou assistido por IA.

Um pipeline DevSecOps prático com GitHub Actions

Aqui está um pipeline mínimo com ferramentas open source conhecidas. Ele roda verificações de segredos, SAST, dependências e IaC em todo pull request e em todo push para a main. Adapte as ferramentas ao seu stack; o que importa é a estrutura.

# .github/workflows/security.yml
name: security
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # histórico completo, para escanear commits antigos
      - name: Segredos no histórico do git (Gitleaks)
        run: |
          docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/repo" \
            zricethezav/gitleaks:latest detect --source /repo -v

  sast:
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - name: SAST (Semgrep, regras OWASP Top 10)
        run: semgrep scan --config p/owasp-top-ten --error

  dependencies-and-iac:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Dependências com CVEs conhecidos (Trivy)
        run: |
          docker run --rm -v "$PWD:/src" aquasec/trivy \
            fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 /src
      - name: Configurações incorretas de IaC (Trivy)
        run: |
          docker run --rm -v "$PWD:/src" aquasec/trivy \
            config --severity HIGH,CRITICAL --exit-code 1 /src

E um job de DAST que roda depois do deploy em staging, já que precisa de uma URL no ar:

  dast:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: DAST baseline (OWASP ZAP)
        run: |
          docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
            zap-baseline.py -t https://staging.example.com

Alguns detalhes que importam mais do que a ferramenta escolhida:

• permissions: contents: read no topo. Os workflows recebem um token; dê a ele o menor privilégio necessário.
• Fixe actions e imagens de terceiros em um commit SHA ou digest nos pipelines de produção. Tags como @main ou :latest podem mudar sem aviso, e isso já é um risco de supply chain.
• No começo, falhe só com HIGH e CRITICAL. Um pipeline que falha a cada nota de baixa severidade acaba desativado em uma semana.
• Ative branch protection para que os jobs de segurança sejam checks obrigatórios antes do merge.

Categorias de ferramentas DevSecOps

Juntar cinco ou seis ferramentas funciona, mas cada uma tem sua configuração, seu formato de saída e seus falsos positivos. Por isso muitos times preferem um único scanner de segurança para GitHub que cubra várias categorias em um só relatório. O Nurbak, por exemplo, se conecta ao GitHub e escaneia um repositório com seu próprio modelo de IA self-hosted (seu código não é enviado para a OpenAI nem para a Anthropic na análise): vulnerabilidades exploráveis com arquivo e linha, dependências comparadas com CVEs conhecidos, configurações incorretas de GitHub Actions, Docker, Terraform e Kubernetes, e segredos no histórico do git, tudo resumido em um score de segurança de 0 a 100 com explicações em linguagem simples.

Como começar com DevSecOps em um time pequeno

Você não precisa de um time de segurança para fazer DevSecOps. Precisa de algumas verificações automáticas, de uma regra sobre o que bloqueia um merge e do hábito de corrigir achados como qualquer outro bug. Uma ordem realista:

1. Semana 1: segredos. Ative secret scanning com push protection e escaneie todo o histórico uma vez. Rotacione o que for real. Impacto máximo, quase zero falsos positivos.
2. Semana 1: dependências. Ative PRs automáticos de atualização e alertas de CVEs. Faça merge dos críticos primeiro.
3. Semana 2: SAST nos pull requests, em modo não bloqueante. Leia os resultados por duas semanas, remova as regras ruidosas e depois torne HIGH/CRITICAL bloqueantes.
4. Semana 3: IaC. Se você tem Terraform, Kubernetes, Dockerfiles ou workflows não triviais, adicione scan de IaC ao mesmo pipeline.
5. Semana 4: DAST baseline contra staging depois de cada deploy.
6. Sempre: uma regra de triagem. Por exemplo: críticos corrigidos em 7 dias, altos em 30, o resto revisado todo mês. Acompanhe o backlog como qualquer outra dívida técnica.
7. Periodicamente: um pentest humano (ou assistido por IA) nos fluxos que mais importam: autenticação, pagamentos, acesso a dados multi-tenant.

A falha mais comum não é escolher a ferramenta errada, é o ruído. Se os devs aprendem que o job de segurança quase sempre erra, param de ler. Prefira menos achados e mais confiáveis, e que cada um seja acionável: onde está, por que importa e como corrigir.

Esse último passo, corrigir, é onde os times travam. Algumas ferramentas já fecham o ciclo: quando o Nurbak confirma um achado, ele pode abrir um pull request com a correção e um teste de regressão de segurança (a correção é gerada com o Claude, só com o seu consentimento explícito), assim a remediação passa pelo seu review normal. Se você quer uma visão rápida antes de montar o pipeline inteiro, o scan gratuito do seu repositório no GitHub mostra completos os 3 achados mais importantes.

Resumo

• DevSecOps é DevOps com a segurança automatizada dentro do pipeline e sob responsabilidade do time inteiro.
• Shift-left: pegar problemas no pull request, quando corrigir é mais barato.
• As cinco práticas principais são SAST, SCA, secret scanning, scan de IaC e DAST, mais pentest periódico para falhas de lógica.
• Comece pequeno: segredos e dependências primeiro, SAST não bloqueante, depois aperte.
• Ruído mata programas de DevSecOps. Busque achados em que os devs confiem e consigam corrigir.