DevSecOps: o que é, como funciona e por que segurança precisa fazer parte do ciclo de desenvolvimento

DevSecOps é a junção de Development, Security e Operations. Em português direto, significa integrar segurança ao desenvolvimento e à operação de software de forma contínua, automatizada e compartilhada.

A diferença principal entre DevOps e DevSecOps não está apenas em adicionar uma ferramenta de segurança na pipeline. A mudança real está na forma como a organização enxerga segurança. Em um modelo tradicional, o time de desenvolvimento cria a aplicação, o time de operações publica e mantém o ambiente, e o time de segurança entra no final para revisar problemas. Esse modelo costuma gerar atraso, retrabalho e correções emergenciais.

No DevSecOps, segurança deixa de ser uma barreira no final do processo e passa a ser uma responsabilidade distribuída durante todo o ciclo de vida do software. Isso inclui planejamento, escrita de código, revisão, build, teste, empacotamento, deploy, monitoramento e resposta a incidentes.

A Red Hat define DevSecOps como uma abordagem de cultura, automação e design de plataforma que integra segurança como responsabilidade compartilhada durante todo o ciclo de vida de TI. A OWASP também descreve DevSecOps como a inclusão de etapas de segurança dentro das pipelines existentes de CI/CD, com o objetivo de construir segurança dentro do processo de desenvolvimento e entrega.

Em uma visão prática, DevSecOps tenta responder uma pergunta simples: como entregar software rápido sem transformar velocidade em risco?

Por que DevSecOps se tornou tão importante?

Aplicações modernas mudaram muito. Hoje, um sistema raramente é apenas um código monolítico hospedado em um servidor controlado manualmente. O software atual costuma depender de APIs, containers, bibliotecas open source, cloud, infraestrutura como código, pipelines automatizadas, segredos, tokens, imagens Docker, serviços gerenciados e integrações externas.

Isso aumentou muito a superfície de ataque. Um problema de segurança pode surgir em várias camadas:

O DevSecOps surge porque segurança manual não acompanha mais a velocidade de entrega de software. Se uma equipe publica várias versões por semana ou por dia, não faz sentido depender apenas de revisão manual no final. A segurança precisa ser automatizada dentro do fluxo.

O NIST SSDF reforça exatamente essa ideia ao propor práticas fundamentais de desenvolvimento seguro que devem ser adicionadas e integradas aos modelos de SDLC existentes, já que muitos ciclos de desenvolvimento não tratam segurança em profundidade por padrão.

A CISA, por meio da iniciativa Secure by Design, também defende que fabricantes e desenvolvedores assumam mais responsabilidade pela segurança dos produtos, tratando segurança como parte do design e não como uma correção posterior.

DevOps tradicional vs DevSecOps

DevOps já trouxe uma mudança importante ao aproximar desenvolvimento e operações. A ideia era reduzir silos, automatizar entregas e tornar deploys mais frequentes e confiáveis. Porém, em muitos ambientes, a segurança continuou como uma camada externa.

O DevSecOps corrige essa lacuna colocando validações de segurança dentro do mesmo fluxo automatizado usado para build, teste e deploy.

Em uma pipeline DevOps comum, o foco costuma estar em compilar, testar e publicar. Em uma pipeline DevSecOps, o fluxo adiciona etapas como SAST, SCA, secret scanning, análise de container, validação de IaC, políticas de deploy e monitoramento de runtime.

commit → build → testes → análise de segurança → empacotamento → deploy → monitoramento → resposta

A diferença é que a segurança passa a acompanhar cada etapa do ciclo, reduzindo a chance de uma vulnerabilidade chegar intacta ao ambiente de produção.

O conceito de Shift Left

Um dos conceitos mais conhecidos em DevSecOps é o chamado Shift Left. A ideia é mover atividades de segurança para fases mais iniciais do desenvolvimento.

Em vez de descobrir uma vulnerabilidade crítica apenas depois do deploy, o time tenta detectar problemas ainda no commit, no pull request ou durante o build.

Exemplo simples:

código inseguro → detecção no pull request → correção antes do merge → build bloqueado se necessário

Isso reduz custo e impacto. Corrigir uma query vulnerável a SQL Injection durante a revisão de código é muito mais simples do que corrigir a mesma falha depois que ela foi explorada em produção.

Mas Shift Left não significa abandonar segurança em produção. Esse é um erro comum. O ideal é combinar Shift Left com Shift Right.

Shift Left foca em prevenir cedo. Shift Right foca em observar, detectar e responder em produção.

