DevSecOps é um modelo em que os requisitos de segurança, os controles, os testes, o retorno e a remediação operam de forma contínua em todas as fases do desenvolvimento e das operações de software, em vez de como uma revisão no final. O National Cybersecurity Center of Excellence do NIST o descreve como a integração da segurança como componente fundamental do modelo DevOps, ao longo de sete fases: planejamento, desenvolvimento, construção, testes, liberação, implantação e operação. A segurança não fica entre essas fases. Ela corre dentro de todas elas.
A diferença aparece nos dados de remediação. No State of Attacks 2026 da Fluid Attacks, com base em 1.119.396 vulnerabilidades reportadas em sistemas de clientes entre 1º de janeiro e 31 de dezembro de 2025, os clientes cujos pipelines executavam um portão de segurança remediaram 72 % de suas vulnerabilidades, contra 58 % dos clientes sem ele, e as fecharam em uma mediana de 22 dias em vez de 30.
Esta página cobre o que DevSecOps é e o que não é, em que se diferencia de DevOps, qual trabalho de segurança pertence a cada fase do ciclo, o que significa quebrar o build na prática, onde a automação deixa de bastar e como avaliar a maturidade em vez de tratar a adoção como um interruptor de sim ou não.
O que é DevSecOps?
DevSecOps é a prática de tornar a segurança uma propriedade compartilhada e contínua da entrega de software, em vez de uma barreira no final. As equipes de desenvolvimento, operações e segurança trabalham sobre o mesmo backlog, o mesmo pipeline e a mesma evidência. O objetivo não é frear a entrega, mas eliminar a etapa que costumava detê-la: a revisão de segurança que chega quando o código já está escrito.
Vale esclarecer três mal-entendidos sobre DevSecOps, porque eles determinam como as equipes orçam o trabalho.
Não é uma categoria de ferramentas. Comprar um scanner não torna uma equipe DevSecOps, assim como comprar um servidor de CI não a torna DevOps. O projeto DevSecOps do NIST NCCoE coloca os requisitos de segurança, o design seguro, a modelagem de ameaças e a definição de papéis na fase de planejamento, antes de existir uma única linha de código. As ferramentas chegam depois e servem a essas decisões.
Não é só shift-left. Mover os testes para o início é uma metade. A outra é o que o NIST chama de retorno contínuo: um ciclo que agrega sinais de sucesso, falha e anomalia de todo o ciclo de vida de desenvolvimento de software (SDLC) e os devolve às equipes no ponto mais cedo de detecção. Sem o caminho de volta, mover os testes para a esquerda apenas desloca um gargalo.
Não é uma fase que se termina. O mesmo modelo de referência trata as melhorias, a segurança e o monitoramento como componentes presentes em todas as fases, não como uma etapa própria. Uma equipe que executa análise estática nos commits e nada mais automatizou uma fase de DevSecOps de sete.
DevOps e DevSecOps não são a mesma coisa
DevOps uniu desenvolvimento e operações para entregar mais rápido. DevSecOps mantém essa velocidade e soma a segurança como terceira parte do mesmo acordo, com autoridade para deter uma liberação. A diferença prática não é o número de equipes envolvidas. É o que acontece quando uma verificação falha.
Dimensão | DevOps | DevSecOps |
Objetivo principal | Liberações mais rápidas, frequentes e confiáveis | As mesmas liberações, com o risco conhecido resolvido antes de sair |
Onde fica a segurança | Uma revisão antes de liberar, muitas vezes externa à equipe | Dentro de cada fase, dos requisitos ao tempo de execução |
Quem responde por ela | Uma equipe de segurança, consultada | Desenvolvimento, operações e segurança, com responsabilidade conjunta |
O que uma verificação falha provoca | Gera um chamado | Quebra o build e bloqueia o merge até a política ser cumprida |
Evidência que produz | Registros de testes e implantação | Esses, mais achados, severidade, explorabilidade e histórico de remediação por mudança |
Padrões aos quais mapeia | Métricas de entrega | Um framework de desenvolvimento seguro de software como NIST SSDF, com controles rastreados a requisitos |
Se você quiser primeiro a metade de entrega em separado, a prática sobre a qual DevSecOps se constrói, temos uma página à parte sobre DevOps.
DevSecOps na Fluid Attacks
Aplicamos DevSecOps ao nosso próprio software e o executamos dentro dos pipelines dos nossos clientes. Dessa dupla posição saem os números desta página: os dados de remediação de vulnerabilidades dos nossos clientes e um benchmark controlado em que o nosso scanner e um dos nossos pentesters testaram a mesma aplicação que 36 ferramentas de terceiros.
O que avaliamos e sob quais regras
Testamos os sistemas que o cliente inscreve, enquanto estiverem inscritos, sob um escopo definido e acordado antes do início. A avaliação cobre código-fonte, aplicações em execução, aplicações móveis, infraestrutura como código, configuração de nuvem e dependências de terceiros. Os achados são reportados com sua severidade e a evidência que os sustenta, e uma correção não é dada como fechada até que um reattack reavalie o código, porque uma correção pode introduzir novas vulnerabilidades ou não resolver a original.
Nada no nosso modelo DevSecOps depende de o cliente pausar a entrega. Os testes correm enquanto a aplicação muda, que é a única maneira de os resultados seguirem válidos em uma base de código que é implantada várias vezes ao dia.
Como DevSecOps se parece em um pipeline
Em um pipeline DevSecOps, cada fase tem um controle e cada controle produz evidência sobre a qual a fase seguinte pode agir. É assim que o mapeamento se parece quando está implementado e não apenas descrito.
Fase | O que é executado | Evidência que produz |
Planejamento | Requisitos de segurança selecionados por indústria e regulação; modelagem de ameaças | Um conjunto de requisitos contra o qual o sistema é medido depois |
Desenvolvimento | Static Application Security Testing (SAST), AI SAST e Varredura de Segredos, no IDE e a cada commit | Achados na linha de código, antes do pull request |
Construção | Software Composition Analysis (SCA), geração de SBOM, verificação de contêineres e IaC | Um inventário de dependências com vulnerabilidades conhecidas e alcançabilidade |
Testes | Dynamic Application Security Testing (DAST), MAST, Revisão de Código Seguro manual e Pentesting as a Service (PTaaS) | Achados explorados com prova, não apenas assinaturas |
Liberação | CI Gate avaliado contra a política de severidade do cliente | Uma passagem aprovada ou um build quebrado, com o motivo anexado |
Implantação | CSPM e revisão de configuração | Configurações incorretas ligadas ao ambiente implantado |
Operação | Reattacks sob solicitação, reescaneamento contínuo enquanto o sistema muda | Fechamento verificado, ou um achado reaberto com evidência |
O ciclo DevSecOps. Os nomes das fases seguem o modelo de referência do NIST NCCoE; os controles e a evidência mostrados são os que a Fluid Attacks executa em cada fase.
Qualquer um dos nossos scanners pode ser integrado a um pipeline de CI/CD por meio de contêineres Docker, GitHub Actions ou binários distribuídos, e a plataforma se conecta às ferramentas que as equipes já usam, de IDEs e assistentes de IA a sistemas de acompanhamento de bugs.
O que quebrar o build muda de verdade
"Quebrar o build" é a única prática de DevSecOps com um resultado mensurável nos nossos próprios dados de clientes, então vale separar o slogan do resultado. O CI Gate bloqueia uma implantação enquanto houver vulnerabilidades abertas e não aceitas que violem a política do cliente.
O CI Gate executado com um limiar de severidade de 7.0: o build falha quando há uma vulnerabilidade de severidade alta.
Medida de remediação de vulnerabilidades (1º jan – 31 dez de 2025) | Clientes com CI Gate | Clientes sem ele |
Proporção de vulnerabilidades reportadas que foram remediadas | 72 % | 58 % |
Tempo mediano de remediação | 22 dias | 30 dias |
Isso é uma melhoria de 26,7 % na mediana, sobre uma base de 1.119.396 vulnerabilidades reportadas em sistemas de clientes em 2025. O portão não encontra nada que os scanners já não tivessem encontrado. O que muda é quem precisa lidar com o achado, e quando.
Onde a automação para
Este é o número que complica o discurso habitual dos fornecedores. Nos mesmos dados de 2025, as ferramentas automatizadas encontraram 88,4 % de todas as vulnerabilidades reportadas e os testes manuais encontraram 11,6 %. Lido isoladamente, parece um argumento para automatizar e seguir em frente.
A visão ponderada por risco inverte isso. Essas mesmas ferramentas responderam por 55,8 % da exposição total ao risco, medida em CVSSF, contra 44,2 % dos testes manuais. A vulnerabilidade média encontrada por uma ferramenta carregava 15,5 unidades CVSSF de exposição; a encontrada por um pentester, 93,2, cerca de seis vezes mais. Das vulnerabilidades de severidade crítica reportadas naquele ano, 87 % vieram de testes manuais.
As ferramentas passaram de 29,5 % para 55,8 % da exposição ao risco detectada; os pentesters seguem encontrando 87 % das vulnerabilidades de severidade crítica. Fonte: Fluid Attacks, State of Attacks 2026.
Fonte de detecção (1º jan – 31 dez de 2025) | Proporção de vulnerabilidades encontradas | Proporção de exposição ao risco encontrada | Exposição média por achado (CVSSF) |
Ferramentas automatizadas | 88,4 % | 55,8 % | 15,5 |
Testes manuais | 11,6 % | 44,2 % | 93,2 |
Um teste controlado aponta na mesma direção. No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra uma aplicação semeada com 1.201 vulnerabilidades, 743 delas — 61,9 % — foram detectadas exclusivamente pelo pentester em testes manuais. Sobre o escopo que esse pentester revisou, que excluía as seções já cobertas pelo nosso próprio scanner, ele alcançou 89,6 % de recall com 100 % de precisão.
O melhor resultado automatizado foi de 22,7 % de recall, e veio do nosso próprio scanner; as ferramentas de terceiros mais fortes ficaram entre 21,0 % e 21,6 %, e a média das outras 34 foi de 1,7 %. A automação é o que torna acessíveis os testes DevSecOps contínuos na frequência dos commits. Não é o que encontra a vulnerabilidade que termina em um relatório de incidente.
A prática que decide todo o resto
Se você adotar uma única prática de DevSecOps desta página, que seja a política por trás do portão, e não o portão em si. Um portão configurado por quantidade de vulnerabilidades pune as equipes por ruído de severidade baixa e as treina a pedir exceções. Um portão configurado por severidade e explorabilidade bloqueia o punhado de achados que concentra o risco e deixa o resto passar para o backlog.
Os dados de 2025 sustentam a assimetria: as vulnerabilidades de severidade alta e crítica foram 4,5 % dos achados, mas 79,9 % da exposição total ao risco. Coloque o limiar onde está essa concentração e o portão deixa de ser um obstáculo que as equipes contornam.
Para se aprofundar: nosso guia sobre como implementar DevSecOps percorre a seleção de requisitos, e nosso artigo de boas práticas de DevSecOps cobre os hábitos operacionais em detalhe.
Como funciona o ciclo DevSecOps
Funciona atribuindo uma atividade de segurança e um portão de controle a cada fase, e devolvendo às fases anteriores o que cada uma aprende. O NIST descreve os portões de controle como controles técnicos ou organizacionais aplicados antes de permitir que uma mudança de software avance para a etapa seguinte. O pipeline os faz valer; o ciclo de retorno é o que faz valer a pena aplicá-los.
Planejamento
A fase de planejamento fixa os requisitos de segurança contra os quais o software será medido, define uma arquitetura que segue princípios de design seguro e executa modelagem de ameaças para decidir o que vale a pena defender. Os requisitos costumam vir da regulação que a empresa já precisa cumprir, como PCI DSS, HIPAA ou GDPR, mais um framework de desenvolvimento seguro de software. NIST SP 800-218, o Secure Software Development Framework, é a linha de base comum; mapeamos suas práticas para requisitos verificáveis em nosso banco de dados público.
Pular esta fase é o que produz a categoria de achado mais cara: a fraqueza criada por design, que nenhum scanner reconhece porque o código faz exatamente o que foi especificado.
Desenvolvimento, construção e testes
Estas três fases concentram a maior parte do trabalho automatizado de DevSecOps. A análise estática e a varredura de segredos correm enquanto a pessoa desenvolvedora escreve e de novo a cada commit; a análise de composição e a geração de SBOM correm na construção contra a árvore de dependências; os testes dinâmicos e móveis correm contra o artefato implantado. A revisão manual e o pentesting correm em paralelo, com uma cadência definida pela velocidade com que a aplicação muda.
Colocá-las aqui é uma questão de custo. Um achado detectado no IDE é uma correção. O mesmo achado detectado depois da liberação é um incidente, um patch, um ciclo de liberação e uma conversa com um cliente.
Liberação, implantação e operação
Na liberação, o portão decide. Na implantação, as verificações de nuvem e configuração pegam os erros de configuração que nunca aparecem no código-fonte. Na operação, o sistema é reescaneado conforme muda e as correções são verificadas em vez de presumidas, que é a etapa que as equipes mais pulam: um chamado fechado não é uma vulnerabilidade fechada até que algo a teste de novo.
Retorno contínuo
O NIST define este ciclo como um que agrega critérios de decisão — sinais de sucesso, falha e anomalia — de todo o SDLC e os entrega às equipes no ponto mais cedo de detecção, para que sejam devolvidos às fases anteriores. Na prática, isso significa que uma fraqueza recorrente em produção deveria mudar o conjunto de requisitos, o modelo de ameaças e a política do portão, e não apenas a linha de código que a causou.
As equipes que tratam os achados como chamados corrigem instâncias. As equipes que tratam os achados como retorno param de produzir a classe inteira.
Por que precisamos de DevSecOps?
DevSecOps existe porque a alternativa deixou de funcionar. O software é implantado de forma contínua, depende de código que ninguém na equipe escreveu e roda sobre infraestrutura definida por mais código. Uma revisão de segurança trimestral não consegue descrever um sistema que mudou quatrocentas vezes desde a anterior.
A exposição cresce, não diminui
Em 2025, 70 % dos sistemas que avaliamos tinham ao menos uma vulnerabilidade de severidade alta ou crítica, contra 53,3 % em 2024. A mediana de exposição ao risco por sistema subiu 33,5 % ano a ano. São sistemas sob testes contínuos, o que significa que a taxa de achados reflete o que existe, e não o que deu tempo de olhar.
Suas dependências são parte da sua superfície de ataque
A maior parte do código de uma aplicação moderna foi escrita por outra pessoa, e os atacantes sabem disso. Em março de 2024, a CISA e a comunidade de código aberto reportaram código malicioso embutido no XZ Utils versões 5.6.0 e 5.6.1, registrado como CVE-2024-3094, em uma biblioteca de compressão que pode estar presente em distribuições Linux. Nada estava errado nas aplicações que dependiam dela. O comprometimento entrou pela construção.
Por isso a segurança da cadeia de suprimentos de software fica dentro do pipeline e não em um questionário anual a fornecedores. Nosso próprio requisito a respeito é direto: os sistemas devem usar versões estáveis, testadas e atualizadas de componentes de terceiros. Nossa análise do OWASP Top 10 2025 cobre como a categoria ganhou destaque, e aprofundamos o tema em nossa página sobre segurança da cadeia de suprimentos de software.
Segurança é assunto de todos
Uma equipe de segurança de dez pessoas não consegue revisar a produção de trezentas pessoas desenvolvedoras, e nunca se esperou que conseguisse. DevSecOps distribui o trabalho: quem desenvolve responde pelos achados em seu código, operações pela configuração, e a equipe de segurança pelos requisitos, pelo modelo de ameaças e pelas decisões de critério. O papel que costura essas peças tem nome e descrição de cargo, e o cobrimos em nosso artigo sobre o que faz uma pessoa engenheira DevSecOps.
Shift-left, e o que ele deixa de fora
A segurança shift-left consiste em mover os testes para o início do SDLC, onde os defeitos são mais baratos de corrigir. É a metade mais citada de DevSecOps e é o comportamento correto por padrão. Sozinha, também é uma descrição incompleta do que o modelo exige.
O que ela deixa de fora é o lado direito. As vulnerabilidades chegam à produção de todo jeito: por dependências atualizadas depois da liberação, por desvio de configuração, por classes de falha que nenhum teste prévio pega. Mover para a esquerda estreita essa janela; o monitoramento, o reescaneamento e os reattacks a fecham para o que escapa. O enquadramento útil não é esquerda contra direita, mas cobertura DevSecOps ao longo de toda a linha, com o retorno do lado direito redefinindo o que se testa no esquerdo.
Automação de DevSecOps junto com técnicas manuais
A automação e os testes manuais resolvem metades diferentes do problema de DevSecOps: a automação dá cobertura na velocidade em que o código muda, os testes manuais dão os achados que carregam a severidade. Depender só da automação implica aceitar tanto falsos positivos, que custam tempo de revisão, quanto falsos negativos, que custam mais.
Na prática, os scanners correm a cada commit e os pentesters trabalham de forma contínua sobre os mesmos sistemas, com os dois conjuntos de resultados na mesma plataforma e no mesmo backlog. Os scanners estreitam a superfície; os pentesters encadeiam o que resta em algo que um atacante poderia usar, incluídas falhas de lógica de negócio que nenhuma assinatura descreve. Nosso artigo sobre DevSecOps na nuvem aplica a mesma divisão a pipelines nativos de nuvem, onde os arquivos de IaC e as imagens de contêiner precisam de testes contínuos próprios.
Como evoluir de DevOps para DevSecOps
A maturidade DevSecOps é um caminho, não um interruptor. Uma equipe não "faz DevSecOps" ou não: ela tem um nível por prática, e a pergunta útil é qual prática subir em seguida. Modelos como OWASP SAMM existem justamente para tornar isso avaliável, com práticas pontuadas em governança, design, implementação, verificação e operações.
Uma ordem que funciona, quando não há uma avaliação de partida:
Defina os requisitos primeiro: escolha o framework e as regulações que se aplicam, para que os achados posteriores tenham contra o que ser medidos.
Instrumente as fases que você já automatiza: a análise estática e a de composição vão onde seu CI já roda.
Adicione o portão, por severidade: uma política sobre severidade alta e crítica, não sobre quantidades.
Adicione pentesting onde a severidade se concentra: os achados críticos são os que a automação perde.
Feche o ciclo: use reattacks para verificar as correções e deixe que as fraquezas recorrentes mudem os requisitos, e não apenas o código.
Reavalie: pontue as práticas de novo e suba a mais baixa.
Boas práticas de DevSecOps
As práticas que separam um programa DevSecOps que funciona de um que só tem ferramentas são sobretudo organizacionais. A colaboração vem primeiro: as equipes de desenvolvimento e segurança que revisam o produto juntas encontram problemas que nenhuma encontraria sozinha, porque entender por que o código faz algo é a rota mais rápida para saber como ele quebra.
Além disso: testar de forma contínua e não por ciclos de auditoria; priorizar por explorabilidade e severidade e não por quantidade de achados; verificar cada correção com um reattack em vez de confiar em um chamado fechado; e manter o ciclo de retorno de quem desenvolve dentro do próprio ambiente, porque um achado que exige entrar em outro portal é atendido tarde.
Como DevSecOps se relaciona com os red teams?
O red teaming complementa DevSecOps testando a organização e não a base de código. Um red team emula adversários reais — seus recursos, táticas e procedimentos — no plano tecnológico e no humano, incluída a engenharia social, para medir quão bem funcionam a prevenção, a detecção e a resposta. DevSecOps protege o que você constrói; o red teaming verifica o que acontece quando alguém vai atrás disso.
Os dois se encontram no ciclo de retorno. O que um exercício de red team descobre pertence ao conjunto de requisitos e ao modelo de ameaças, que é de onde sai a política do portão da liberação seguinte.
SecDevOps?
SecDevOps, DevSecOps e DevOpsSec nomeiam a mesma coisa. O reordenamento às vezes é usado para argumentar que a segurança deveria vir primeiro e não no meio, mas nenhum organismo de padrões os distingue, e o NIST usa DevSecOps. O termo que você escolher importa muito menos do que se uma verificação de segurança que falha consegue deter uma liberação.
Conclusões
DevSecOps não é a automação dos testes de segurança, nem a prática de mover a segurança para a esquerda. É um modelo de ciclo de vida em que os requisitos, os controles, os testes, o retorno, o monitoramento e a remediação operam de forma contínua em planejamento, desenvolvimento, construção, testes, liberação, implantação e operações, com portões de controle decidindo o que avança.
A evidência de DevSecOps é específica, não filosófica. As equipes que quebraram o build diante de violações de política em 2025 alcançaram uma taxa de remediação de vulnerabilidades de 72 % contra 58 % sem esse controle, e o fizeram oito dias mais rápido na mediana. As ferramentas automatizadas encontraram 88,4 % das vulnerabilidades, mas apenas 55,8 % da exposição ao risco, e 87 % dos achados de severidade crítica vieram de testes manuais. A segurança shift-left e o retorno contínuo são ambos estruturais, e um programa que financie só um dos dois vai notar isso na severidade do que lhe escapa.
Perguntas frequentes
DevSecOps é só adicionar ferramentas de segurança ao pipeline de CI/CD?
Não. As ferramentas no pipeline são uma fase de sete. O modelo de referência do NIST NCCoE coloca trabalho de segurança em planejamento, desenvolvimento, construção, testes, liberação, implantação e operação, com melhorias, segurança e monitoramento presentes em todas elas, mais um ciclo de retorno que devolve os achados às fases anteriores. Uma equipe que escaneia a cada commit e nada mais automatizou uma fração do modelo.
DevSecOps substitui o pentesting?
Não, e os dados explicam por quê. Sobre 1.119.396 vulnerabilidades reportadas em sistemas de clientes entre janeiro e dezembro de 2025, as ferramentas automatizadas encontraram 88,4 % das vulnerabilidades, mas 55,8 % da exposição ao risco, enquanto 87 % das vulnerabilidades de severidade crítica vieram de testes manuais. A automação entrega cobertura na velocidade em que o código muda; o pentesting entrega os achados que carregam a severidade. Um programa DevSecOps precisa dos dois.
O que é um portão de segurança e o que significa quebrar o build?
Um portão de segurança é um controle aplicado antes de permitir que uma mudança passe à etapa seguinte do ciclo. Quebrar o build significa que esse portão detém a implantação enquanto houver vulnerabilidades abertas e não aceitas que violem a política definida, o que obriga a uma correção em vez de a um chamado. Em 2025, os clientes que o usavam remediaram 72 % de suas vulnerabilidades contra 58 % de quem não usava.
Como se mede a maturidade DevSecOps?
Com um modelo pontuado, e não com uma resposta de sim ou não. Frameworks como o OWASP SAMM avaliam práticas em governança, design, implementação, verificação e operações, de modo que uma equipe consegue ver qual prática está mais fraca e subir aquela. Tratar a adoção como binária esconde a diferença entre uma equipe que escaneia a cada commit e uma que também fixa requisitos, aplica portões por severidade e verifica as correções.
A Fluid Attacks suporta DevSecOps em pipelines de CI/CD?
Sim. Nossos scanners se integram ao CI/CD por meio de contêineres Docker, GitHub Actions ou binários distribuídos, e nosso CI Gate avalia cada build contra sua política de severidade e bloqueia os merges quando há vulnerabilidades que violam a política. A plataforma se conecta aos IDEs, assistentes de IA e sistemas de acompanhamento de bugs que sua equipe já usa, e nossos pentesters testam os mesmos sistemas de forma contínua no plano Advanced.
Entregue rápido sem vulnerabilidades
Nossos scanners, nossa IA e nossos pentesters levam os testes DevSecOps às suas aplicações conforme elas mudam, e nosso CI Gate detém os builds que levariam uma vulnerabilidade crítica para a produção. Start free trial · Contact us
