Jean Pierre Lessa e Santos Ferreira conhece bem a diferença entre organizações que constroem segurança dentro dos seus sistemas e as que tentam adicioná-la depois. A segunda abordagem é mais comum do que deveria ser, e seu custo se manifesta de formas previsíveis: vulnerabilidades descobertas tarde, correções que exigem reescrita de componentes críticos e incidentes que poderiam ter sido evitados se a perspectiva de segurança tivesse entrado no projeto antes da primeira linha de código.
O conceito de segurança por design parte de uma premissa simples: é muito mais barato e eficaz considerar os requisitos de segurança durante o desenvolvimento do que remediar falhas em sistemas que já estão em produção. Essa premissa, embora amplamente aceita na teoria, ainda encontra resistência prática em ambientes onde a pressão por velocidade de entrega domina as decisões de curto prazo.
Threat modeling: o que muda quando o time começa a pensar como um atacante?
Uma das práticas mais eficazes da segurança por design é o threat modeling, processo pelo qual o time de desenvolvimento mapeia sistematicamente as ameaças potenciais a um sistema antes de implementá-lo. A ideia central é direta: identificar como um atacante poderia explorar o sistema permite projetar controles que tornem esse ataque mais difícil ou impossível desde o início, sem precisar corrigi-lo às pressas depois que o problema já está em produção.
O processo estruturado de threat modeling envolve etapas que precisam acontecer antes da implementação:
- Identificação e classificação de ativos, mapeando o que precisa ser protegido, qual o valor de cada ativo para o negócio e quais seriam as consequências de sua exposição ou comprometimento.
- Mapeamento de vetores de ataque e definição de controles, avaliando a probabilidade e o impacto de cada ameaça identificada para decidir quais mitigações são proporcionais ao risco real.
A incorporação dessa prática em times que historicamente não tinham esse repertório exige tanto capacitação técnica quanto uma mudança na forma de pensar sobre o ciclo de desenvolvimento. Jean Pierre Lessa e Santos Ferreira, como especialista em tecnologia, administra esse processo de transformação em equipes de engenharia que precisam desenvolver uma atitude de segurança sem perder o ritmo de entrega.
O pipeline de CI/CD como linha de defesa
Pipelines de integração e entrega contínua se tornaram infraestrutura padrão em times de engenharia modernos. O que ainda não é padrão em muitas organizações é o uso desse pipeline como mecanismo ativo de segurança. Ferramentas de análise estática de código, verificação de dependências com vulnerabilidades conhecidas, scanning de configurações de infraestrutura e testes de segurança automatizados podem ser integrados ao pipeline de forma que nenhum código chegue à produção sem passar por um conjunto mínimo de verificações.
Essa abordagem, conhecida como DevSecOps, muda fundamentalmente a relação entre os times de desenvolvimento e as práticas de segurança. Em vez de uma revisão de segurança pontual antes do lançamento, a verificação se torna contínua e automática. Jean Pierre Lessa e Santos Ferreira frisa a importância de estar familiarizado com os desafios de implementar esse modelo em organizações com pipelines já estabelecidos e times que precisam ser envolvidos na mudança sem ter seu ritmo de entrega comprometido.
De que forma a gestão de dependências influencia os riscos dos projetos e sistemas?
Um dos vetores de ataque que ganhou atenção crescente nos últimos anos é a exploração de vulnerabilidades em bibliotecas e dependências de código aberto. O ataque à cadeia de suprimentos de software, em que um componente amplamente utilizado é comprometido e distribui código malicioso para todos os projetos que dele dependem, deixou de ser cenário teórico depois de incidentes reais de grande impacto.
Gerenciar dependências com rigor significa mais do que manter versões atualizadas. Significa ter visibilidade completa sobre quais componentes externos fazem parte de cada sistema, avaliar a saúde e a manutenção ativa desses componentes e ter processos para responder rapidamente quando uma vulnerabilidade crítica é descoberta em algo que seu produto usa. Para Jean Pierre Lessa e Santos Ferreira, esse nível de controle sobre a cadeia de suprimentos de software é parte da postura de segurança que organizações maduras precisam desenvolver.
Segurança que não atrapalha é segurança que funciona
Um dos motivos pelos quais práticas de segurança são abandonadas ou contornadas em times de desenvolvimento é a fricção que introduzem no trabalho cotidiano. Processos de aprovação demorados, ferramentas que geram volumes impossíveis de falsos positivos e políticas que não distinguem entre riscos altos e baixos criam resistência legítima. A segurança eficaz é a que protege sem paralisar, integrando-se ao fluxo de trabalho de forma que a adesão seja natural.
A consolidação desse modelo de integração exige a convergência entre competência técnica e a dinâmica operacional das equipes de engenharia. Esse alinhamento estratégico é conduzido por Jean Pierre Lessa e Santos Ferreira na diretoria de tecnologia, com foco no balanceamento dos controles internos. O objetivo técnico é estabelecer diretrizes de segurança da informação rígidas o suficiente para a proteção dos ativos, mas viáveis para impedir o surgimento de caminhos alternativos de burla por parte dos desenvolvedores.
Autor: Diego Rodríguez Velázquez
