Como menciona o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, a segurança de software tem um problema de timing que é ao mesmo tempo bem compreendido e sistematicamente ignorado. O custo de corrigir uma vulnerabilidade de segurança cresce exponencialmente à medida que ela avança no ciclo de desenvolvimento: é barato corrigir na fase de design, moderadamente caro corrigir durante o desenvolvimento, significativamente mais caro corrigir em testes, e extremamente caro corrigir em produção, especialmente depois que foi explorada. Esse dado é amplamente conhecido e raramente muda o comportamento de organizações que continuam tratando segurança como atividade de pentest pré-release em vez de disciplina integrada ao ciclo de desenvolvimento.
Se você é desenvolvedor que nunca recebeu treinamento formal em segurança de software, ou lidera um time que trata segurança como responsabilidade exclusiva do time de infosec, este artigo oferece perspectiva e práticas concretas para mudar essa dinâmica de forma que beneficie tanto a qualidade do produto quanto a velocidade de entrega.
Por que a abordagem de segurança como verificação final persiste e quais são os custos reais dessa persistência?
De acordo com Jean Pierre Lessa e Santos Ferreira, a segurança como verificação final persiste por razões que são racionais a nível individual e irracionais a nível organizacional. Para o desenvolvedor individual, a segurança que não é cobrada durante o desenvolvimento não é incentivada pelo processo que avalia o seu trabalho. Se a velocidade de entrega de funcionalidades é o que gera reconhecimento, e se vulnerabilidades introduzidas durante o desenvolvimento raramente são atribuídas ao desenvolvedor que as criou porque são descobertas muito depois, o incentivo natural é otimizar para o que é medido. Esse desalinhamento de incentivos, e não a falta de consciência sobre a importância da segurança, é o principal mecanismo que mantém a segurança fora do fluxo de desenvolvimento cotidiano.
O custo da correção tardia de vulnerabilidades de segurança é bem documentado, mas raramente é apresentado de forma que torne as consequências concretas para quem toma decisões de alocação de recursos. Uma vulnerabilidade de injeção de SQL identificada em revisão de código durante o desenvolvimento leva minutos para ser corrigida. A mesma vulnerabilidade descoberta em pentest antes do release leva horas, incluindo o ciclo de reporte, triagem, correção e revalidação. Descoberta em produção após exploração, o custo inclui contenção do incidente, análise forense, notificação de usuários afetados, comunicação de crise, potenciais multas regulatórias e o impacto reputacional que não tem valor facilmente calculável mas que é real e duradouro. Tornar essa progressão de custo visível e concreta é frequentemente o que muda a disposição de lideranças para investir em segurança integrada ao desenvolvimento, comenta o diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira.
Quais práticas de shift left em segurança produzem redução real de vulnerabilidades sem comprometer a velocidade de entrega?
Segundo Jean Pierre Lessa e Santos Ferreira, a modelagem de ameaças é a prática de maior impacto e menor adoção em times de desenvolvimento que buscam segurança integrada. Realizada durante a fase de design de uma nova funcionalidade ou sistema, a modelagem de ameaças é o processo estruturado de identificar quais ativos precisam ser protegidos, quais atores mal-intencionados poderiam querer comprometê-los, quais vetores de ataque esses atores poderiam usar e quais controles de segurança precisam estar presentes no design para mitigar esses riscos. Esse exercício, que pode ser realizado em sessões de uma a duas horas com o time de desenvolvimento, tem o poder de eliminar classes inteiras de vulnerabilidades antes que uma linha de código seja escrita, o que é a forma mais eficiente possível de segurança.
A implementação de verificações de segurança automatizadas no pipeline de integração contínua é a prática de shift left com a melhor relação entre esforço de implementação e cobertura de vulnerabilidades comuns. Análise estática de código com foco em vulnerabilidades de segurança, verificação de dependências contra bases de vulnerabilidades conhecidas e testes de segurança básicos automatizados que rodam a cada pull request fornecem feedback imediato ao desenvolvedor sobre problemas de segurança introduzidos no código que está sendo commitado. Esse feedback imediato é o que fecha o ciclo de aprendizado que transforma segurança de auditoria periódica em parte do fluxo cotidiano de desenvolvimento.
Conforme Jean Pierre Lessa e Santos Ferreira, o treinamento em segurança de software específico para desenvolvedores, com foco em vulnerabilidades relevantes para as tecnologias e domínios com os quais o time trabalha, é o componente de habilitação que multiplica o efeito de todas as outras práticas. Desenvolvedores que entendem como vulnerabilidades comuns, como injeção de SQL, cross-site scripting, deserialização insegura e controle de acesso inadequado, funcionam na prática, e que sabem reconhecer os padrões de código que as introduzem, não dependem de ferramentas de análise estática para evitá-las: as evitam por conhecimento, o que é mais rápido e mais confiável do que qualquer processo de verificação automatizado.
Como times de desenvolvimento podem construir a capacidade de pensar em segurança como parte do trabalho cotidiano de engenharia?
A integração de critérios de segurança no processo de definição de pronto de histórias de usuário é um passo organizacional que muda o que o time considera necessário para declarar uma funcionalidade completa. Quando as histórias de usuário incluem explicitamente critérios de aceitação relacionados à segurança, como autenticação e autorização adequadas, proteção de dados sensíveis e resistência a inputs maliciosos, a segurança deixa de ser uma verificação adicional e passa a ser parte da definição de trabalho bem feito. Essa mudança de processo, simples na implementação, tem impacto significativo no comportamento do time porque muda o que é necessário para fechar uma história.
A criação de um campeão de segurança dentro do time de desenvolvimento é uma prática adotada por times que querem construir capacidade interna sem depender exclusivamente de expertise externa. O campeão de segurança não precisa ser um especialista em todos os aspectos de segurança de software: precisa ser um desenvolvedor com interesse na área que mantém conhecimento atualizado sobre vulnerabilidades relevantes para o contexto do time, facilita as sessões de modelagem de ameaças, revisa pull requests com atenção especial a aspectos de segurança e serve como ponto de contato entre o time de desenvolvimento e o time de segurança da organização. Como destaca Jean Pierre Lessa e Santos Ferreira, esse papel, quando rotacionado entre membros do time, tem o benefício adicional de distribuir o conhecimento de segurança de forma que não cria dependência de uma única pessoa.
A celebração de vulnerabilidades encontradas internamente antes de chegarem à produção é um comportamento de liderança que parece contraintuitivo, mas que é altamente eficaz para construir uma cultura em que segurança é responsabilidade compartilhada. Quando um desenvolvedor encontra e corrige uma vulnerabilidade durante o desenvolvimento, e esse achado é reconhecido positivamente pela liderança técnica, o comportamento é reforçado de forma que incentiva outros membros do time a adotar a mesma atitude proativa. Esse reforço positivo contrasta com a dinâmica mais comum em que vulnerabilidades encontradas internamente são tratadas com a mesma urgência e o mesmo sentido de crise que as encontradas externamente, criando um desincentivo perverso para que problemas sejam identificados e reportados de forma proativa.
Autor: Diego Rodríguez Velázquez