Onde a segurança entra no ciclo DevSecOps?

Um ciclo DevSecOps bem implementado normalmente envolve segurança em várias fases.

Essa integração é importante porque uma vulnerabilidade pode nascer em qualquer ponto do processo.

Um token exposto pode aparecer no commit. Uma dependência vulnerável pode entrar no build. Um container inseguro pode chegar no registry. Uma permissão cloud perigosa pode ser criada via Terraform. Um endpoint sem autenticação pode ser publicado em produção.

O papel do DevSecOps é criar barreiras automatizadas e visíveis em cada uma dessas etapas.

Principais práticas de DevSecOps

A OWASP mantém diretrizes específicas para DevSecOps com foco em implementação de pipeline segura, boas práticas e cultura de Shift Left. O projeto também destaca que DevSecOps busca ajudar empresas de diferentes tamanhos que já possuem pipelines DevOps.

Na prática, algumas das principais práticas são:

Cada uma dessas práticas cobre uma parte diferente da superfície de ataque.

SAST: análise estática de código

SAST significa Static Application Security Testing. É a análise de código-fonte sem executar a aplicação. Ela tenta encontrar padrões inseguros diretamente no código.

Exemplos de problemas que SAST pode detectar:

Exemplo conceitual de código vulnerável:

app.get("/user", async (req, res) => { const id = req.query.id; const result = await db.query("SELECT * FROM users WHERE id = " + id); res.json(result.rows); });

O problema aqui é que o parâmetro id entra diretamente na query. Em um fluxo DevSecOps, um scanner SAST poderia marcar esse trecho antes do merge.

Versão mais segura:

app.get("/user", async (req, res) => { const id = req.query.id; const result = await db.query("SELECT * FROM users WHERE id = $1", [id]); res.json(result.rows); });

SCA: análise de dependências

SCA significa Software Composition Analysis. Essa prática analisa bibliotecas, frameworks e pacotes utilizados pela aplicação.

Esse ponto é essencial porque a maioria das aplicações modernas depende fortemente de componentes open source. Uma API Node.js pode usar dezenas ou centenas de pacotes indiretos. Uma aplicação Java pode depender de múltiplos artefatos Maven. Um projeto Python pode carregar bibliotecas com vulnerabilidades conhecidas.

O SCA identifica:

Exemplo de comando comum em projetos Node.js:

npm audit

Exemplo em Python:

pip-audit

Exemplo em Java com Maven:

mvn org.owasp:dependency-check-maven:check

O NIST SSDF também reforça a importância de práticas seguras em todo o ciclo de desenvolvimento, incluindo gestão de componentes e redução de vulnerabilidades no software entregue.

Secret scanning: evitando vazamento de credenciais

Um dos problemas mais comuns em ambientes reais é vazamento de credenciais no repositório.

Isso pode incluir:

Exemplo de segredo exposto:

AWS_ACCESS_KEY_ID=AKIAxxxxxxxxxxxxxxxx AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Em um fluxo DevSecOps, a pipeline deve bloquear esse tipo de commit antes que ele seja incorporado ao branch principal.

Exemplo de verificação com Gitleaks:

gitleaks detect --source . --verbose

Exemplo de etapa em pipeline:

secret_scan: stage: security script: - gitleaks detect --source . --verbose

DAST: teste dinâmico da aplicação

DAST significa Dynamic Application Security Testing. Diferente do SAST, ele testa a aplicação em execução.

Esse tipo de teste tenta encontrar vulnerabilidades observando o comportamento real da aplicação.

Problemas comuns detectados por DAST:

Fluxo conceitual:

deploy em ambiente de teste → scanner DAST → requisições controladas → relatório → bloqueio ou aprovação

Exemplo usando OWASP ZAP em modo baseline:

zap-baseline.py -t https://staging.exemplo.com -r zap-report.html

Em DevSecOps, o DAST deve ser usado com cuidado para não gerar impacto em produção. O ideal é rodar primeiro em ambientes de staging, homologação ou laboratórios controlados.

Segurança em containers

Containers viraram padrão em muitas arquiteturas modernas, mas também trouxeram novos riscos.

Uma imagem Docker insegura pode conter:

Exemplo de Dockerfile ruim:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl vim netcat
COPY . /app
WORKDIR /app
CMD ["node", "server.js"]

Problemas:

Versão mais segura:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
CMD ["node", "server.js"]

Exemplo de scan com Trivy:

trivy image minha-aplicacao:latest

Essa validação pode ser adicionada na pipeline para impedir que imagens críticas sejam publicadas no registry.

