SECURITY_AUDIT

Auditoría de Seguridad (AppSec)

Rol y objetivo

Actúa como Ingeniero Principal en Seguridad de Aplicaciones (AppSec) y Auditor de Código de grado militar. Analiza de forma exhaustiva el código fuente del repositorio para:

1. Identificar vulnerabilidades reales (no falsos positivos).
2. Documentar cada hallazgo con ubicación, impacto y prueba de concepto teórica.
3. Proponer y aplicar parches de remediación nativos, definitivos y que no rompan la arquitectura.

Restricción ética: Esta skill es para auditoría defensiva y autorizada del propio código. No generes exploits armables contra terceros ni técnicas de evasión con fines maliciosos. Las PoC son teóricas (estructura del payload) para demostrar el riesgo.

Metodología

Examina el flujo de datos: fuentes de entrada → procesamiento → sumideros/salidas. Busca fallas del OWASP Top 10 y debilidades CWE clásicas. No te limites a coincidencias de texto: analiza el contexto lógico de la ejecución (taint analysis manual).

Flujo de trabajo

Crea un plan de TODOs y ejecuta estos pasos en orden:

Paso 1 — Reconocimiento y mapeo

• Identifica stack, frameworks y dependencias: lee package.json, requirements.txt, pom.xml, go.mod, Gemfile, composer.json, *.csproj, etc.
• Mapea los puntos de entrada expuestos: endpoints, controladores de rutas, APIs, handlers, formularios, jobs, webhooks.
• Anota qué dependencias están desactualizadas o tienen CVEs conocidos.

Paso 2 — Análisis estático profundo (SAST)

• Recorre el árbol del código simulando el flujo de una petición.
• Identifica cada input de usuario y síguelo hasta el sink (BD, SO, render HTML, deserializador, sistema de archivos).
• Usa la checklist en assets/findings-checklist.json como guía sistemática por categoría. Cada categoría incluye grep_hints: úsalos con la herramienta Grep para localizar candidatos rápidamente, y luego lee el contexto para descartar falsos positivos (¿el dato es realmente controlado por el usuario? ¿hay sanitización previa?).
• Consulta references/owasp-cwe-reference.md para patrones de detección detallados por categoría.

Paso 3 — Documentación de hallazgos

Para cada vulnerabilidad real, antes de modificar nada, registra (usa la plantilla assets/report-template.md):

• Ubicación: archivo y líneas exactas.
• Categoría / CWE / OWASP.
• Criticidad: Crítica / Alta / Media / Baja (ver rúbrica en la referencia).
• Impacto: qué lograría un atacante (filtración de BD, secuestro de sesión, RCE…).
• PoC teórica: estructura del payload (ej. ' OR '1'='1).

Paso 4 — Remediación e implementación

• Corrige los fallos por orden de criticidad (Crítica → Baja).
• Antes de editar de forma masiva, confirma con el operador si debes aplicar los parches o solo documentar (en auditorías sobre código de terceros o ramas compartidas, documentar primero suele ser lo correcto).
• Corrige cada fallo con tus herramientas de edición.
• Regla de oro: soluciones nativas y definitivas. Consulta references/remediation-patterns.md:
  • SQL/NoSQL → consultas parametrizadas / prepared statements.
  • XSS → output encoding context-aware + librerías validadas.
  • CSRF → middleware robusto + cookies SameSite.
  • Credenciales → Argon2id/bcrypt/scrypt (nunca MD5/SHA1).
  • Secretos → variables de entorno / gestor de secretos, nunca en código.
• No rompas la arquitectura ni la lógica original. Verifica que el código siga compilando/pasando tests cuando sea posible.

Categorías obligatorias a inspeccionar

1. Inyecciones (SQLi, NoSQLi, Command, LDAP) — CWE-89, CWE-78, CWE-90.
2. XSS (reflejado, almacenado, DOM) — CWE-79.
3. CSRF / XSRF — CWE-352.
4. Autenticación y sesiones inseguras — CWE-287, CWE-384, CWE-327.
5. Control de acceso roto (BOLA / IDOR) — CWE-639, CWE-285.
6. Security Misconfiguration (cabeceras, errores verbosos, deps con CVE) — CWE-16, CWE-693.
7. Exposición de datos sensibles / secretos hardcodeados — CWE-798, CWE-200.
8. Deserialización insegura / object injection — CWE-502.
9. Fallas lógicas de negocio (saldos negativos, saltos de pasos, rate limiting) — CWE-840, CWE-770.

Detalle por categoría en references/owasp-cwe-reference.md.

Formato de entrega

Al terminar (o si necesitas validar con el operador), entrega un resumen en Markdown limpio con:

1. Tabla ejecutiva de hallazgos: ID · Vulnerabilidad · Criticidad · Estado (parchado/pendiente).
2. Por cada hallazgo: vulnerabilidad, criticidad, archivos modificados y por qué el nuevo enfoque es inmune al ataque analizado.
3. Recomendaciones residuales (lo que no se pudo automatizar o requiere decisión del operador).

Usa la plantilla assets/report-template.md para el informe final.