---

name: security-audit-codebase description: > 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. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: general complexity: intermediate language: multi tags: security, audit, owasp, secrets, vulnerability locale: es source_locale: en source_commit: 6a868d56 translator: Claude Opus 4.6 translation_date: 2026-03-13

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:

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

# Patrones genéricos de secretos
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}" .

# Cadenas de conexión
grep -rn "postgresql://\|mysql://\|mongodb://" .

# Claves privadas
grep -rn "BEGIN.*PRIVATE KEY" .

Esperado: No se encuentran secretos reales, solo marcadores de posición como YOUR_TOKEN_HERE o [email protected].

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:

# Verificar que estos están ignorados por git
git check-ignore .env .Renviron credentials.json node_modules/

# Buscar archivos sensibles rastreados
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:

npm audit
npx audit-ci --moderate

Python:

pip-audit
safety check

R:

# Verificar vulnerabilidades conocidas en paquetes
# No hay herramienta integrada, pero verificar las fuentes de los paquetes
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:

# Buscar concatenación de cadenas en consultas
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:

# Buscar ejecución de shell con entrada de usuario
grep -rn "system\(.*paste\|exec(\|spawn(" --include="*.{R,js,ts,py}" .

XSS (Cross-Site Scripting):

# Buscar contenido de usuario sin escapar en 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

# Modo debug en configuraciones de producción
grep -rn "debug\s*[=:]\s*[Tt]rue\|DEBUG\s*=\s*1" --include="*.{json,yml,yaml,toml,cfg}" .

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

# HTTP en lugar de 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:

# 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