O modelo tradicional e os seus custos
No modelo clássico de desenvolvimento de software, a segurança era domínio de uma equipa especializada que testava o sistema imediatamente antes da implementação em produção. As vulnerabilidades encontradas geravam desvios dispendiosos — os programadores tinham de regressar a tarefas há muito encerradas, compreender o contexto de semanas anteriores e introduzir alterações que perturbavam outros elementos já testados. A frustração era mútua: a equipa de segurança era vista como bloqueio, os programadores como despreparados para escrever código seguro.
A filosofia shift-left
Shift-left significa literalmente deslocar as atividades de segurança para a esquerda no eixo temporal do projeto — da fase de testes e implementação para a fase de design e codificação. Quanto mais cedo uma vulnerabilidade for detetada, mais barato e simples é corrigi-la. Um programador que vê um alerta de vulnerabilidade no seu ambiente de desenvolvimento segundos após escrever código problemático corrige-o imediatamente, sem perda de contexto e sem interromper o fluxo de trabalho de toda a equipa.
Automação no pipeline CI/CD
O shift-left concretiza-se através da incorporação de controlos de segurança automáticos em cada etapa do pipeline de integração e entrega contínuas. Cada commit de código inicia uma sequência de verificações de segurança que bloqueia a passagem à etapa seguinte em caso de deteção de vulnerabilidades graves.
- SAST (análise estática de código) — deteta vulnerabilidades no código-fonte sem o executar: injeções SQL, desserializações inseguras, utilização de funções perigosas
- SCA (análise de composição de software) — analisa dependências quanto a vulnerabilidades conhecidas, verifica licenças, deteta bibliotecas desatualizadas
- Scanning de segredos — bloqueia o commit acidental de passwords, chaves API e certificados no repositório
- DAST (análise dinâmica) — testa a aplicação em execução num ambiente de teste, simulando ataques a interfaces API e web
- Testes de contentores e infraestrutura — verificação da configuração de imagens Docker e definições de infraestrutura quanto a erros de segurança
Segurança como código
Organizações maduras tratam as políticas de segurança como código — definem-nas em ficheiros de configuração armazenados no repositório, submetidos a revisão e testes. Isto significa que as regras WAF, políticas de rede, configurações de sistemas de deteção de anomalias e políticas RBAC são geridas com o mesmo rigor que o código da aplicação. As alterações requerem revisão, o histórico é auditável, o rollback é possível em minutos.
Cultura como fundamento
Ferramentas sem cultura não produzem resultados. O DevSecOps requer que os programadores compreendam as consequências das decisões de design para a segurança e encarem os alertas não como obstáculos mas como feedback valioso. Isto significa investimento em formação, disponibilidade de especialistas de segurança como parceiros no design (não auditores), métricas claras e responsabilidade partilhada pelas vulnerabilidades. A ESKOM.AI aplica o modelo DevSecOps no desenvolvimento dos seus próprios sistemas, combinando a automação de testes com uma cultura de responsabilidade partilhada pela segurança em cada fase do ciclo de desenvolvimento.