O que o pentest me ensinou sobre escrever código melhor

Durante oito meses dividi meu tempo entre segurança ofensiva na RNP, fazendo emulação de adversário e avaliação de vulnerabilidades, e desenvolvimento full stack na Bridge Laboratory, entregando features em React, TypeScript, Kotlin e Spring Boot. Esses dois trabalhos normalmente não cabem na mesma cabeça. Eles mudaram como escrevo código.

Pentest treina um hábito específico: antes de tocar em um sistema, perguntar onde um atacante ganha vantagem. Não "essa feature funciona", mas "o que acontece se essa entrada vier malformada, esse token for reutilizado, esse endpoint for chamado sem autenticação". Essa pergunta não desaparece quando você troca de quebrar sistemas para construí-los.

O ponto mais claro que carreguei foi validação de entrada. Depois de tempo suficiente encontrando pontos de injeção e checagens de autenticação quebradas em sistemas de outras pessoas, parei de tratar validação como formalidade nos meus próprios pull requests. Todo endpoint recebe a mesma pergunta de um engajamento de pentest: qual é a pior entrada possível para esse parâmetro, e o código sobrevive a ela.

Higiene de dependências é o segundo hábito. Avaliações de vulnerabilidade gastam tempo real com pacotes desatualizados com CVEs conhecidas, porque essa costuma ser a porta de entrada real, não algum zero day sofisticado. Rodar npm audit ou equivalente antes de um release deixou de ser checklist e virou hábito.

Autenticação e gestão de sessão também ganham mais atenção. Trabalhar com Kali Linux e ferramentas de emulação de adversário torna replay de token, fixação de sessão e escalação de privilégio modos de falha concretos, não itens abstratos de uma lista OWASP. A pergunta na revisão de código muda de "o login funciona" para "o que acontece se esse token for reutilizado depois do logout".

A tensão é real, porém. Desenvolvimento otimiza para entregar; segurança otimiza para reduzir superfície de ataque. Uma mentalidade de pentest pode travar um time se toda decisão for tratada como incidente. O hábito que realmente vale a pena carregar não é paranoia, é fazer a pergunta do atacante cedo, na fase de design, quando corrigir não custa nada, em vez de depois que a feature já está no ar.

Construir este portfólio e o sistema de blog foi um teste pequeno para isso. Os dados ficam no Supabase atrás de row level security, o CMS do blog valida e sanitiza cada campo antes de chegar ao banco, e upload de imagem passa por um bucket de storage escopado em vez de escrita arbitrária de arquivo. Nada disso é exótico. É o mesmo checklist que um engajamento de pentest roda, aplicado enquanto o código ainda está sendo escrito, em vez de depois que alguém tenta quebrar.

Programação full stack e segurança ofensiva sempre voltam para a mesma pergunta: o que eu pensei que não está de fato garantido. Responder isso mais cedo custa menos que responder durante um incidente.