DevSecOps: o que é e como aplicar segurança no pipeline

No modelo tradicional, o time de segurança entra no fim do projeto.

A aplicação já está pronta, o deploy marcado, e a auditoria encontra uma injeção de SQL ou uma credencial exposta no repositório.

Corrigir nesse ponto custa caro: refazer código, atrasar entrega, refazer testes.

O DevSecOps muda o momento da verificação, não a quantidade de trabalho.

A ideia central é que segurança seja responsabilidade compartilhada entre desenvolvimento, operações e o time de segurança, com verificações automatizadas rodando dentro do pipeline.

Em vez de um portão manual no final, o pipeline executa análise de código, varredura de dependências e testes de configuração a cada commit.

O termo aparece em materiais da IBM, Red Hat, Microsoft e CrowdStrike com a mesma definição de base: DevSecOps é a extensão do DevOps para incluir segurança como parte do fluxo, e não como etapa separada. ## Os quatro pilares na prática Materiais como o da Fcamara organizam DevSecOps em quatro pilares.

Vale entender cada um pelo que ele muda no dia a dia. **Cultura e responsabilidade compartilhada.** Segurança deixa de ser assunto exclusivo do time de segurança.

Desenvolvedores recebem treinamento para reconhecer falhas comuns, como validação de entrada e gestão de segredos.

O time de segurança passa a escrever políticas automatizáveis, não relatórios. **Automação no pipeline.** Ferramentas de análise estática (SAST), análise de composição de software (SCA) e análise dinâmica (DAST) rodam como etapas do CI/CD.

O desenvolvedor recebe o resultado no mesmo lugar onde vê o resultado dos testes unitários. **Infraestrutura como código segura.** Se o ambiente é descrito em Terraform, Kubernetes ou Ansible, a configuração também precisa ser verificada.

Um bucket S3 público ou um security group aberto para 0.0.0.0/0 são falhas de infraestrutura, não de aplicação. **Monitoramento contínuo.** Segurança não termina no deploy.

Logs, alertas e detecção de anomalias em produção fecham o ciclo e alimentam o próximo desenvolvimento. ## Onde cada verificação entra no pipeline A pergunta prática é: qual ferramenta roda em qual etapa?

A resposta depende do tipo de falha que cada uma detecta melhor.

1. **No commit e no pull request.** Análise estática (SAST) lê o código sem executá-lo e aponta padrões inseguros.

Análise de composição (SCA) verifica bibliotecas de terceiros contra bases de vulnerabilidades conhecidas, como o NVD.

Verificação de segredos impede que chaves de API e senhas entrem no repositório.

2. **No build.** Assinatura e verificação de integridade de artefatos.

Scan da imagem de container antes de publicá-la no registry.

Uma imagem com biblioteca desatualizada é bloqueada aqui, não em produção.

3. **No ambiente de teste.** Análise dinâmica (DAST) ataca a aplicação em execução, simulando um invasor.

Testes de segurança de API verificam autenticação, autorização e exposição de dados.

4. **Antes do deploy em produção.** Verificação de configuração de infraestrutura como código.

Checagem de políticas (policy as code) que barram mudanças fora do padrão aprovado.

5. **Depois do deploy.** Monitoramento de runtime, detecção de comportamento anômalo e resposta a incidentes.

O ponto de decisão mais delicado é o que bloqueia o pipeline e o que apenas gera alerta.

Bloquear tudo no primeiro dia paralisa o time.

A prática comum é começar com modo de observação, medir quantas falhas aparecem e só então tornar obrigatórias as verificações mais críticas. ## Checklist de implementação Este roteiro serve para times que estão começando ou reorganizando o pipeline. - Mapeie o fluxo atual de CI/CD e identifique onde cada etapa roda hoje. - Escolha uma verificação para começar.

SCA costuma ser a mais rápida de implantar e a que encontra mais problemas reais, porque a maioria do código moderno depende de bibliotecas de terceiros. - Rode a ferramenta em modo de observação por algumas semanas e registre os achados. - Defina critérios de bloqueio com o time, não para o time.

Exemplo: vulnerabilidade crítica com correção disponível bloqueia; vulnerabilidade sem correção vira tarefa acompanhada. - Treine desenvolvedores nos tipos de falha que a ferramenta mais aponta. - Automatize a gestão de segredos com um cofre, em vez de variáveis de ambiente espalhadas. - Verifique a configuração de infraestrutura como código antes do apply. - Estabeleça um ciclo de revisão das políticas.

Regra que ninguém entende é regra que alguém vai burlar. - Meça o tempo entre detecção e correção.

Esse número mostra se o programa está funcionando. ## O erro mais comum O erro mais comum não é escolher a ferramenta errada.

É tratar DevSecOps como projeto de ferramenta.

Times instalam um scanner, geram centenas de alertas, ninguém triagem, e em três meses a ferramenta está desligada.

O que sustenta o programa é o processo de triagem.

Alguém precisa olhar os achados, classificá-los por risco real e transformá-los em trabalho planejado.

Sem isso, a automação só produz ruído.

O segundo erro é medir sucesso pelo número de vulnerabilidades encontradas.

Encontrar mais falhas não é sinal de pipeline melhor.

O indicador que importa é o tempo entre a detecção e a correção, e a redução de falhas que chegam a produção. ## O que muda para o time de segurança Em uma operação DevSecOps madura, o time de segurança escreve políticas, mantém as ferramentas e faz revisão de arquitetura.

Ele não revisa cada pull request manualmente.

Essa mudança é desconfortável para profissionais acostumados a aprovar ou reprovar entregas, mas é o que permite escalar.

A Microsoft descreve DevSecOps dentro do guarda-chuva de segurança de negócios, com ênfase em automação e integração contínua.

A Red Hat posiciona o tema como evolução natural do DevOps.

A leitura conjunta desses materiais aponta para a mesma direção: segurança vira código, política e automação, e deixa de ser documento. ## Perguntas frequentes **DevSecOps substitui o time de segurança?** Não.

Ele redistribui responsabilidades.

O time de segurança define políticas, mantém ferramentas e atua em revisão de arquitetura e resposta a incidentes.

A execução das verificações passa a ser automatizada no pipeline. **Qual ferramenta usar para começar?** Depende do tipo de falha mais provável no seu sistema.

Para aplicações que dependem de muitas bibliotecas de terceiros, análise de composição de software (SCA) costuma trazer resultado mais rápido.

Para código próprio com regras de negócio complexas, análise estática (SAST) tende a ser mais útil.

Não existe escolha única que sirva para todos os casos. **DevSecOps atrasa as entregas?** Pode atrasar no início, enquanto o time ajusta critérios e aprende a interpretar os resultados.

O ganho aparece depois, quando falhas são corrigidas no commit em vez de em produção.

O custo de correção cresce conforme a falha avança no ciclo, e é isso que a automação no pipeline evita.