Vibe coding para achar o buraco na infra e não só no app

O app pode estar bem contido e o buraco estar na infra. Endurecer só o código deixa aberto o lado que o documento já apontou.

Danilix chega nesse ponto depois de mostrar o harness, numa live de 631 min da Caverna Coding. Ele entra na parte de segurança e o primeiro movimento é separar os ambientes do sistema. O que está na tela é um documento de blindagem do SaaS. A conclusão está escrita e ele lê: o app está bem contido; o buraco está na infra.

Separar ambientes começa na documentação de blindagem

Ele nomeia o que trava a sessão:

Ó, agora preciso, preciso de resolver uma paragem porque eu estou a separar os ambientes, tá ligado? do meu sistema que comecei a fazer a minha parte de segurança.

A paragem é o começo da segurança. Separar ambientes entra agora, no instante em que ele corta o sistema em lados. Enquanto os ambientes estão misturados, o app pode parecer seguro e o furo continuar onde o código não alcança.

Ele aponta para um arquivo que já escreveu.

Só fiz aqui, ó, blindagem do SAS, não é? Assim, o APS está está bem contido, o buraco está na infra, entendeu?

SAS, no narrador, é o SaaS. APS é o app. A frase dele é o diagnóstico desta cena. O código da aplicação está contido; o que ainda fura mora na infra, e a live usa essa palavra e para nela. Ele entrega a camada em que vai trabalhar.

A documentação cobre o que precisa resolver e como resolver: é documentação de implementação.

Isto aqui, ó, é uma documentação que eu fiz do que é que eu preciso de resolver, está ligado?

O vibe coding acha o buraco na camada da infra

Colar o código do app e pedir auditoria manda a IA trabalhar no que recebeu. Ela devolve correção de aplicação, você aplica, o app fica mais duro e o buraco na infra fica onde estava.

O vibe coding desta cena começa pelo documento de blindagem. Danilix pede o diagnóstico em documento, lê o resultado e aceita o que o documento disse. O app já está contido. O próximo trabalho é a infra, e a separação de ambientes que impede o furo de um ambiente de valer pelo outro. O mesmo problema apareceu em vibe coding para checar se painel admin esta exposto direto na internet.

Na mesma live ele já tinha o recorte de esperar a quebra de tela quando a segurança entra. Aquele post é o efeito colateral: a tela que funcionava quebra. Este é o mapa do furo. São 2 cortes do mesmo dia, cada um com a sua busca.

O irmão sobre camadas de segurança ensina a encarecer a invasão. Lá você empilha custo para quem ataca. Aqui o passo vem antes: descobrir em qual camada o buraco está, para a sessão não ir inteira para o lado que o documento já deu como contido.

O prompt "faz a segurança" escolhe o app por reflexo

Ele recusa o atalho:

Eu não não digo assim: "Ah, faz a segurança, faço uma documentação.

Mandar "faz a segurança" no chat deixa a IA escolher o terreno. Ela conhece o código do app. O documento de blindagem impõe a ordem do mapa antes da implementação: o que precisa resolver e a melhor forma de resolver.

Numa sessão de 631 min, um diagnóstico que vive só no chat some. O arquivo de blindagem ainda está aberto quando ele volta a separar ambientes. A live não descreve o desenho desses ambientes, só o ato de separar. Você leva o ato e a conclusão.

Endurecer o app de novo, depois dessa frase, é repetir o lado que já está contido. O trabalho que sobra é achar o buraco na infra e não só no app.

O mapa que você escreve antes de endurecer o app de novo

Amanhã, antes de pedir mais código de segurança, peça o mapa por escrito, com o lugar em que o app já está contido e o lugar em que o buraco ainda está. O documento precisa dizer o que fazer e como fazer. Sem o arquivo, a IA volta para o repositório porque é o que ela tem na frente.

Peça à IA um documento de blindagem do seu SaaS antes de qualquer diff. Se a resposta for a mesma que a dele, o próximo trabalho é a infra e a separação de ambientes. O vibe coding útil nesta hora aceita o diagnóstico e muda de camada.

Dá para assistir à live e ouvir ele ler a blindagem do SaaS em voz alta.