DevSecOps integra segurança ao ciclo de CI/CD por meio de testes automatizados em cada etapa: SAST analisa o código-fonte, SCA verifica dependências de terceiros, o secrets scanning bloqueia credenciais expostas e o DAST testa a aplicação em execução. O pentest entra depois, validando o que a automação não alcança.
A promessa do DevSecOps não é adicionar uma etapa de segurança ao final do desenvolvimento — é distribuir a verificação por todo o pipeline, de modo que uma falha seja encontrada na hora em que o custo de corrigi-la é mais baixo. Quanto mais tarde um problema aparece, mais caro ele fica: uma vulnerabilidade detectada no commit consome minutos; a mesma falha em produção envolve incidente, correção emergencial e, muitas vezes, exposição de dados. Este guia percorre os quatro tipos de teste automatizado que sustentam um pipeline seguro, mostra onde cada um entra e delimita a fronteira em que a automação para e o teste de invasão começa.
O que é DevSecOps em CI/CD?
DevSecOps é a prática de incorporar controles de segurança automatizados ao pipeline de integração e entrega contínuas (CI/CD), de forma que cada mudança de código passe por verificação antes de avançar. Em vez de tratar segurança como um portão no fim do processo, ela vira uma responsabilidade compartilhada entre desenvolvimento, operações e segurança, executada continuamente.
Na prática, isso significa que o pipeline — a sequência automatizada que constrói, testa e implanta a aplicação — ganha etapas de verificação de segurança acopladas às etapas que já existiam. Um commit dispara análise de código; um build dispara verificação de dependências; um deploy em ambiente de teste dispara varredura da aplicação em execução. Cada estágio tem um critério de aprovação, e uma falha grave pode interromper a promoção da mudança (o chamado break the build).
O ganho é de velocidade e de contexto. A falha chega ao desenvolvedor que a introduziu, no mesmo dia, com a linha de código apontada — não em um relatório trimestral desconectado do trabalho atual. A perda de contexto entre "escrevi o código" e "descobri o problema" é o que torna a correção cara, e o DevSecOps existe para encurtar essa distância.
Quais são os tipos de teste de segurança automatizado?
Quatro categorias de teste formam a base de um pipeline DevSecOps. Elas são complementares — cada uma enxerga uma superfície que as outras não alcançam, e nenhuma substitui as demais.
- SAST (Static Application Security Testing) — analisa o código-fonte, o bytecode ou o binário sem executá-lo. Identifica padrões inseguros diretamente no código: injeção de SQL, uso incorreto de criptografia, tratamento indevido de entrada. É o teste mais próximo do desenvolvedor e o mais barato de executar, mas gera falsos positivos porque avalia o código isolado do seu contexto de execução.
- SCA (Software Composition Analysis) — inventaria as dependências de terceiros (bibliotecas, frameworks, pacotes) e as compara com bases de vulnerabilidades conhecidas. Como a maior parte de uma aplicação moderna é código que a equipe não escreveu, o SCA cobre uma superfície que o SAST ignora: a das falhas herdadas de componentes open source e comerciais, incluindo licenças incompatíveis.
- Secrets scanning — varre o código, o histórico do repositório e os artefatos de build em busca de credenciais expostas: chaves de API, tokens, senhas e certificados escritos diretamente no código. Uma credencial vazada em um repositório é explorável em minutos por varredura automatizada, e o histórico do Git preserva o segredo mesmo depois de removido do arquivo atual.
- DAST (Dynamic Application Security Testing) — testa a aplicação em execução, de fora para dentro, sem acesso ao código. Envia requisições maliciosas e observa as respostas, encontrando falhas que só existem em tempo de execução: erros de configuração, problemas de autenticação e sessão, comportamentos de servidor que o código-fonte não revela. É mais lento e roda mais tarde no pipeline, sobre um ambiente já implantado.
Um quinto tipo, o IAST (Interactive Application Security Testing), combina as abordagens estática e dinâmica: instrumenta a aplicação por dentro enquanto ela é exercitada por testes, correlacionando a requisição externa com a linha de código que a processa. Reduz falsos positivos, mas exige instrumentação e uma suíte de testes que exercite os caminhos relevantes.
A tabela abaixo resume as diferenças práticas entre as quatro categorias centrais:
| Critério | SAST | SCA | Secrets scanning | DAST |
|---|---|---|---|---|
| O que analisa | Código-fonte próprio | Dependências de terceiros | Credenciais expostas | Aplicação em execução |
| Precisa executar a aplicação? | Não | Não | Não | Sim |
| Onde entra no pipeline | Commit / build | Build | Commit / pre-commit | Ambiente de teste |
| Principal limitação | Falsos positivos | Só cobre falhas conhecidas | Não avalia lógica | Não aponta a linha de código |
| Falha que enxerga melhor | Injeção, cripto fraca | CVE em biblioteca | Chave de API vazada | Config, sessão, autenticação |
Nenhuma dessas ferramentas entende a lógica de negócio da aplicação. Elas encontram padrões — não raciocinam sobre o que o sistema deveria ou não permitir. Essa é a fronteira que define onde o pentest entra.
Onde cada teste entra no pipeline de CI/CD?
A ordem importa: cada teste é posicionado no ponto em que seu custo é menor e sua resposta é mais rápida. Um pipeline maduro distribui as verificações assim:
- Pré-commit e commit — secrets scanning e um SAST leve rodam antes ou no momento do commit, no ambiente do desenvolvedor ou no gatilho inicial. O objetivo é impedir que uma credencial ou um padrão claramente inseguro sequer entre no repositório. É a etapa mais barata de todas.
- Build — SAST completo e SCA rodam quando o código é compilado e as dependências são resolvidas. Aqui o pipeline tem a árvore de dependências inteira e o código consolidado, o que permite inventário preciso e análise mais profunda. Uma vulnerabilidade crítica pode interromper o build.
- Ambiente de teste — DAST e, quando aplicável, IAST rodam sobre a aplicação já implantada em um ambiente que espelha produção. Como exigem a aplicação no ar, entram depois do build bem-sucedido.
- Pré-produção e produção contínua — SCA continua rodando de forma agendada, porque uma dependência segura hoje pode ter uma CVE publicada amanhã sem que uma linha de código mude. O monitoramento de dependências é permanente, não pontual.
O princípio que organiza tudo isso é o shift left: mover a verificação para o mais cedo possível no ciclo. Mas shift left não significa concentrar tudo no início — significa colocar cada teste no ponto mais precoce em que ele consegue produzir um resultado confiável. O DAST não pode ser deslocado para o commit porque não há aplicação em execução ali; o secrets scanning, sim.
Como funciona o secrets scanning e por que ele é crítico?
O secrets scanning merece atenção separada porque a falha que ele previne tem a menor janela de exploração de todas. Uma chave de API ou senha comprometida em um repositório — sobretudo em um repositório público — é encontrada por varredura automatizada em minutos, e a exploração não exige nenhuma sofisticação: a credencial simplesmente funciona.
Dois pontos costumam ser subestimados:
- O histórico do Git preserva o segredo. Remover a credencial do arquivo atual e fazer um novo commit não a apaga — ela permanece acessível no histórico. A remediação correta exige rotacionar a credencial (invalidá-la na origem), não apenas editar o arquivo.
- A prevenção vale mais que a detecção. Um hook de pré-commit que bloqueia o segredo antes de ele entrar no repositório é ordens de magnitude mais eficaz do que descobri-lo depois. Por isso o secrets scanning aparece tão cedo quanto possível no pipeline, idealmente no ambiente do próprio desenvolvedor.
Quando uma credencial é detectada já dentro do repositório, o tratamento é o mesmo de um incidente: rotacionar imediatamente, investigar se houve uso indevido e limpar o histórico quando o repositório assim exigir.
Onde o pentest se encaixa no DevSecOps?
A automação encontra classes conhecidas de falha em padrões conhecidos de código. O pentest encontra o que exige raciocínio adversarial: falhas de lógica de negócio, cadeias de vulnerabilidades individualmente inofensivas que juntas comprometem o sistema, e abusos de autorização que só fazem sentido quando alguém entende o que o sistema deveria proteger.
Nenhum SAST detecta que um usuário comum pode acessar o pedido de outro cliente trocando um identificador na URL, porque o código está "correto" — ele faz exatamente o que foi escrito. Nenhum DAST entende que uma sequência legítima de operações, executada fora de ordem, contorna um controle de aprovação. Essas são falhas de projeto, não de implementação, e é onde o teste de invasão conduzido por especialistas continua insubstituível.
O papel do pentest no DevSecOps é duplo:
- Validar o que a automação reporta. Uma ferramenta aponta centenas de achados; o teste manual confirma quais são realmente exploráveis, elimina falsos positivos e prova o impacto encadeando o que importa.
- Cobrir o que a automação não enxerga. Lógica de negócio, autorização, encadeamento de falhas e a superfície que nenhuma assinatura descreve.
A cadência muda em relação ao modelo tradicional. Em vez de um único pentest anual desconectado do desenvolvimento, o teste manual passa a ser acionado por marcos: uma nova funcionalidade sensível, uma mudança de arquitetura, uma integração externa. A automação sustenta a cobertura contínua; o pentest aprofunda nos pontos de maior risco. Os dois se retroalimentam — os achados manuais viram regras e casos de teste que a automação passa a cobrir dali em diante.
Como a Berghem executa DevSecOps
Na Berghem, o serviço de DevSecOps não começa pela escolha de ferramentas, mas pelo modelo de ameaça da aplicação: o que precisa ser protegido, contra quem, e onde uma falha teria o maior impacto no negócio. A partir daí, integramos SAST, SCA, secrets scanning e DAST ao pipeline existente, calibrando cada etapa para reduzir ruído — um pipeline que grita a cada build é um pipeline que a equipe aprende a ignorar.
O trabalho se apoia em três princípios. O primeiro é a redução de falsos positivos: uma ferramenta mal calibrada custa mais em atenção desperdiçada do que entrega em segurança, então cada regra é ajustada ao contexto do projeto. O segundo é a priorização por impacto — os achados são ordenados por severidade CVSS e por exploração real, não por volume, com metodologia reconhecida (OWASP, NIST SP 800-115) sustentando cada etapa. O terceiro é a integração entre automação e teste manual: a esteira cobre o contínuo, e o pentest entra nos marcos de maior risco.
Somos uma empresa de segurança da informação em São Paulo, e o DevSecOps se conecta ao restante do portfólio quando o risco justifica: pentest de API e pentest de cloud para as superfícies que a esteira expõe, exercícios de Red Team para validar a resposta de ponta a ponta, e a esteira de compliance quando há adequação à ISO 27001 ou outras normas em jogo. Cada relatório entrega evidência, passos de reprodução, severidade e correção priorizada, além do reteste que confirma a eliminação da falha.
A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.
Perguntas frequentes
Qual a diferença entre SAST e DAST?
SAST analisa o código-fonte sem executá-lo e aponta a linha exata do problema, mas gera falsos positivos por avaliar o código fora de contexto. DAST testa a aplicação em execução, de fora para dentro, e encontra falhas de configuração e sessão que só existem em tempo de execução, sem apontar a linha de código. São complementares, não alternativos.
DevSecOps elimina a necessidade de pentest?
Não. A automação de DevSecOps encontra classes conhecidas de falha em padrões conhecidos, mas não raciocina sobre lógica de negócio, abuso de autorização ou encadeamento de vulnerabilidades. O pentest cobre exatamente essa superfície e valida quais achados automatizados são realmente exploráveis. Os dois se complementam: a esteira sustenta a cobertura contínua, o pentest aprofunda nos pontos de maior risco.
O que fazer quando o secrets scanning encontra uma credencial exposta?
Trate como incidente. A prioridade é rotacionar a credencial na origem — apenas removê-la do arquivo não basta, porque o histórico do Git a preserva. Depois, investigue se houve uso indevido no período de exposição e, quando o repositório exigir, limpe o segredo do histórico. Prevenir com um hook de pré-commit é sempre mais eficaz que remediar depois.
Para integrar SAST, DAST, SCA e secrets scanning ao seu pipeline com calibração dedicada, conheça o serviço de DevSecOps da Berghem.