Por mais bem definido que seja o ciclo de desenvolvimento do seu software, tem uma coisa que a gente sistematicamente deixa passar pra trás: segurança. Ela vira uma etapa isolada, quase sempre no fim, quase sempre feita por outra equipe, quase sempre tarde demais. E o problema não é falta de vontade — é que ninguém para pra pensar onde, dentro do SDLC que você já usa, a segurança deveria entrar.
O que é o SDLC, rapidinho
SDLC é sigla de Software Development Life Cycle — o conjunto de etapas estruturado que define como o desenvolvimento do seu software vai funcionar, desde a concepção da ideia até a manutenção depois que o cliente já está usando e reportando bug. Ter essas etapas bem definidas existe por um motivo simples: organizar o planejamento, aumentar a qualidade do que você entrega, reduzir custo e risco do projeto, e garantir conformidade com regulamentações da área onde aquele software vai ser aplicado — um software de sistema contábil tem uma regulamentação, um software embarcado num sistema de transmissão DWDM tem outra completamente diferente.
As etapas clássicas são:
- Levantamento de requisitos — o que o software precisa fazer para atender a necessidade do cliente. Armazenar dado, autenticar usuário, acender um LED, acionar um motor, mexer um braço mecânico. Se não está especificado, não existe motivo pra implementar.
- Planejamento e design — a arquitetura: qual design pattern seguir, qual biblioteca usar em vez de reinventar a roda, qual banco de dados, qual mecanismo de autenticação.
- Desenvolvimento — a parte de transformar tudo isso em código.
- Testes — geralmente feito por uma pessoa terceira, testando como usuário real: inserindo dado que você não previu, clicando em botão fora de ordem. Pode ser manual ou automatizado, com um caderno de testes definido.
- Implantação e manutenção — colocar em produção no cliente e manter: corrigir bug que aparece, melhorar documentação, atender chamado.
Só que, na prática, segurança quase nunca tem um lugar reservado dentro dessas cinco etapas. Ela vira um apêndice.
Por que vale a pena integrar segurança em cada fase (e não só no fim)
Três benefícios concretos, sem enrolação:
- Identificar vulnerabilidade cedo custa muito menos que descobrir depois. Se você ou seu time acha uma vulnerabilidade lá na fase de requisitos ou de planejamento, você cria a mitigação ali mesmo. Descobrir a mesma vulnerabilidade depois que o cliente já está usando o software custa ordens de grandeza mais caro — em retrabalho, em reputação, às vezes em multa.
- Atender regulamentação de segurança traz credibilidade. Uma coisa é atender a regulamentação da área de aplicação do software. Outra, diferente, é atender regulamentação de segurança em si. Isso evita que seu cliente seja “pego de calça curta” — sofrendo sanção ou multa porque o software que você entregou não seguiu um requisito de segurança que já era conhecido.
- Aumenta a resistência a ataques comuns. SQL injection mal tratada, buffer overflow — são ataques pequenos, conhecidos, e evitáveis se você pensar neles enquanto constrói, não depois.
Segurança fase por fase
Aqui está o que efetivamente entra em cada etapa — não é teoria abstrata, é o que dá pra aplicar já no próximo sprint.
Levantamento de requisitos
- Identifique ameaças possíveis desde já: que tipo de ataque esse software provavelmente vai sofrer, dado o que ele faz e onde vai rodar?
- Garanta o princípio do menor privilégio já como requisito: só quem realmente precisa inserir dado no banco tem permissão de inserir; quem só precisa visualizar, só visualiza.
- Levante a regulamentação de segurança aplicável ao setor, não só a regulamentação funcional.
Planejamento e design
- Incorpore defesa em profundidade (defense in depth): construa camadas de segurança, de forma que se uma camada for quebrada, ainda existe outra atrás dela protegendo o sistema. Nunca aposte tudo em um único mecanismo de proteção.
Desenvolvimento
- Valide toda entrada de usuário. Antes de confiar num parâmetro de função, teste se ele está dentro do range esperado — se sua função espera um valor de 0 a 10 e alguém manda 11 ou -1, qual é o comportamento? Se você não testou isso, você não sabe, e isso é a origem clássica de buffer overflow.
- Mantenha bibliotecas e frameworks atualizados. Isso parece óbvio, mas é sistematicamente esquecido: fique de olho se alguma lib que seu software usa recebeu atualização de segurança e aplique o mais rápido possível.
Um exemplo direto de validação de parâmetro que costuma faltar:
def ajustar_volume(nivel: int) -> None:
if not (0 <= nivel <= 10):
raise ValueError(f"nivel fora do range esperado: {nivel}")
# resto da lógica
Sem essa checagem, nivel = -1 ou nivel = 999 entra na lógica sem ninguém questionar — e em sistemas embarcados isso vira comportamento indefinido de hardware, não só uma exceção bonitinha em Python.
Testes
- Faça teste manual e automatizado, sem diferença conceitual do que já se faz hoje pra funcionalidade.
- O ponto que costuma faltar: simule os ataques possíveis de propósito. Buffer overflow, SQL injection, e se for aplicação web, XSS (cross-site scripting). O time de teste precisa planejar isso como parte do caderno de testes, não como um extra.
Implantação e manutenção
- Tenha procedimentos claros de como a atualização vai ser feita se algo der errado. Se você atua com sistemas embarcados, por exemplo, trocar um bootloader tem impacto real — documente o que precisa ser feito.
- Tenha um plano de resposta rápida para quando o cliente reportar um incidente. A velocidade de resposta aqui é o que determina se o incidente vira um imprevisto administrável ou uma crise de confiança com o cliente.
Ferramentas que ajudam (sem inventar moda)
Não precisa reinventar nada aqui. Existem referências prontas:
- Um guia com as vulnerabilidades mais recorrentes em aplicações web no momento (a lista do OWASP Top 10, que vou detalhar num artigo específico aqui no blog).
- Uma lista mais ampla de fraquezas de software que causaram problema ao longo do tempo, pra você avaliar o que se aplica ao seu contexto.
- Padrões de compliance de segurança e modelos de maturidade de práticas de desenvolvimento seguro (o SAMM é o exemplo que também trato em outro artigo aqui).
O ponto central
Segurança integrada ao SDLC não é uma etapa nova que você adiciona no fim — é uma lente que você aplica em cada etapa que já existe. Requisito de segurança na hora de levantar requisito. Camada de defesa na hora de desenhar arquitetura. Validação de entrada na hora de codificar. Simulação de ataque na hora de testar. Plano de resposta na hora de manter. Nenhuma dessas coisas exige reescrever seu processo do zero — exige só parar de tratar segurança como problema de outra equipe, em outra hora.
Esse tema tem vídeo correspondente no canal do FortShield no YouTube, com a explicação completa de cada fase — vale assistir se você prefere ver isso sendo explicado do que ler. E se você quer ir mais fundo no assunto de teste de segurança (SAST, DAST) que aparece na fase de testes e desenvolvimento, esse assunto tem artigo próprio aqui no blog.
