---
title: "DevSecOps na prática: segurança no CI/CD sem travar o time"
description: "Como integrar SAST, SCA, secrets, IaC, containers e DAST ao pipeline de CI/CD com políticas de bloqueio sensatas, feedback rápido e métricas que mostram…"
url: "https://security.transitax.com/blog/devsecops-pipeline-ci-cd"
---

DevSecOps

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

Como integrar SAST, SCA, secrets, IaC, containers e DAST ao pipeline de CI/CD com políticas de bloqueio sensatas, feedback rápido e métricas que mostram progresso.

[Equipe de Pesquisa TransiTax Security](https://security.transitax.com/sobre#pesquisa)Publicado em 6 de maio de 2026Atualizado em 27 de maio de 20264 min de leitura

Resumo

-   Segurança no pipeline funciona quando é rápida, incremental e bloqueia pouco.
-   Cada verificação tem o seu lugar: secrets no commit, SAST e SCA no pull request, containers e IaC no build, DAST e pentest depois do deploy.
-   Bloqueie só o que é crítico, alcançável e tem correção; informe o resto.
-   Meça tempo de correção, taxa de descarte e cobertura, não quantidade de alertas.

Neste artigo

1.  [Os três princípios](#os-tres-principios)
2.  [O mapa da esteira](#o-mapa-da-esteira)
3.  [Exemplo com GitHub Actions](#exemplo-com-github-actions)
4.  [Políticas de bloqueio que funcionam](#politicas-de-bloqueio-que-funcionam)
5.  [Feedback onde o desenvolvedor está](#feedback-onde-o-desenvolvedor-esta)
6.  [Lidando com o backlog](#lidando-com-o-backlog)
7.  [Métricas que importam](#metricas-que-importam)
8.  [DevSecOps e conformidade](#devsecops-e-conformidade)

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](#os-tres-principios)

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](#o-mapa-da-esteira)

| Fase | Verificação | Tempo alvo | Bloqueia? |
| --- | --- | --- | --- |
| Máquina do dev | Secrets (pre commit), proteção contra pacotes maliciosos | < 2 s | Sim, localmente |
| Pull request | SAST incremental, SCA, secrets, IaC, revisão com IA | < 60 s | Só crítico alcançável |
| Build | Imagem de container, SBOM, assinatura | < 90 s | Crítico com correção disponível |
| Pós deploy em homologação | DAST autenticado, pentest das rotas alteradas | minutos a horas | Não, gera achados com SLA |
| Produção | Proteção em runtime, CSPM, superfície de ataque | contínuo | Bloqueia ataques, não deploys |

## [Exemplo com GitHub Actions](#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:

```yaml
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](https://security.transitax.com/blog/ataques-cadeia-de-suprimentos-npm), e identidade federada no lugar de chaves de nuvem em secrets do repositório.

## [Políticas de bloqueio que funcionam](#politicas-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á](#feedback-onde-o-desenvolvedor-esta)

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](https://security.transitax.com/funcionalidades/revisao-de-pull-request) 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](https://security.transitax.com/funcionalidades/autofix) abre o PR com o patch e roda os testes; o desenvolvedor só revisa.

## [Lidando com o backlog](#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](https://security.transitax.com/blog/sca-alcancabilidade) 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](#metricas-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](#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](https://security.transitax.com/conformidade/iso-27001), o CC8.1 do [SOC 2](https://security.transitax.com/conformidade/soc-2) e o requisito 6 do [PCI DSS](https://security.transitax.com/conformidade/pci-dss).

Quer ver isso rodando no seu código?

Em 30 minutos mostramos a TransiTax Security num repositório seu, separando o que é explorável do que é ruído.

[Falar com um especialista](https://security.transitax.com/contato)

Escrito por

Equipe de Pesquisa TransiTax Security

Engenheiros de segurança de aplicações e de nuvem que acompanham registros de pacotes, bases de vulnerabilidades e técnicas de ataque. [Conheça a equipe](https://security.transitax.com/sobre#pesquisa).

Neste artigo

1.  [Os três princípios](#os-tres-principios)
2.  [O mapa da esteira](#o-mapa-da-esteira)
3.  [Exemplo com GitHub Actions](#exemplo-com-github-actions)
4.  [Políticas de bloqueio que funcionam](#politicas-de-bloqueio-que-funcionam)
5.  [Feedback onde o desenvolvedor está](#feedback-onde-o-desenvolvedor-esta)
6.  [Lidando com o backlog](#lidando-com-o-backlog)
7.  [Métricas que importam](#metricas-que-importam)
8.  [DevSecOps e conformidade](#devsecops-e-conformidade)
9.  [Perguntas frequentes](#perguntas-frequentes)

## Perguntas frequentes

Respostas diretas às dúvidas mais comuns sobre o tema.

### O que é DevSecOps?

É a prática de integrar segurança ao fluxo de desenvolvimento e entrega de software, com automação e responsabilidade compartilhada entre desenvolvimento, operações e segurança, em vez de uma etapa separada no fim.

### Segurança no pipeline deixa o build mais lento?

Pode deixar, se mal configurada. Com análises incrementais, execução em paralelo e cada verificação na fase certa, o tempo adicionado costuma ficar abaixo de um minuto no pull request.

### Devo bloquear o merge por vulnerabilidades?

Apenas para achados novos, críticos, confirmados e com correção disponível, além de secrets válidos e pacotes maliciosos. Bloquear tudo incentiva exceções em massa e desgasta a relação com o time.

### Onde colocar o DAST no CI/CD?

Depois do deploy em homologação, testando a aplicação em execução. Ele não deve bloquear o pull request, mas gerar achados com prazo de correção.

### Quais métricas mostram que o DevSecOps está funcionando?

Tempo médio de correção por severidade, taxa de falsos positivos, cobertura de ativos analisados e quantidade de achados críticos abertos além do prazo.

## Continue lendo

-   [O que é SAST: guia completo de análise estática de código16 de setembro de 2026Fundamentos](https://security.transitax.com/blog/o-que-e-sast)
-   [SAST, DAST, IAST e SCA: diferenças e quando usar cada um2 de setembro de 2026Fundamentos](https://security.transitax.com/blog/sast-dast-iast-sca-diferencas)
-   [OWASP Top 10 2025: o que mudou e como se proteger de cada risco26 de agosto de 2026Vulnerabilidades](https://security.transitax.com/blog/owasp-top-10-2025)

## Veja o que é explorável no seu código

Em 30 minutos mostramos a plataforma num repositório seu, separamos o risco real do ruído e montamos uma proposta em reais.

[Falar com um especialista](https://security.transitax.com/contato)

Resposta em até 1 dia útil.