SEGURIDAD POR DISEÑO: DIRECTRICES MAESTRAS Y MITIGACIÓN DE CWE
Este documento establece las directrices maestras para el desarrollo de software bajo un enfoque de "Seguridad por Diseño" (Secure by Design). En un panorama donde el volumen de código crece exponencialmente, es imperativo adoptar patrones que reduzcan el riesgo de forma temprana, antes de que las vulnerabilidades se vuelvan explotables en producción.
Enfoque: Secure by Design · Zero Trust en Código
Prohibido: Hardcoding de credenciales en repositorios
Entorno: Integración continua (SDLC) asistida por IA y contexto de nube.
// Explicación no técnica
Construir software sin pensar en seguridad es como fabricar un coche sin frenos y añadirlos después de que ya está en la calle. "Seguridad por Diseño" significa pensar en los frenos, el chasis y los airbags desde el primer boceto en papel, no como un parche añadido al final.
01. EL PLANO DEL DISEÑO SEGURO
La seguridad no comienza en el código, sino en la evaluación del entorno y la naturaleza de los datos. Antes de escribir lógica de negocio, se deben responder tres preguntas críticas:
1. Exposición de la Superficie: ¿La aplicación estará expuesta públicamente o restringida a tráfico interno? Los vectores de entrada se modelan en base a esto.
2. Sensibilidad de los Datos: ¿Procesará PII, PHI o datos financieros? Esto dicta niveles de cumplimiento.
3. Identidad y Propiedad: ¿Quién es el propietario del sistema y qué identidades están autorizadas para interactuar con él?
Seguridad en el Diseño de APIs: Uso mandatorio de OAuth 2.0 para terceros, JWT para autenticación stateless, e implementación obligatoria de MFA (Autenticación de Múltiples Factores) como defensa en profundidad.
Patrones de Resiliencia: Toda entrada debe considerarse maliciosa. Implementar Schema Enforcement (ej. JSON Schema), Rate Limiting para mitigar DoS, y Modos de Fallo Seguro (sanitizar logs y stack traces para prevenir CWE-209).
02. GESTIÓN CENTRALIZADA DE SECRETOS
Qeda estrictamente prohibido el uso de "hardcoding" para claves de API, certificados, contraseñas o cualquier credencial en el código fuente.
Las aplicaciones deben recuperar secretos de forma dinámica en tiempo de ejecución utilizando bóvedas especializadas. Se requiere el uso de AWS Secrets Manager o Azure Key Vault para centralizar la gestión, rotación y auditoría, garantizando que los secretos nunca residan en el sistema de control de versiones (Git).
03. VULNERABILIDADES DE INYECCIÓN (CWE TOP 25)
Las debilidades de inyección siguen siendo el vector de ataque más crítico. La mitigación requiere patrones de codificación estrictos.
| Nombre / CWE | Impacto | Estrategia de Mitigación |
|---|---|---|
| XSS (CWE-79) | Robo de sesiones, redirecciones. | Usar APIs de texto (textContent), no de HTML. |
| SQL Injection (CWE-89) | Acceso no autorizado a BD. | Consultas parametrizadas u ORMs. |
| Code Injection (CWE-94) | Ejecución de código arbitrario. | Evitar eval(), usar allow-lists. |
| Command Injection (CWE-77) | Control del sistema operativo. | Pasar argumentos como listas, sin shell. |
// Patrón Riesgoso:
document.getElementById("output").innerHTML = comment;
// Solución (Fix):
document.getElementById("output").textContent = comment;
# Patrón Riesgoso:
cursor.execute(f"SELECT * FROM users WHERE username = '{username}'")
# Solución (Fix):
cursor.execute(
"SELECT * FROM users WHERE username = %s",
(username,)
)
# Patrón Riesgoso:
subprocess.check_output(f"ping {host}", shell=True)
# Solución (Fix):
subprocess.check_output(["ping", host])
04. CONTROL DE ACCESO Y FLUJOS
Falta de Autorización (CWE-862): Ocurre cuando no hay verificación. Autorización Incorrecta (CWE-863): Cuando la verificación es burlada (ej. ver facturas ajenas).
Mitigación: Verificación estricta de Propiedad (*Ownership*) y Principio de Mínimo Privilegio.
Vulnerabilidades de Configuración Críticas:
- CWE-352 (CSRF): Tokens anti-CSRF por sesión y cookies `SameSite: Strict`. Los métodos GET jamás deben cambiar estado.
- CWE-918 (SSRF): Listas de permitidos. Bloquear explícitamente IPs internas y el IP de metadatos de la nube (169.254.169.254).
- CWE-22 (Path Traversal): Sanitizar rutas usando `os.path.basename()` para eliminar secuencias `../`.
- CWE-502 (Deserialización): Preferir JSON. Si se usa serialización nativa en Java, implementar validación "look-ahead".
05. CONTEXTO DE NUBE Y SAST ASISTIDO POR IA
El SAST tradicional genera "ruido" masivo al carecer de contexto de ejecución. La evolución (ej. enfoque Wiz) utiliza bases de datos orientadas a grafos (*Security Graph*) para realizar un code-to-cloud mapping, trazando el linaje: Código Fuente → CI Pipeline → Contenedor.
exploitability_criteria:
- CWE-94 se eleva a CRÍTICO si el contenedor usa privilegios elevados.
- CWE-89 es máxima prioridad si la carga está expuesta a Internet.
validation_layer:
- Wiz ASM simula comportamiento "outside-in" para confirmar explotabilidad real.
- Elimina falsos positivos dinámicos en SSRF y XSS.
A diferencia del emparejamiento de patrones, el agente de IA actual realiza análisis semántico. La remediación ocurre en el SDLC mediante comandos integrados en el IDE o Pull Requests (ej. `#wiz remediate`), aplicando parches automáticos adaptados a la arquitectura del proyecto y asignando el *ownership* al desarrollador correspondiente.
-- CONCLUSIÓN
Buscar vulnerabilidades en el código sin conocer la infraestructura donde se ejecuta es como buscar una aguja en un pajar a ciegas. La seguridad moderna exige que el análisis estático (SAST) entienda la nube, y que la IA no solo encuentre el error, sino que escriba la solución exacta en el contexto del desarrollador.
> SYSTEM_READY > NODE_ONLINE