Auditoría de seguridad en un prompt: 47 comprobaciones, sin herramientas de pago

TL;DR

• Apunta un agente de código a un único archivo Markdown y audita un repositorio — sin herramienta de pago, sin cuenta, sin framework.
• El catálogo tiene 47 comprobaciones de vulnerabilidad en cuatro grupos: inyección, autenticación y sesión, cripto e infraestructura, lógica e integridad.
• Cada fase escribe su estado en audit-workspace/, así que una auditoría interrumpida es reanudable y auditable.
• El agente presenta los hallazgos y espera tu decisión; las correcciones se aplican solo tras la aprobación y se confirman una por una para poder revertir cualquiera.

Qué es y para quién

One Prompt Security Audit es un sistema de prompts, no un binario de escaneo. El README lo describe como una forma de convertir cualquier agente de código — Claude Code, Codex, Cursor y los demás — en auditor de seguridad de tu código, usando solo lo que el agente ya tiene: lectura de archivos, grep y git.

Es para quien quiere una primera pasada real de seguridad en el repositorio sin comprar herramienta ni montar framework, y para quien ya paga una suscripción de agente y prefiere usarla. Es una primera auditoría, no un pentest: nada en el README afirma que sustituya una revisión humana de un sistema en producción.

Qué hace

El catálogo es la sustancia. El README agrupa 47 comprobaciones en cuatro grupos de escaneo:

Cada comprobación combina una búsqueda tipo grep con verificación semántica — y por eso la hace un agente y no una lista de regex: el grep levanta candidatos, el agente decide si el candidato es un defecto real. El catálogo completo, con orientación de detección por ítem, está en VULNERABILITY_CATALOG.md.

Antes de los grupos corre un preflight de higiene de git: exposición de .env, secreto confirmado en el historial y visibilidad del repositorio. Lo último importa porque un repo que parece privado y es público ya es el hallazgo.

El flujo orquestado

El punto de entrada es ORCHESTRATOR_PROMPT.md, que ejecuta cinco etapas:

1. Fase 0 — preflight: higiene de git, exposición de .env, secretos en el historial, visibilidad del repo.
2. Fase 1 — ingesta: el agente mapea el código y escribe un manifiesto.
3. Fase 2 — grupos A/B/C/D: en paralelo cuando el agente puede abrir subagentes, secuencial si no.
4. Fase 3 — merge y reporte: hallazgos en lenguaje sencillo y parada para tu decisión.
5. Fase 4 — aplicar correcciones aprobadas: solo las aprobadas, confirmadas individualmente en git.

El diagrama del README hace explícita la puerta: el flujo se bifurca en la decisión del usuario, y la rama "sin correcciones" termina la auditoría sin tocar el código. Cada fase escribe su salida en audit-workspace/ — progress.json, repo-manifest.json, findings/GROUP-*.json, output/report.md — y eso es lo que deja la ejecución reanudable.

Cómo usarlo

El camino más corto es una instrucción al agente:

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

Para que el agente clone el sistema por su cuenta:

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

No hace falta nada más: el agente lee los archivos de prompt y sabe qué hacer. El repositorio también trae SCANNING_PROMPT.md con las instrucciones de escaneo, REPORT_PROMPT.md para generar el reporte, FIX_PROMPT.md para aplicar correcciones vía git, SYSTEM_SPEC.md como referencia de arquitectura, schema/ con los esquemas JSON de los archivos generados y examples/ con salidas de ejemplo.

Por qué "sin corrección sin permiso" es la regla interesante

La mayoría de las herramientas de seguridad mezclan detección y cambio, y así es como un escaneo acaba reescribiendo código que no pediste tocar. Aquí la separación es explícita: la detección produce un reporte, y la fase de corrección solo corre después de que apruebas hallazgos concretos. Confirmar cada corrección por separado significa que una corrección mala está a un git revert, no a un bisect por un commit gigante.

Cuándo usarlo, cuándo no

Úsalo antes de abrir un repositorio al público, antes de entregar un código a un tercero, o como primera pasada periódica en un proyecto que nunca tuvo revisión de seguridad. Solo el preflight ya paga la ejecución si alguna vez confirmaste un .env.

No trates la salida como un pentest. El README es un prompt de revisión de tu propio repositorio y no dice nada sobre explotación en runtime, configuración de infraestructura fuera del repo ni la paciencia de un atacante real. Y no ejecutes la fase de corrección a ciegas: lee primero los hallazgos, porque el juicio del agente sobre qué es un defecto es justamente lo que la puerta de aprobación existe para filtrar.

Sources

1. One Prompt Security Audit — repositorio — diagrama de arquitectura, tabla de las 47 comprobaciones, mapa de archivos y las cinco fases citadas arriba.
2. README.md — quick start, tabla de cobertura, lista de artefactos.

Página del proyecto: One Prompt Security Audit

FAQ

¿Necesita herramienta de pago o cuenta? No. El README afirma: sin herramienta de pago, sin cuenta y sin framework — el agente usa la lectura de archivos, el grep y el git que ya tiene.

¿Cuántas comprobaciones ejecuta? 47 comprobaciones en cuatro grupos — inyección, autenticación y sesión, cripto e infraestructura, lógica e integridad — más un preflight de higiene de git y secretos.

¿El agente cambia el código solo? No. Presenta los hallazgos y espera tu decisión; las correcciones solo corren tras la aprobación, y cada una se confirma individualmente para poder revertirla.

¿Se puede reanudar una auditoría interrumpida? Sí. Cada fase escribe su estado en audit-workspace/: progreso, manifiesto, hallazgos por grupo y reporte.