# Security Audit Codebase

> Realizar una auditoría de seguridad del código verificando secretos expuestos, dependencias vulnerables, vulnerabilidades de inyección, configuraciones inseguras y problemas del OWASP Top 10. Utilizar antes de publicar o desplegar un proyecto, para revisiones de seguridad periódicas, después de agregar autenticación o integración con API, antes de hacer público un repositorio privado, o al prepararse para una auditoría de cumplimiento de seguridad.

- Skill: `pjt222/security-audit-codebase-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pjt222/security-audit-codebase-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pjt222/security-audit-codebase-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: pjt222 (https://skillmd.com/u/pjt222)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/pjt222/security-audit-codebase-2

---


# Auditoría de Seguridad del Código

Realizar una revisión de seguridad sistemática del código para identificar vulnerabilidades y secretos expuestos.

## Cuándo Usar

- Antes de publicar o desplegar un proyecto
- Revisión de seguridad periódica de proyectos existentes
- Después de agregar autenticación, integración con API o manejo de entrada de usuario
- Antes de hacer público un repositorio privado
- Al prepararse para una auditoría de cumplimiento de seguridad

## Entradas

- **Requerido**: Código a auditar
- **Opcional**: Área de enfoque específica (secretos, dependencias, inyección, autenticación)
- **Opcional**: Marco de cumplimiento (OWASP, ISO 27001, SOC 2)
- **Opcional**: Hallazgos de auditorías anteriores para comparación

## Procedimiento

### Paso 1: Buscar Secretos Expuestos

Buscar patrones que indiquen secretos codificados directamente:

```bash
# API keys and tokens
grep -rn "sk-\|ghp_\|gho_\|github_pat_\|hf_\|AKIA" --include="*.{md,js,ts,py,R,json,yml,yaml}" .

# Generic secret patterns
grep -rn "password\s*=\s*['\"]" --include="*.{js,ts,py,R,json}" .
grep -rn "api[_-]key\s*[=:]\s*['\"]" --include="*.{js,ts,py,R,json}" .
grep -rn "secret\s*[=:]\s*['\"]" --include="*.{js,ts,py,R,json}" .

# Connection strings
grep -rn "postgresql://\|mysql://\|mongodb://" .

# Private keys
grep -rn "BEGIN.*PRIVATE KEY" .
```

**Esperado:** No se encuentran secretos reales, solo marcadores de posición como `YOUR_TOKEN_HERE` o `your.email@example.com`.

**En caso de fallo:** Si se encuentran secretos reales, eliminarlos inmediatamente, rotar la credencial expuesta y limpiar el historial de git con `git filter-branch` o `git-filter-repo`. Tratar cualquier secreto expuesto como comprometido.

### Paso 2: Verificar la Cobertura de .gitignore

Verificar que los archivos sensibles estén excluidos:

```bash
# Check that these are git-ignored
git check-ignore .env .Renviron credentials.json node_modules/

# Look for tracked sensitive files
git ls-files | grep -i "\.env\|\.renviron\|credentials\|secret"
```

**Esperado:** Todos los archivos sensibles (`.env`, `.Renviron`, `credentials.json`) están listados en `.gitignore`, y `git ls-files` no devuelve archivos sensibles rastreados.

**En caso de fallo:** Si hay archivos sensibles rastreados, ejecutar `git rm --cached <file>` para dejar de rastrearlos, agregar a `.gitignore` y confirmar. El archivo permanece en disco pero ya no está bajo control de versiones.

### Paso 3: Auditar Dependencias

**Node.js**:

```bash
npm audit
npx audit-ci --moderate
```

**Python**:

```bash
pip-audit
safety check
```

**R**:

```r
# Check for known vulnerabilities in packages
# No built-in tool, but verify package sources
renv::status()
```

**Esperado:** No hay vulnerabilidades altas o críticas en las dependencias. Las vulnerabilidades moderadas y bajas están documentadas para revisión.

**En caso de fallo:** Si se encuentran vulnerabilidades críticas, actualizar los paquetes afectados inmediatamente con `npm audit fix` o `pip install --upgrade`. Si las actualizaciones introducen cambios incompatibles, documentar la vulnerabilidad y crear un plan de remediación.

### Paso 4: Verificar Vulnerabilidades de Inyección

**Inyección SQL**:

```bash
# Look for string concatenation in queries
grep -rn "paste.*SELECT\|paste.*INSERT\|paste.*UPDATE\|paste.*DELETE" --include="*.R" .
grep -rn "query.*\+.*\|query.*\$\{" --include="*.{js,ts}" .
```

Todas las consultas a bases de datos deben usar consultas parametrizadas, no concatenación de cadenas.

**Inyección de Comandos**:

```bash
# Look for shell execution with user input
grep -rn "system\(.*paste\|exec(\|spawn(" --include="*.{R,js,ts,py}" .
```

**XSS (Cross-Site Scripting)**:

```bash
# Look for unescaped user content in HTML
grep -rn "innerHTML\|dangerouslySetInnerHTML\|v-html" --include="*.{js,ts,jsx,tsx,vue}" .
```

**Esperado:** No se encuentran vectores de inyección SQL, de comandos ni XSS. Todas las consultas a bases de datos usan sentencias parametrizadas, los comandos de shell evitan entrada controlada por el usuario, y la salida HTML está correctamente escapada.

**En caso de fallo:** Si se encuentran vulnerabilidades de inyección, reemplazar la concatenación de cadenas en consultas con consultas parametrizadas, sanitizar o escapar la entrada del usuario antes de la ejecución en shell, y usar métodos de renderizado seguros del framework en lugar de `innerHTML` o `dangerouslySetInnerHTML`.

### Paso 5: Revisar Autenticación y Autorización

Lista de verificación:
- [ ] Contraseñas hasheadas con bcrypt/argon2 (no MD5/SHA1)
- [ ] Tokens de sesión son aleatorios y suficientemente largos
- [ ] Tokens de autenticación tienen expiración
- [ ] Los endpoints de API verifican autorización
- [ ] CORS configurado de forma restrictiva
- [ ] Protección CSRF habilitada para operaciones que modifican estado

**Esperado:** Todos los elementos de la lista pasan: las contraseñas usan hash fuerte, los tokens son aleatorios con expiración, los endpoints aplican autorización, CORS es restrictivo y la protección CSRF está activa.

**En caso de fallo:** Priorizar las correcciones por severidad: hash de contraseñas débil y autorización faltante son críticos, mientras que los problemas de CORS y CSRF son altos. Documentar todos los hallazgos con su nivel de severidad.

### Paso 6: Verificar Seguridad de la Configuración

```bash
# Debug mode in production configs
grep -rn "debug\s*[=:]\s*[Tt]rue\|DEBUG\s*=\s*1" --include="*.{json,yml,yaml,toml,cfg}" .