Infrastructure as Code e cloud security

DevSecOps também precisa olhar para infraestrutura como código. Em muitos ambientes, cloud não é configurada manualmente. Ela é criada por Terraform, CloudFormation, Pulumi, Ansible ou Helm charts.

Isso significa que erros de segurança também podem ser versionados.

Exemplo de configuração insegura em Terraform:

resource "aws_security_group_rule" "ssh_open" { type = "ingress" from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] }

Esse trecho libera SSH para a internet inteira.

Uma abordagem mais segura seria restringir origem:

resource "aws_security_group_rule" "ssh_restricted" { type = "ingress" from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["203.0.113.10/32"] }

Ferramentas como Checkov, tfsec e Terrascan podem identificar esse tipo de problema antes da aplicação da infraestrutura.

Exemplo com Checkov:

checkov -d .

Segurança da própria pipeline CI/CD

Um erro muito comum é proteger a aplicação, mas esquecer que a pipeline também é um alvo.

Pipelines CI/CD têm acesso a:

Se a pipeline for comprometida, o atacante pode alterar código, inserir backdoor, roubar secrets ou publicar artefatos maliciosos.

A OWASP possui material específico sobre segurança em CI/CD, destacando riscos e boas práticas para proteger a própria pipeline.

Algumas medidas importantes:

Exemplo de pipeline DevSecOps

Abaixo está um exemplo conceitual de pipeline com etapas de segurança. Ele não representa uma receita universal, mas mostra como diferentes validações podem ser integradas ao fluxo.

stages: - test - security - build - container_scan - deploy
unit_tests:
stage: test
script:
- npm ci
- npm test
sast:
stage: security
script:
- semgrep scan --config auto .
secret_scan:
stage: security
script:
- gitleaks detect --source . --verbose
dependency_scan:
stage: security
script:
- npm audit --audit-level=high
build_image:
stage: build
script:
- docker build -t registry.local/app:$CI_COMMIT_SHA .
container_scan:
stage: container_scan
script:
- trivy image --severity HIGH,CRITICAL registry.local/app:$CI_COMMIT_SHA
deploy_staging:
stage: deploy
script:
- kubectl apply -f k8s/staging/

Em uma organização mais madura, esse fluxo poderia incluir também:

Policy as Code

Policy as Code é a prática de transformar regras de segurança e conformidade em código versionado.

Em vez de uma política ficar apenas em documento, ela é aplicada automaticamente na pipeline.

Exemplo de regra conceitual:

não permitir container executando como root

Exemplo de política em Kubernetes:

apiVersion: v1 kind: Pod metadata: name: app spec: securityContext: runAsNonRoot: true containers: - name: app image: minha-app:latest securityContext: allowPrivilegeEscalation: false

Esse tipo de controle reduz dependência de validação manual.

SBOM e rastreabilidade

SBOM significa Software Bill of Materials. É uma lista dos componentes que fazem parte de uma aplicação ou artefato.

A importância do SBOM aumentou porque ataques à cadeia de suprimentos de software se tornaram mais frequentes. Quando uma vulnerabilidade crítica aparece em uma biblioteca popular, empresas precisam responder rapidamente a uma pergunta simples: onde usamos isso?

Sem inventário, a resposta pode demorar dias. Com SBOM, a organização consegue identificar dependências afetadas com mais velocidade.

Um SBOM pode conter:

Exemplo de geração com Syft:

syft packages dir:. -o cyclonedx-json > sbom.json

Esse arquivo pode ser armazenado junto com o artefato da aplicação.

Threat Modeling dentro do DevSecOps

Threat modeling é uma prática essencial para entender como uma aplicação pode ser atacada antes mesmo da implementação completa.

Em vez de apenas procurar vulnerabilidades depois, o time faz perguntas como:

Exemplo de fluxo:

usuário → API pública → autenticação → serviço interno → banco de dados

Nesse fluxo, o time pode mapear riscos como:

Threat modeling não precisa ser burocrático. Pode começar simples, com diagramas e perguntas objetivas durante o planejamento de uma feature.

DevSecOps e cultura

Um dos maiores erros é tratar DevSecOps apenas como instalação de ferramentas.

Ferramentas ajudam, mas não resolvem cultura ruim.

Uma cultura DevSecOps exige:

O objetivo não é transformar todo desenvolvedor em pentester. O objetivo é criar um ambiente onde decisões inseguras sejam detectadas cedo, corrigidas com clareza e evitadas no futuro.

