DevSecOps: segurança no pipeline de CI/CD
Levar a verificação de segurança para dentro da esteira encontra falhas cedo, quando corrigir custa menos. O desafio é fazer isso sem virar ruído.
DevSecOps é a prática de integrar segurança ao ciclo de desenvolvimento e à esteira de entrega, em vez de deixá-la para uma auditoria no fim. A ideia central é simples: quanto mais cedo uma falha é encontrada, mais barato é corrigi-la. Encontrar um problema de segurança no momento em que o código é escrito custa muito menos do que descobri-lo em produção, depois de um incidente.
Este guia explica como encaixar as verificações de segurança no pipeline de CI/CD, o que cada tipo de teste faz e como evitar o erro mais comum, que é transformar a esteira em uma fonte de alertas que ninguém trata. A sopa de siglas costuma assustar, mas SAST, DAST e SCA resolvem problemas distintos e se complementam quando usados com critério.
O que muda com DevSecOps
No modelo tradicional, a segurança entra no fim, quando a aplicação já está pronta. O resultado costuma ser uma lista longa de correções caras, algumas ligadas a decisões de arquitetura difíceis de reverter. DevSecOps distribui a verificação ao longo do caminho: no editor do desenvolvedor, no commit, na build e na entrega. A segurança deixa de ser um portão único e vira uma sequência de checagens menores.
Esse deslocamento para o início do ciclo, muitas vezes chamado de mover a segurança para a esquerda, só funciona com responsabilidade compartilhada. O time de desenvolvimento passa a lidar com parte dos achados, e o time de segurança deixa de ser um gargalo para virar quem define regras, prioriza risco e apoia a correção. Sem essa mudança de cultura, as ferramentas viram enfeite na esteira.
SAST, DAST e SCA: o que cada um faz
As três siglas descrevem tipos de teste que olham a aplicação de ângulos diferentes. Nenhum substitui o outro, porque cada um encontra uma classe de problema que os demais tendem a perder.
- SAST (análise estática): examina o código-fonte sem executá-lo, procurando padrões inseguros como injeção e uso incorreto de criptografia. Roda cedo, mas gera falsos positivos que precisam de triagem.
- DAST (análise dinâmica): testa a aplicação em execução, do lado de fora, simulando requisições. Encontra problemas que só aparecem em tempo de execução, mas depende de um ambiente de teste rodando.
- SCA (análise de composição): inventaria bibliotecas e dependências e aponta componentes com vulnerabilidades conhecidas. É essencial porque boa parte do código de uma aplicação vem de terceiros.
Uma quarta categoria útil é a varredura de segredos, que procura chaves e senhas expostas no código antes que elas cheguem ao repositório. Muitos incidentes começam com uma credencial esquecida em um commit, e essa checagem simples evita um problema recorrente.
Onde encaixar cada teste no pipeline
A posição de cada verificação importa tanto quanto a ferramenta. Testes rápidos e de baixo ruído ficam bem cedo, perto do desenvolvedor, para dar retorno imediato. Testes mais lentos, como o DAST, ficam melhor em etapas posteriores, contra um ambiente de homologação, para não travar cada commit. O objetivo é dar retorno rápido sem transformar a esteira em uma espera longa.
- No editor e no commit: varredura de segredos e checagens leves
- Na build: SAST e SCA, com limites claros de severidade
- Antes ou depois do deploy em homologação: DAST contra o ambiente
- De forma contínua: reavaliação de dependências quando surgem novas falhas
Uma etapa de segurança no pipeline, na prática
O desenho abaixo ilustra como as verificações se encaixam em uma esteira, do commit à homologação. É um esboço conceitual, agnóstico de ferramenta, para mostrar a ordem e os pontos de decisão, não uma configuração pronta para copiar.
estagios:
- commit:
- varredura_de_segredos # bloqueia se achar chave exposta
- lint_e_testes
- build:
- sast # análise estática do código
- sca # dependências com falha conhecida
- politica: falhar_em: [critico, alto]
- homologacao:
- deploy_efemero
- dast # aplicação em execução
- continuo:
- reavaliar_dependencias # quando surge nova vulnerabilidadeO ponto central é a linha de política: ela define o que interrompe a entrega e o que apenas registra um aviso. Sem esse limite explícito, ou tudo passa e a verificação vira teatro, ou tudo trava e o time procura um jeito de contornar a esteira. Vale versionar essa política como código, para que mudanças no gate passem por revisão como qualquer outra alteração.
Como evitar a fadiga de alertas
O maior risco de DevSecOps não é a falta de achados, e sim o excesso. Uma esteira que gera centenas de alertas sem priorização faz o time ignorar todos, inclusive os graves. A verificação de segurança precisa de política: o que quebra a build, o que apenas avisa, quem tria os resultados e em quanto tempo. Sem essa política, a automação vira ruído.
- Definir quais severidades quebram a build e quais apenas alertam
- Priorizar por exploração real e criticidade do ativo, não por contagem
- Ajustar as regras para reduzir falsos positivos ao longo do tempo
- Ter um responsável pela triagem dos achados de segurança
- Tratar a esteira como produto que evolui, não como configuração fixa
Métricas que mostram se o programa funciona
DevSecOps sem medição vira opinião. Poucos indicadores, escolhidos com cuidado, dizem se a verificação está reduzindo risco ou apenas gerando alerta. O objetivo não é um painel bonito, e sim saber se a falha é encontrada e corrigida mais cedo ao longo do tempo.
- Tempo entre descobrir e corrigir uma vulnerabilidade, por severidade
- Proporção de builds que passam pelo gate de segurança sem exceção manual
- Quantidade de segredos barrados antes de chegar ao repositório
- Idade das vulnerabilidades ainda abertas em componentes de terceiros
- Taxa de falsos positivos e sua evolução após ajuste das regras
Cuidado com a métrica de vaidade. Contar quantos alertas a esteira gera não diz nada sobre risco, e muitas vezes quanto maior o número, pior a priorização. O que importa é a tendência: falhas encontradas mais cedo, corrigidas mais rápido e menos ruído chegando ao time.
Checklist prático
- Distribuir verificações ao longo do pipeline, não só no fim
- Rodar varredura de segredos antes do código chegar ao repositório
- Incluir SAST e SCA na build com limites de severidade
- Rodar DAST contra um ambiente de homologação
- Reavaliar dependências quando novas vulnerabilidades surgem
- Definir o que quebra a build e o que apenas alerta
- Priorizar achados por risco real, não por volume
- Designar responsável pela triagem dos resultados
- Definir a política de gate como código, versionada e revisada
- Acompanhar o tempo entre descobrir e corrigir vulnerabilidades
Boas práticas
- Mova a verificação para o início do ciclo, perto de quem escreve o código
- Combine SAST, DAST e SCA, porque cada um cobre uma lacuna
- Trate a fadiga de alertas como o principal risco a gerenciar
- Dê retorno rápido sem travar cada commit com testes lentos
- Compartilhe a responsabilidade entre desenvolvimento e segurança
- Evolua as regras da esteira com base nos falsos positivos observados
- Meça a tendência de correção, não a contagem de alertas gerados
Erros comuns
Ligar todas as ferramentas sem política de severidade
Centenas de alertas ignorados, incluindo os realmente graves.
Colocar testes lentos em cada commit
Esteira travada e desenvolvedores tentando burlar a verificação.
Confiar só em SAST e esquecer dependências
Componentes de terceiros com falhas conhecidas em produção.
Automatizar sem responsável pela triagem
Achados que ninguém lê e risco que permanece sem tratamento.
Tratar DevSecOps como só ferramenta, sem cultura
Segurança segue como gargalo e a esteira não muda o resultado.
Medir sucesso pela quantidade de alertas gerados
Métrica de vaidade que esconde a falta de priorização e de correção.
Quando procurar apoio especializado
O serviço de Segurança de Aplicações da GUARDIASEC ajuda a desenhar a verificação de segurança no pipeline de CI/CD, escolhendo e ajustando SAST, DAST e SCA por risco, com política de severidade que evita a fadiga de alertas e integra a correção ao fluxo do time.
Perguntas frequentes
Qual a diferença entre SAST, DAST e SCA?
SAST analisa o código-fonte sem executá-lo, procurando padrões inseguros. DAST testa a aplicação em execução, do lado de fora, simulando requisições. SCA inventaria as dependências e aponta bibliotecas com vulnerabilidades conhecidas. Os três olham a aplicação de ângulos diferentes e se complementam, porque cada um encontra uma classe de problema que os outros tendem a perder.
DevSecOps substitui o pentest?
Não. As verificações automáticas no pipeline encontram padrões conhecidos e componentes vulneráveis com amplitude e rapidez, mas não substituem o teste manual, que encontra falhas de lógica de negócio e encadeamentos que ferramentas não enxergam. DevSecOps e pentest se complementam: a esteira dá cobertura contínua, e o pentest dá profundidade em momentos-chave, como antes de um lançamento importante.
Como evitar que a esteira de segurança vire ruído?
Com política e priorização. Defina quais severidades quebram a build e quais apenas alertam, priorize por exploração real e criticidade do ativo em vez de contagem de achados, ajuste as regras para reduzir falsos positivos e designe alguém para triar os resultados. Sem isso, o volume de alertas cresce, o time passa a ignorar tudo e a automação deixa de reduzir risco.
Preciso de ferramentas pagas para começar com DevSecOps?
Não para começar. Há opções abertas e maduras para varredura de segredos, análise estática, composição de dependências e teste dinâmico. O maior ganho inicial não vem da ferramenta cara, e sim de encaixar as verificações no fluxo e definir uma política de severidade clara. Comece com o essencial, prove valor e só então avalie soluções pagas onde elas realmente reduzem esforço ou ampliam cobertura.
O que significa mover a segurança para a esquerda?
É a ideia de deslocar a verificação de segurança para o início do ciclo, perto de quem escreve o código, em vez de deixá-la para uma auditoria no fim. Quanto mais cedo a falha aparece, mais barato é corrigi-la. Na prática, isso vira checagens no editor, no commit e na build. O cuidado é não empurrar tudo para a esquerda sem política, porque aí o desenvolvedor recebe ruído em vez de retorno útil.
DevSecOps funciona em times pequenos?
Funciona, e às vezes com menos atrito, porque a responsabilidade compartilhada já é natural quando poucas pessoas fazem tudo. O segredo é começar simples: varredura de segredos no commit, análise de dependências na build e uma política mínima de severidade. Ferramentas leves e bem escolhidas rendem mais do que uma esteira ambiciosa que ninguém mantém. O princípio é o mesmo de um time grande, na escala do time.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.