Você já entrou num projeto onde segurança só aparece na reunião de retrospectiva, depois que algo já deu errado? É o padrão mais comum que eu vejo: time trata segurança como item de checklist de fim de sprint, não como parte do design. O problema não é falta de ferramenta — hoje sobra scanner, sobra linter, sobra plugin de IDE. O problema é falta de estrutura pra saber que tipo de controle você está aplicando e em que momento ele faz sentido.
Existe uma forma simples de organizar isso, que vem de segurança da informação clássica e se aplica direto a desenvolvimento: todo controle de segurança cai em uma de três categorias — preventivo, detectivo ou corretivo. Entender essa divisão muda a forma como você prioriza o que implementar primeiro.
Controles preventivos: evitar que o problema exista
O objetivo aqui é simples — impedir que a vulnerabilidade chegue a existir ou a ser explorada. Na prática, os três pilares são:
- Padrões de código seguro: seguir convenções conhecidas evita reintroduzir os mesmos erros clássicos (injeção, validação fraca, exposição de dados sensível em log).
- Validação de entrada: todo dado que entra no seu sistema vindo de fora — formulário, API, upload — precisa ser tratado como hostil até prova em contrário.
- Autenticação robusta: MFA como padrão, não como opção que o usuário ativa se quiser.
Isso é o que mais reduz custo, porque bug que nunca existiu não precisa ser corrigido.
Controles detectivos: assumir que algo vai passar
Nenhuma prevenção é perfeita — isso não é pessimismo, é estatística. Por isso você precisa de uma segunda camada que detecta o que passou pela primeira:
- Sistemas de detecção de intrusão (IDS): monitoram tráfego e comportamento do sistema procurando padrão de ataque.
- Code review e auditoria: revisão manual e automatizada pega o que o preventivo não pegou — inclusive porque quem escreveu o código tem pontos cegos que outra pessoa não tem.
- Monitoramento contínuo: log sem alerta não serve pra nada. O ponto não é só guardar o dado, é ter alguém (ou algo) olhando pra ele em tempo hábil.
Controles corretivos: o que fazer quando já aconteceu
Aqui é resposta a incidente de verdade — não o “vamos ver depois”, mas um processo definido:
- Plano de resposta a incidente: quem aciona quem, em que ordem, com que autoridade pra tomar decisão sob pressão.
- Gestão de patch: manter dependências e runtime atualizados é chato e é, ainda assim, uma das formas mais eficazes de fechar vulnerabilidade conhecida.
- Retroalimentação: todo incidente que não vira aprendizado formal (o que falhou, por que passou pelo preventivo e pelo detectivo) é uma vulnerabilidade que você vai reencontrar.
Como isso se encaixa no ciclo de vida do projeto
Esse framework de três controles não é uma etapa isolada — ele precisa aparecer em cada fase:
Requisitos/Planejamento → definir objetivo de segurança + avaliação de risco
Design/Arquitetura → threat modeling + escolha de tecnologia segura
Codificação → SAST + code review focado em segurança
Testes → pentest + scan de vulnerabilidade
Operação/Manutenção → patch management + monitoramento contínuo
Se você já escreveu segurança em cada fase do SDLC comigo em outro artigo daqui, esse quadro é o complemento natural: aquele artigo fala de quando aplicar segurança, este fala de que tipo de controle você está de fato aplicando em cada momento.
DevSecOps é a automação disso, não outra coisa
Vale um esclarecimento rápido: DevSecOps não é um quarto tipo de controle — é a forma de automatizar e distribuir os três ao longo do pipeline de CI/CD, com testes e análises rodando a cada commit em vez de numa auditoria trimestral. Se você quer entender DevSecOps com mais profundidade, já escrevi sobre isso especificamente aqui.
Por onde começar, na prática
Se seu time não tem nenhum dos três estruturado hoje, comece pelo preventivo — é o que tem menor atrito de implementação e maior retorno imediato (validação de entrada e MFA você implementa em semanas, não em meses). Detectivo vem em seguida, porque sem visibilidade você não sabe se o preventivo está funcionando. Corretivo formal costuma ser o último a amadurecer, porque só fica óbvio que falta um plano de resposta quando você já precisou de um e não tinha.
Não existe atalho pra pular etapa aqui. Um time que só tem controle corretivo bem definido (resposta a incidente afiada) mas não tem preventivo nenhum vai viver apagando incêndio. Um time que só tem preventivo mas não detecta nada vive numa falsa sensação de segurança até o dia que descobre, tarde demais, que algo furou.
