Auditoria de segurança em um prompt: 47 checagens, sem ferramenta paga

TL;DR

• Aponte um agente de código para um único arquivo Markdown e ele audita um repositório — sem ferramenta paga, sem conta, sem framework.
• O catálogo tem 47 checagens de vulnerabilidade em quatro grupos: injeção, autenticação e sessão, cripto e infraestrutura, lógica e integridade.
• Toda fase grava o estado em audit-workspace/, então uma auditoria interrompida é retomável e auditável.
• O agente apresenta os achados e espera a sua decisão; correções são aplicadas só depois da aprovação e commitadas uma por uma, para poder reverter qualquer uma.

O que é e para quem

One Prompt Security Audit é um sistema de prompts, não um binário de scanner. O README o descreve como uma forma de transformar qualquer agente de código — Claude Code, Codex, Cursor e os demais — em auditor de segurança do seu código, usando só o que o agente já tem: leitura de arquivo, grep e git.

É para quem quer uma primeira passada real de segurança no repositório sem comprar ferramenta nem montar framework, e para quem já paga assinatura de agente e prefere usar isso. É uma primeira auditoria, não um pentest: nada no README afirma que ela substitui revisão humana de um sistema em produção.

O que ela faz

O catálogo é a substância. O README agrupa 47 checagens em quatro grupos de varredura:

Cada checagem combina uma busca no estilo grep com verificação semântica — e é por isso que um agente, e não uma lista de regex, faz o trabalho: o grep levanta candidatos, o agente decide se o candidato é defeito real. O catálogo completo, com orientação de detecção por item, está em VULNERABILITY_CATALOG.md.

Antes dos grupos roda um preflight de higiene de git: exposição de .env, segredo commitado no histórico e visibilidade do repositório. O último importa porque um repo que parece privado e é público já é o achado.

O fluxo orquestrado

O ponto de entrada é ORCHESTRATOR_PROMPT.md, que roda cinco etapas:

1. Fase 0 — preflight: higiene de git, exposição de .env, segredos no histórico, visibilidade do repo.
2. Fase 1 — ingestão: o agente mapeia o código e escreve um manifesto.
3. Fase 2 — grupos A/B/C/D: em paralelo quando o agente consegue abrir sub-agentes, sequencial caso contrário.
4. Fase 3 — merge e relatório: achados em linguagem simples e parada para a sua decisão.
5. Fase 4 — aplicar correções aprovadas: só as aprovadas, commitadas individualmente no git.

O diagrama do README deixa o portão explícito: o fluxo se divide na decisão do usuário, e o ramo "sem correções" termina a auditoria sem tocar no código. Cada fase grava a saída em audit-workspace/ — progress.json, repo-manifest.json, findings/GROUP-*.json, output/report.md — e é isso que deixa a execução retomável.

Como usar

O caminho mais curto é uma instrução para o agente:

Read ORCHESTRATOR_PROMPT.md and audit: [repo URL or local folder path]

Para o agente clonar o sistema sozinho:

Clone https://github.com/artificialguybr/one-prompt-security-audit, read its
ORCHESTRATOR_PROMPT.md, and audit: [your repo URL or local path]

Nada mais é necessário: o agente lê os arquivos de prompt e sabe o que fazer. O repositório também traz SCANNING_PROMPT.md com as instruções de varredura, REPORT_PROMPT.md para gerar o relatório, FIX_PROMPT.md para aplicar correções via git, SYSTEM_SPEC.md como referência de arquitetura, schema/ com os schemas JSON dos arquivos gerados e examples/ com saídas de exemplo.

Por que "sem correção sem permissão" é a regra interessante

A maior parte das ferramentas de segurança junta detecção e mudança, e é assim que uma varredura acaba reescrevendo código que você não pediu para tocar. Aqui a separação é explícita: a detecção produz relatório, e a fase de correção só roda depois que você aprova achados específicos. Commitar cada correção individualmente significa que uma correção ruim é um git revert de distância, não um bisect por um commit gigante.

Quando usar, quando não usar

Use antes de abrir um repositório ao público, antes de entregar um código para um terceiro, ou como primeira passada periódica num projeto que nunca teve revisão de segurança. Só o preflight já paga a execução se você já commitou um .env alguma vez.

Não trate a saída como pentest. O README é um prompt de revisão do seu próprio repositório e não diz nada sobre exploração em runtime, configuração de infraestrutura fora do repo ou a paciência de um atacante real. E não rode a fase de correção no escuro: leia os achados primeiro, porque o julgamento do agente sobre o que é defeito é justamente o que o portão de aprovação existe para filtrar.

Sources

1. One Prompt Security Audit — repositório — diagrama de arquitetura, tabela das 47 checagens, mapa de arquivos e as cinco fases citadas acima.
2. README.md — quick start, tabela de cobertura, lista de artefatos.

Página do projeto: One Prompt Security Audit

FAQ

Precisa de ferramenta paga ou conta? Não. O README afirma: sem ferramenta paga, sem conta e sem framework — o agente usa a leitura de arquivo, o grep e o git que já tem.

Quantas checagens ela roda? 47 checagens em quatro grupos — injeção, autenticação e sessão, cripto e infraestrutura, lógica e integridade — mais um preflight de higiene de git e segredos.

O agente mexe no código sozinho? Não. Ele apresenta os achados e espera a sua decisão; as correções só rodam depois da aprovação, e cada uma é commitada individualmente para poder ser revertida.

Uma auditoria interrompida pode ser retomada? Sim. Cada fase grava o estado em audit-workspace/: progresso, manifesto, achados por grupo e relatório.