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

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:

# 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