A própria definição de DevSecOps da Red Hat reforça a ideia de cultura, automação e design de plataforma, não apenas ferramentas isoladas.

Métricas importantes em DevSecOps

Para saber se DevSecOps está funcionando, a organização precisa medir.

Algumas métricas úteis:

Exemplo prático de fluxo DevSecOps em uma API

Imagine uma equipe desenvolvendo uma API de autenticação.

Fluxo sem DevSecOps:

desenvolvedor cria endpoint → merge → deploy → pentest encontra falha → correção emergencial

Fluxo com DevSecOps:

planejamento → threat modeling → código → SAST → secret scanning → testes → SCA → build → container scan → DAST em staging → deploy controlado → monitoramento

Durante esse processo, a pipeline poderia identificar:

Cada problema seria encontrado antes ou logo após o deploy controlado, reduzindo risco de exposição real.

DevSecOps não substitui pentest

Uma dúvida comum é: se eu tenho DevSecOps, ainda preciso de pentest?

Sim. DevSecOps não substitui pentest, red team ou revisão especializada.

Ele reduz problemas recorrentes e automatizáveis, mas não elimina a necessidade de análise humana.

Ferramentas automatizadas são boas para encontrar padrões conhecidos. Já uma análise manual consegue entender lógica de negócio, abuso de fluxo, encadeamento de vulnerabilidades e impacto real.

Exemplos de falhas que geralmente exigem análise humana:

DevSecOps e Red Team defensivo

Em ambientes maduros, DevSecOps pode se conectar a práticas de red team defensivo e purple team.

A ideia não é colocar exploits perigosos na pipeline, mas transformar hipóteses de ataque em testes seguros e controlados.

Exemplo conceitual:

hipótese: endpoint administrativo não deve aceitar usuário comum

Teste automatizado seguro:

test("usuário comum não acessa endpoint admin", async () => { const response = await request(app) .get("/admin/users") .set("Authorization", "Bearer token_usuario_comum");
expect(response.status).toBe(403);
});

Outro exemplo:

hipótese: API deve bloquear payload com tentativa de path traversal

Teste defensivo:

test("bloqueia tentativa de path traversal", async () => { const response = await request(app) .get("/download?file=../../etc/passwd");
expect([400, 403]).toContain(response.status);
});

Esses testes não ensinam exploração ofensiva real contra terceiros. Eles validam se a aplicação resiste a classes comuns de abuso dentro do próprio ambiente controlado.

Benefícios do DevSecOps

Quando bem implementado, DevSecOps traz benefícios técnicos e operacionais importantes.

A proposta do DevSecOps está diretamente ligada a manter velocidade de entrega sem perder controle. O NIST NCCoE também descreve DevSecOps como uma união entre desenvolvimento seguro e operações para reduzir ciclos de desenvolvimento, manter agilidade e usar práticas modernas de cloud e segurança.

Como começar com DevSecOps

Uma empresa não precisa implementar tudo de uma vez. O caminho mais realista é começar pequeno e evoluir.

Uma ordem prática seria:

O ponto mais importante é criar feedback útil para o desenvolvedor. Se a ferramenta apenas acusa erro sem explicar o problema, a adoção será baixa.

Conclusão

DevSecOps é uma evolução natural do desenvolvimento moderno. Ele nasce da necessidade de entregar software rápido sem transformar a pipeline em uma fábrica de vulnerabilidades.

A ideia central é simples: segurança precisa fazer parte do ciclo de desenvolvimento desde o começo. Isso envolve cultura, automação, ferramentas, processos, métricas, governança e monitoramento contínuo.

Na prática, DevSecOps não é apenas rodar um scanner antes do deploy. É construir um fluxo onde cada etapa contribui para reduzir risco:

Organizações que implementam DevSecOps de forma madura conseguem reduzir vulnerabilidades, melhorar resposta a incidentes e entregar software com mais confiança.

Em um cenário onde aplicações dependem de cloud, APIs, containers, open source e automação, segurança não pode mais ser uma etapa separada. Ela precisa estar no fluxo.

NIST SSDF

OWASP DevSecOps Guideline

OWASP CI/CD Security Cheat Sheet

CISA Secure by Design

NIST NCCoE DevSecOps Practices

Red Hat — What is DevSecOps?

Escrito por

Daniel Felipe

Daniel Felipe é criador do NetCatTest e produz conteúdos sobre cibersegurança, privacidade digital, OSINT, laboratórios autorizados e ferramentas para estudo técnico responsável.

Perfil e publicações [email protected] YouTube GitHub LinkedIn