# Permissive CORS
grep -rn "Access-Control-Allow-Origin.*\*\|cors.*origin.*\*" --include="*.{js,ts}" .

# HTTP instead of HTTPS
grep -rn "http://" --include="*.{js,ts,py,R}" . | grep -v "localhost\|127.0.0.1\|http://"
```

**Esperado:** El modo debug está deshabilitado en configuraciones de producción, CORS no usa orígenes comodín en producción, y todas las URLs externas usan HTTPS.

**En caso de fallo:** Si el modo debug está habilitado en configuraciones de producción, deshabilitarlo inmediatamente. Reemplazar orígenes CORS comodín con dominios permitidos explícitos. Actualizar URLs `http://` a `https://` donde el endpoint lo soporte.

### Paso 7: Documentar los Hallazgos

Crear un informe de auditoría:

```markdown
# Security Audit Report

**Date**: YYYY-MM-DD
**Auditor**: [Name]
**Scope**: [Repository/Project]
**Status**: [PASS/FAIL/CONDITIONAL]

## Findings Summary

| Category | Status | Details |
|----------|--------|---------|
| Exposed secrets | PASS | No secrets found |
| .gitignore | PASS | Sensitive files excluded |
| Dependencies | WARN | 2 moderate vulnerabilities |
| Injection | PASS | Parameterized queries used |
| Auth/AuthZ | N/A | No authentication in scope |
| Configuration | PASS | Debug mode disabled |

## Detailed Findings

### Finding 1: [Title]
- **Severity**: Low / Medium / High / Critical
- **Location**: `path/to/file:line`
- **Description**: What was found
- **Recommendation**: How to fix
- **Status**: Open / Resolved

## Recommendations
1. Update dependencies to fix moderate vulnerabilities
2. [Additional recommendations]
```

**Esperado:** Un `SECURITY_AUDIT_REPORT.md` completo guardado en la raíz del proyecto con hallazgos categorizados por severidad, cada uno con ubicación específica, descripción y recomendación.

**En caso de fallo:** Si hay demasiados hallazgos para documentar individualmente, agrupar por categoría y priorizar los hallazgos críticos/altos. Generar el informe independientemente del resultado para establecer una línea base.

## Validación

- [ ] No hay secretos codificados directamente en el código fuente
- [ ] .gitignore cubre todos los archivos sensibles
- [ ] No hay vulnerabilidades altas/críticas en dependencias
- [ ] No hay vulnerabilidades de inyección
- [ ] La autenticación está correctamente implementada (si aplica)
- [ ] El informe de auditoría está completo y los hallazgos están atendidos

## Errores Comunes

- **Solo verificar archivos actuales**: Los secretos en el historial de git siguen estando expuestos. Verificar con `git log -p --all -S 'secret_pattern'`.
- **Ignorar dependencias de desarrollo**: Las dependencias de desarrollo también pueden introducir riesgos en la cadena de suministro.
- **Falsa sensación de seguridad por `.gitignore`**: `.gitignore` solo previene el rastreo futuro. Los archivos ya confirmados necesitan `git rm --cached`.
- **Pasar por alto archivos de configuración**: `docker-compose.yml`, configuraciones de CI y scripts de despliegue frecuentemente contienen secretos.
- **No rotar credenciales comprometidas**: Encontrar y eliminar un secreto no es suficiente. La credencial debe ser revocada y regenerada.

## Habilidades Relacionadas

- `configure-git-repository` - configuración adecuada de .gitignore
- `write-claude-md` - documentar requisitos de seguridad
- `setup-gxp-r-project` - seguridad en entornos regulados