security-audit

Sales de la revisión con un findings.json contrastado contra esquema, un ledger de cobertura y tres informes (REPORT.md, FINDINGS-DETAIL.md y NEEDS-VALIDATION.md) construidos a partir de registros que un agente distinto ha intentado desmentir. Los veredictos no se mezclan: confirmed exige traza de código y un resultado acotado; needs_validation deja un hecho sin resolver y sin severidad; rejected documenta al candidato desmentido.

El flujo recorre seis fases: reconocimiento de arquitectura, límites de confianza y superficies de entrada; caza guiada por cobertura con cazadores aislados y críticos de huecos; validación de cada candidato por un verificador fresco; salida estructurada; verificación independiente de las reclamaciones de código (con otro verificador si hay un reemplazo material); e informe neutro respecto al objetivo. Tras crear o actualizar el ledger se ejecuta validate-coverage-ledger.cjs; en las fases 4 y 5, validate-findings.cjs.

Alcance de la caza

• Clases para web, protocolos HTTP y autenticación, cliente/DOM, cadena de suministro y publicación.
• Memoria y binarios, IA/LLM, nube y despliegue, RPC y mensajería, agotamiento de recursos, aislamiento de datos e IPC local o apps nativas.

Varias pasadas sobre el mismo repositorio se suman: reutilizas ledgers y hallazgos previos para atacar huecos, revalidar código que ha cambiado y no dar por cubierto lo obsoleto o lo pendiente. Lo instalas con Skills CLI y lo activas pidiendo una auditoría; en modo completo, si no fijas carpeta, escribe en ~/security-audit-skill/<repo>/run-N y solo toca el repo si eliges un directorio ignorado por el control de versiones. Necesitas un agente con herramientas y subagentes en paralelo, Node.js para los validadores y un sandbox del SO sin red externa para builds, tests, fuzzers y similares.