Camadas de segurança no vibe coding: como encarecer a invasão

Uma camada de segurança serve para encarecer a entrada. Nenhuma fecha a porta em definitivo, e quem decide se vale a pena invadir o seu sistema é o invasor, fazendo a conta dele. Foi assim que danilixz explicou o assunto no Day 01 da CavernaCODING, sem abrir uma linha de código: falando de casa, grade e cerca elétrica.

A meta possível é ficar caro o bastante para a tentativa não compensar, porque impenetrável ninguém fica. Quem aceita isso para de perseguir uma garantia que não existe e passa a somar obstáculos, que é o trabalho que dá para fazer de verdade.

A casa com grade, alarme e o tiozinho da motinho

A cena começa com a lista do que se põe numa casa:

"Você precisa tornar mais difícil do gajo invadir a sua casa. Então você coloca a grade, coloca cerca elétrica, colocas alarme, colocas põe a máquina fotográfica, pagas o tiozinho da motinho para ele estar a apitar quando passa em frente da tua casa."

Nenhum item dessa lista, sozinho, impede alguém de entrar, e é aí que a metáfora fica boa: o efeito é somado, e nenhuma peça precisa dar conta do serviço inteira. Ele fecha o raciocínio sem prometer o que não pode cumprir:

"todas estas medidas de seguranças, não garantem que não vão invadir a [...] sua residência, mas garante que vai ter uma dificuldade maior na hora de invadir"

Daí em diante a decisão sai das suas mãos e passa para as de quem está do lado de fora olhando. Ele encena a hesitação do sujeito na calçada, que "vai analisar duas, três vezes", e depois o inventário:

"Opa. Ó, tem a vedação elétrica, tem uma grade, tem câmara, tem alarme, tem a câmara externa. Opa. Não, então vai sair demasiado caro eu tentar invadir esta residência."

A palavra que decide a cena é "caro". O sujeito vai embora por cálculo de custo, com a grade ainda inteira e o alarme sem tocar, e é esse o resultado que a soma das camadas produz.

Uma trava, outra trava ali

A passagem para software ele faz em uma frase:

"Aí trazes isso para o meio digital. Pois, é o mesmo conceito. Vai colocar aqui uma trava, outra trava ali"

E o desfecho, de novo na voz de quem está do lado de fora:

"É difícil entrar aqui no sistema do cara, vai ser caro."

"acaba por desistir de invadir o sistema"

A cena tem um limite que precisa ficar claro: nela ele não enumera camada técnica nenhuma, fala mesmo em "uma trava, outra trava ali". Os exemplos concretos que vêm agora são meus, e valem porque já estão documentados aqui em posts próprios.

Um deles é proteger lógica sensível no servidor: a regra de negócio fica fora do alcance de quem usa o produto, de forma que ler o que roda no navegador não entrega o que importa. Outro é segurança de painel admin, que trata de quem consegue chegar até a porta e do que essa pessoa pode fazer depois de passar por ela. Vale ver como isso terminou em vibe coding para fazer ia auditar seguranca do proprio sistema. O mesmo problema apareceu em access token mercado pago.

São camadas diferentes do mesmo sistema, e é exatamente esse o argumento. Uma cuida do que está guardado, a outra cuida de quem entra. Ter só a primeira é construir um cofre e deixar o portão aberto.

Por que isso pesa no vibe coding

No vibe coding o desequilíbrio é estrutural. O agente entrega funcionalidade rápido, e segurança não vem junto por padrão: cada trava é uma decisão que alguém precisa pedir. Ninguém escreve "faça a tela de cadastro" e recebe controle de acesso e segregação de dados no pacote.

Some a isso o critério que a gente usa para parar de trabalhar. "Está funcionando" descreve o caminho feliz, testado por você mesmo, clicando como um usuário bem-comportado. Estar protegido descreve todos os outros caminhos, testados por alguém que quer sair do trilho de propósito. Uma coisa e outra se medem de formas diferentes, e o vibe coding é rápido em produzir evidência da primeira e mudo sobre a segunda.

Em outro momento da mesma live ele ancora isso num exemplo histórico:

"Nada é tão seguro nesta vida"

"Os alemães acharam que a sua encriptação era inquebrável"

Confiaram na proteção que tinham como se fosse o fim da conversa, e pararam de somar camadas em cima dela.

Minha análise: 3 ressalvas à metáfora da casa

As ressalvas abaixo são minhas, escritas depois de assistir. Ele não disse nada disso.

A primeira é a mais importante, e é o limite da comparação. O ladrão da rua escolhe uma casa entre várias, então encarecer a sua manda o problema para a do lado. Um sistema exposto na internet é varrido de outro jeito: em escala, por ferramenta automática que não escolhe alvo e testa todo mundo porque testar sai barato. A conta do "não vale a pena" funciona bem contra ataque dirigido e funciona muito menos contra varredura, que nem olha a sua fachada antes de bater na porta.

A segunda: camada só conta se for independente. Grade, alarme e câmera ligados no mesmo portão com defeito são 1 camada, não 3. Em software, 3 conferências que confiam todas no mesmo dado de sessão são 1 conferência repetida, e quem quebra o dado passa pelas 3 de uma vez. O que separa uma coisa da outra é o que cada camada verifica por conta própria.

A terceira: camada cobra de você também. Cada uma custa manutenção, envelhece e pode barrar usuário legítimo. Quando a segurança atrapalha demais, quem trabalha ali dentro desliga, e o custo fica sem a proteção do lado.

O que fazer amanhã

Liste as camadas que o seu produto tem hoje. Ao lado de cada uma, escreva em uma frase o que ela para, com sujeito e objeto: quem ela impede de fazer o quê. Camada que você não consegue descrever assim provavelmente não está parando nada.

Depois vem a pergunta desconfortável: quais delas caem juntas se uma única coisa falhar. Se 3 linhas da sua lista somem ao mesmo tempo por causa de um único componente, você tem uma camada com 3 nomes, e a conta do invasor é bem mais barata do que parecia. Vale assistir à live e acompanhar a explicação da casa do começo ao fim antes de fazer a sua lista.