Segurança não é uma feature. É um jeito de trabalhar.

Tem uma frase que aparece em quase toda proposta de software que eu leio: "segurança a gente trata depois". Esse "depois" tem data e tem preço, e quase nunca é quem prometeu que paga a conta. Por que segurança é hábito de time, não item de backlog, e como dá pra enxergar isso antes de assinar.

Por Raquel Reis

Raquel Reis

Eu leio proposta de desenvolvimento de software quase toda semana. Faz parte do meu trabalho aqui na Revin olhar o que o founder recebe de fornecedor antes de assinar. E tem uma frase que se repete tanto nesses documentos que virou quase piada interna. Aparece em fintech, em healthtech, em marketplace, não importa o setor. Sempre lá pelo meio da proposta, num tom calmo de quem está só organizando prioridade: "segurança a gente trata numa fase posterior".

Fase posterior soa de boa quando você está com pressa de lançar e o orçamento aperta. O problema é que esse "posterior" quase nunca vira uma data de verdade no calendário. Ele vira um item que desce no backlog toda sprint, empurrado por outra coisa que parece mais urgente. E quase tudo parece mais urgente que segurança, até o dia em que deixa de parecer.

Esse texto é pra quem vai contratar quem constrói o software e quer saber de antemão se segurança é algo que aquele time faz ou algo que ele só promete fazer. São coisas bem diferentes, e dá pra perceber a diferença antes de assinar.

Onde a segurança aparece, ou não aparece: menos numa cláusula do contrato, mais nas linhas que o time escreve todo dia.

O "depois" que nunca chega

Por que segurança é sempre o item mais fácil de adiar? Porque ela é invisível enquanto funciona. Ninguém abre o app de manhã e pensa "que bom, meus dados não vazaram hoje". Feature nova rende demo, rende print no Slack, rende elogio do board. Segurança bem feita não aparece em canto nenhum, até o dia em que a falta dela aparece em todos.

Tem também o incentivo do fornecedor, esse que ninguém comenta na reunião. Quem é pago por entrega visível otimiza por entrega visível. Um bodyshop que fatura por tela entregue não tem motivo pra gastar três dias revisando uma regra de acesso que o cliente nem sabe que existe. Não é má-fé. É o contrato dizendo o que importa, e segurança não estava escrita lá.

Já vi exceção, claro. Freelancer cuidadoso, que faz a coisa certa sem ninguém mandar, existe de sobra. Só que você não tem como saber qual é antes de contratar, e apostar a base de dados dos seus clientes num "vai que esse é dos bons" costuma sair caro.

Onde a falta aparece, e não é num ataque de cinema

Quando um sistema vaza, a história real quase nunca é a do filme. Raramente tem um hacker de capuz quebrando criptografia às três da manhã. O que tem é bem mais sem graça que isso.

No começo deste ano a Revin foi chamada pra revisar o código de um marketplace com uns 20 mil usuários ativos. Time enxuto, tinham construído tudo com dois freelancers e muita pressa. Em meio dia de leitura a gente encontrou o suspeito de sempre: a chave da API de pagamento escrita direto no código, em texto puro, num commit de 2023. Estava no histórico do Git, visível pra qualquer pessoa que clonasse o repositório. Ninguém tinha trocado porque ninguém lembrava que ela estava ali.

Esse tipo de buraco costuma morar em quatro lugares:

• Segredo no código: chave de API, senha de banco e token versionados em texto puro.
• Acesso que ninguém revoga: o freela saiu há oito meses e a credencial de produção dele segue viva.
• Permissão larga demais: todo mundo virou admin porque configurar perfil dava trabalho na época.
• Dependência parada no tempo: uma biblioteca com falha conhecida há dois anos que ninguém atualizou porque estava funcionando.

Nenhuma dessas precisa de um gênio do mal pra ser explorada. Precisa de um estagiário curioso, de um ex-fornecedor ressentido ou só de um dia de azar. E todas elas têm a mesma origem: apareceram porque ninguém no time tinha o hábito de procurar.

Achar isso cedo já é metade do trabalho. O Diagnostic Sprint nasceu mais ou menos disso: duas semanas, a gente abre o código na mesa e devolve um retrato honesto do que está exposto, enquanto consertar ainda custa pouco.

Segurança de verdade não vive num relatório anual. Vive na revisão de código que acontece antes do merge.

Segurança é code review, não auditoria

A diferença entre um time que tem segurança e um que apenas a promete não está numa ferramenta cara nem num certificado pendurado na parede. Está num hábito, e esse hábito é visível no fluxo de trabalho de quem você contratou.

Num squad sênior, segurança não é uma etapa que acontece no fim do projeto. É uma lente que fica ligada o tempo todo. Quando alguém abre um pull request, quem revisa não olha apenas se o código funciona. Olha se o endpoint novo confere permissão, se algum dado sensível está sendo gravado em log sem querer, se aquela consulta aceita um parâmetro que não deveria. Least privilege deixa de ser uma frase bonita num documento e vira o jeito padrão de criar acesso: nasce fechado e abre só o necessário.

É assim que funciona nos squads da Revin, e não por virtude especial nossa. É que sai mais barato mesmo. Revisar uma permissão dentro do pull request custa dez minutos de quem está de plantão no review. Descobrir a permissão errada depois que ela já vazou custa o cliente.

Isso não é a mesma coisa que caçar SOC 2

Aqui cabe uma ressalva, porque segurança como hábito vive sendo confundida com segurança como burocracia. Não são a mesma coisa. Você não precisa de SOC 2 no ano um, nem de pentest trimestral caríssimo, e definitivamente não de um CISO antes de ter product-market fit. Buscar compliance cedo demais costuma ser dinheiro jogado fora, e a gente já defendeu isso em por que uma startup no ano um não deveria caçar SOC 2.

Certificado é coisa que se compra pronta. Já o hábito vem do time: ou ele já trabalha assim, ou vai aprender no seu projeto, no seu prazo e com os seus dados. Quando já vem embutido em como as pessoas escrevem código, custa quase nada.

Então, da próxima vez que uma proposta cair na sua mão e seus olhos baterem naquela frase, "segurança a gente trata depois", desconfie do verbo. A pergunta que importa não é quando aquilo vai ser feito, e sim se aquele time já faz isso por padrão. Um time que trata segurança como hábito nem escreve a frase, porque pra ele não existe uma fase posterior: já está no jeito de trabalhar desde o primeiro commit. Quem promete pra depois está te avisando, com todas as letras, que o hábito não está ali. Dá pra contratar mesmo assim, mas pelo menos você ouviu o aviso.

No fim, segurança é menos sobre o que você compra e mais sobre quem você deixa entrar no seu código. Se quiser ver como um squad embarcado lida com isso no dia a dia, ou conhecer os outros vetores que aparecem quando IA entra no fluxo de trabalho, é só marcar uma conversa com a gente.