# SECURITY_AUDIT

> Auditoría de Seguridad (AppSec)

- Skill: `nazahack/security-audit` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add nazahack/security-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nazahack/security-audit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: NazaHack (https://skillmd.com/u/nazahack)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/nazahack/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](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](assets/report-template.md) para el informe final.