Teste de segurança mostra evidências; o revisor decide

seguranca

Quando um agente altera código ligado a login ou ao que o usuário digita, quero uma lista de segurança à mão. Também quero a lista quando ele altera verificações automáticas. Só nessa hora. Deixar tudo carregado em cada sessão ocupa espaço nas informações que o modelo consegue usar. Na maioria das vezes, o trabalho nem toca em segurança.

Cinco listas para consultar quando necessário

Uso cinco skills (conjuntos de instruções para orientar uma tarefa).

• A security-review procura falhas no código. Ela segue recomendações da OWASP (organização que publica orientações de segurança).
• A owasp-audit-zap relaciona achados ao OWASP Top 10 (lista de dez riscos comuns). Também roda testes com ZAP (ferramenta para procurar falhas) em três modos: baseline (varredura rápida), full e autenticado (com login).
• A injection-prevention cobre quatro riscos: SQL injection, XSS, injeção de comando e SSRF. SQL injection altera uma consulta ao banco. XSS exibe código malicioso no navegador. Injeção de comando faz o servidor executar uma ação. SSRF leva o sistema a acessar outro endereço. A skill cobre FastAPI e React (ferramentas para criar sistemas e interfaces).
• A secrets-management usa gitleaks e trufflehog (ferramentas que procuram segredos expostos). Também cuida da troca de segredos e da resposta a incidentes.
• A gha-security-review verifica como alguém poderia explorar um processo automático do GitHub Actions.

Cada lista entra quando o trabalho toca a área que ela cobre. Mexeu numa consulta ao banco, entra a injection-prevention. Mexeu numa verificação automática, entra a gha-security-review. Essas instruções não ficam na memória do agente entre tarefas.

Escolher quando carregar uma lista também faz parte do trabalho. Um PR é um pedido para revisar e incluir mudanças no código. Usar owasp-audit-zap num PR que só troca o texto de um botão gasta contexto sem necessidade. Deixar de usar gha-security-review num PR que altera um processo automático aceita o risco sem conferir.

Uma skill não revisa por mim. Ela lembra o agente do que olhar enquanto escreve o código. Isso já muda bastante o que aparece no PR. Um scanner testa o sistema automaticamente. Ele atua depois, quando o código já está no PR. Nem a skill nem o scanner aprovam o PR.

O scanner mostra evidências

A ADR-061 (registro de uma decisão de arquitetura) foi aceita em 5 de setembro. Ela diz que o DAST fornece evidências para o revisor. DAST é um teste de segurança num sistema em funcionamento. Ele não dá o veredito. Um teste do strix roda a cada PR, e uma varredura baseline do ZAP roda toda noite. O revisor continua decidindo. O plano desse processo passou por um conselho de revisão em 5 rodadas, que encontrou 80 problemas.

Também foi definida uma regra de fail-closed: se a própria ferramenta de teste quebra ou nem roda, isso não conta como aprovação. Um teste que nunca começou também não mostra alertas. Tratar essa ausência como aprovação confundiria um teste limpo com um teste que não aconteceu.

A divisão é simples. O scanner mostra o que encontrou. O revisor lê esses resultados junto com as mudanças do PR e decide se o pedido passa. Se o scanner pudesse aprovar, eu estaria confiando num número sem saber o que ele verificou.

Um alerta pode estar errado. Um PR sem alertas ainda pode ter um problema que o teste não alcança. Nos dois casos, alguém precisa ler o resultado com contexto (as informações do projeto). Esse trabalho é do revisor.

O dia em que um modelo inventou o processo inteiro

A instrução de despacho levou só o título da tarefa ao modelo de código. Isso ocorreu em 5 de setembro, mesmo dia da ADR. O modelo completou o resto e escreveu do zero um arquivo .github/workflows/dast.yml. Dois PRs foram fechados.

Com um título e nenhuma especificação, o modelo fez o que costuma fazer: completou as partes que faltavam. A correção foi na ferramenta que distribui as tarefas. A instrução precisa levar a especificação, não só o título. Na minha opinião, um processo inteiro que ninguém pediu é pior que um erro. O erro chama atenção; o processo pode parecer legítimo.

Segredos, sem entrar em detalhes

Os agentes não leem arquivos .env. Qualquer comando que precise de um segredo passa por um intermediário local separado, o CIPHER. Ele executa o comando sem imprimir a credencial. Só eu posso revelar um segredo. Não entro em mais detalhes de propósito.