Neste artigo
Coding agent tem pontos cegos previsíveis de segurança, e por serem previsíveis eles viram lista em vez de memória. Antes de qualquer SaaS meu receber o primeiro cliente pagante, eu passo por dez itens fixos. Nenhum deles é sofisticado, e é justamente por isso que passam batido.
Por que checklist e não revisão geral?
Revisão geral depende de estar descansado e de lembrar. Checklist não. Os erros que eu encontro em código gerado são quase sempre os mesmos dez, na mesma proporção, projeto após projeto.
Isso não é defeito do agente, é consequência de como o pedido costuma ser feito: ninguém escreve “e não commite o segredo”, então ele resolve o problema que foi pedido e ignora o que não foi.
Quais são os dez itens?
1. Segredo fora do código. Procurar chave, token e senha em todo o histórico, não só nos arquivos atuais. Segredo commitado e depois removido continua no histórico do Git e precisa ser rotacionado, não só apagado.
2. Isolamento entre tenants com teste negativo executado. O item mais importante da lista. Detalhado em autenticação e autorização em SaaS multi-tenant.
3. Rate limit no que é caro ou sensível. Login, recuperação de senha, envio de e-mail, qualquer rota que chame LLM. Sem isso, uma pessoa com um script derruba a conta ou o orçamento.
4. Upload validado por conteúdo, não por extensão. Checar tipo real, limitar tamanho, e servir de um domínio ou caminho que não execute nada.
5. Webhook com assinatura verificada. Endpoint de webhook é público. Sem verificar a assinatura do provedor, qualquer um posta um evento de “pagamento aprovado”.
6. Log sem dado pessoal. O agente loga o objeto inteiro quando dá erro, e o objeto inteiro costuma ter e-mail, documento e às vezes token. Isso vaza em qualquer ferramenta de log e ainda é problema de LGPD.
7. Erro que não conta a estrutura interna. Stack trace na resposta em produção entrega versão de biblioteca e caminho de arquivo. Resposta genérica para fora, detalhe no log interno.
8. Dependência conferida. Rodar auditoria do gerenciador de pacotes e olhar o que o agente instalou. Já peguei biblioteca abandonada há anos escolhida porque aparecia muito no treino.
9. Cabeçalhos de segurança e CORS fechado. CORS com origem liberada para tudo é o padrão que o agente escreve para o erro sumir durante o desenvolvimento, e que ninguém lembra de fechar.
10. Backup testado com restauração real. Backup que nunca foi restaurado não é backup, é esperança. Restaurar uma vez, em ambiente separado, antes do primeiro cliente.
O que costuma estar errado, em ordem de frequência?
| Item | Frequência que eu encontro | Gravidade |
|---|---|---|
| CORS aberto | Muito alta | Média |
| Log com dado pessoal | Muito alta | Alta |
| Sem rate limit | Alta | Alta |
| Webhook sem assinatura | Alta | Crítica |
| Falha de isolamento entre tenants | Média | Crítica |
| Segredo no histórico do Git | Média | Crítica |
| Upload validado só por extensão | Média | Alta |
Como rodar isso sem virar burocracia?
O checklist mora no repositório e vira tarefa antes de qualquer deploy que estreia recurso sensível. Eu peço ao agente para percorrer item por item e mostrar o trecho de código que atende cada um, não para dizer que atende.
Percorra o checklist de seguranca do repositorio.
Para CADA item, responda:
- atende? sim, nao, ou nao se aplica
- o arquivo e a linha que comprova
- se nao atende, o menor patch que resolve
Nao altere nada. Se nao encontrar a evidencia, diga que nao
encontrou, nao presuma que esta implementado.A última frase evita a resposta simpática e inútil de “sim, está tudo certo”. Sem pedir evidência, é isso que vem.
O que não é escopo desse checklist?
Isso é higiene de aplicação, não substitui teste de invasão nem revisão de quem faz segurança em tempo integral. Para SaaS que trata dado sensível de verdade, o checklist é o piso, não o teto.
Perguntas frequentes
O agente não deveria já fazer isso sozinho?
Ele faz quando está no pedido. O padrão dele é resolver o problema descrito e não expandir escopo, o que aliás é o comportamento certo. Se segurança não está no pedido, não entra.
Dá pra automatizar?
Boa parte sim: auditoria de dependência, varredura de segredo e teste de isolamento cabem no CI. Os que dependem de contexto, como log com dado pessoal, continuam sendo leitura.
Em que momento rodar?
Antes do primeiro cliente pagante, e depois a cada recurso que mexa em dado, pagamento ou permissão. O caminho até produção está em deploy de SaaS multi-tenant.
