POL-005: Política de SDLC Seguro y Gestión de Cambios

Campo	Valor
ID	POL-005
Versión	1.0
Clasificación	Interno — Confidencial
Fecha de Emisión	2026-03-13
Próxima Revisión	2027-03-13
Propietario	CISO / Líder de Desarrollo
PCI DSS	Requisito 6
Preguntas ControlCase	Q35, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q1030

1. Propósito

Definir el ciclo de vida de desarrollo de software seguro (Secure SDLC) y el proceso de gestión de cambios para todas las aplicaciones que almacenan, procesan o transmiten datos de tarjetas.

2. Ciclo de Vida de Desarrollo Seguro

2.1 Fases del SDLC

Requisitos → Diseño → Desarrollo → Pruebas → Despliegue → Operación → Decomiso
    │           │          │           │          │           │           │
    ▼           ▼          ▼           ▼          ▼           ▼           ▼
 Análisis    Threat    Coding     SAST/DAST   Change     Monitoring   Secure
 de riesgo   Model    Standards   Security    Mgmt       & Logging    Wipe
                                  Testing     Process

2.2 Requisitos de Seguridad por Fase

Fase	Actividad de Seguridad	Responsable
Requisitos	Identificar requisitos de seguridad, clasificación de datos	Product Owner + Seguridad
Diseño	Threat modeling, revisión de arquitectura	Arquitecto + Seguridad
Desarrollo	Codificación segura, peer review	Desarrolladores
Pruebas	SAST, DAST, pruebas de seguridad	QA + Seguridad
Despliegue	Gestión de cambios, verificación pre-producción	DevOps + Seguridad
Operación	Monitoreo, gestión de vulnerabilidades	DevOps

3. Estándares de Codificación Segura

3.1 Vulnerabilidades a Prevenir (OWASP Top 10)

Vulnerabilidad	Control Implementado	Evidencia
Injection (SQL, NoSQL, OS)	Parameterized queries, ORM (TypeORM), DTOs con class-validator	Código fuente
Broken Authentication	JWT RS256, MFA, Argon2id, account lockout	auth-service
Sensitive Data Exposure	Tokenización, AES-256-GCM, TLS 1.2+, masking de PAN	tokenization-service
XXE	Parser JSON (no XML), si XML: deshabilitación de external entities	Configuración
Broken Access Control	RLS, RBAC, JWT claims validation	DB policies, guards
Security Misconfiguration	Hardening de imágenes, no defaults, security headers	Dockerfiles, Kong
XSS	Output encoding, CSP headers, X-XSS-Protection	Kong headers
Insecure Deserialization	Validación estricta de DTOs, no eval()	class-validator
Using Components with Known Vulnerabilities	npm audit, Trivy, Snyk en CI/CD	ci.yml pipeline
Insufficient Logging	Structured logging, audit triggers	packages/logging

3.2 Prácticas Prohibidas

eval() o ejecución dinámica de código
Contraseñas o secretos hardcodeados en código fuente
Queries SQL construidas por concatenación de strings
Almacenamiento de PAN/CVV/SAD fuera del vault
Commits directos a main sin PR
Despliegue sin aprobación

4. Revisión de Código

4.1 Revisión Obligatoria

Todo código que toca el CDE (tokenization-service, card-vault-service, auth-service) requiere:

Requisito	Detalle
Revisor	Al menos 1 persona diferente al autor
Calificación del revisor	Experiencia demostrable en seguridad de aplicaciones
Herramienta	GitHub Pull Request con review aprobado
Alcance	Vulnerabilidades de seguridad comunes (OWASP), lógica de negocio, manejo de datos sensibles
Aprobación	Review aprobado requerido antes de merge a main

4.2 SAST Automatizado

Herramienta: npm audit + ESLint security rules en CI/CD
Frecuencia: Cada push / PR
Pipeline: .github/workflows/ci.yml
Los hallazgos de severidad HIGH o CRITICAL bloquean el merge

4.3 Registros de Revisión

Historial de PRs en GitHub con comentarios de revisión
Informe de code review con: fecha, revisor, hallazgos, resolución

5. Separación de Entornos

5.1 Entornos

Entorno	Propósito	Datos	Acceso
Desarrollo (local)	Codificación y unit tests	Datos sintéticos	Desarrolladores
CI (GitHub Actions)	Tests automatizados	Datos generados por fixtures	Automatizado
Staging	Pruebas de integración	Datos sintéticos	Dev + QA
Producción	Operación real	Datos reales	DevOps (restringido)

5.2 Separación Lógica

Cada entorno tiene su propia base de datos, credenciales y configuración
Kubernetes namespaces diferentes por entorno (cuando aplique)
Network Policies impiden comunicación cross-entorno
Variables de entorno diferentes por entorno (Kubernetes ConfigMaps/Secrets)

5.3 Separación de Deberes (Q39)

Rol	Desarrollo	Staging	Producción
Desarrolladores	Read/Write	Read	No acceso directo
QA	Read	Read/Write	No acceso directo
DevOps	Read	Read	Read/Write (con MFA)
CI/CD Pipeline	N/A	Deploy auto	Deploy auto (con aprobación)

Los desarrolladores no pueden desplegar directamente a producción
Solo el pipeline CI/CD con aprobación puede desplegar a producción
Esto asegura que solo cambios revisados y aprobados llegan a producción

6. Datos de Prueba (Q40)

6.1 Generación de Datos de Prueba

Los datos de prueba se generan mediante fixtures y factories en código
Se utilizan generadores de datos falsos (ej: faker.js) para nombres, emails, direcciones
PANs de prueba: solo se usan PANs de prueba estándar de la industria:
- 4111 1111 1111 1111 (Visa test)
- 5500 0000 0000 0004 (Mastercard test)
- Nunca se usa PAN real en entornos inferiores

6.2 Limpieza Pre-Producción

Antes de promover código a producción, se verifica que:
- No existen datos de prueba hardcodeados
- No existen cuentas de prueba
- Los fixtures no se ejecutan en producción
- Variables de entorno apuntan a recursos de producción (no dev)

7. Gestión de Cambios

7.1 Tipos de Cambio

Tipo	Ejemplos	Aprobación	Ventana
Estándar	Feature nueva, refactoring	PR review + merge approval	Horario laboral
Significativo	Nueva integración, cambio de DB schema, nuevo servicio	PR review + Oficial de Seguridad	Ventana de cambio programada
Parche de seguridad	CVE fix, dependency update	PR review expedito	Inmediato
Emergencia	Hotfix producción	Post-factum (dentro de 24h)	Inmediato

7.2 Información en Registros de Cambio

Todo cambio debe incluir:

Campo	Descripción
ID del cambio	Número de PR o ticket
Descripción	Qué se cambia y por qué
Fecha	Cuándo se implementa
Solicitante	Quién hace el PR
Aprobador	Quién aprueba (diferente al solicitante)
Impacto	Sistemas afectados, riesgo
Pruebas	Resultados de CI/CD + pruebas manuales
Plan de reversión	Cómo hacer rollback

7.3 Plan de Reversión

Todo cambio en producción debe tener un plan de rollback documentado
Para Kubernetes: kubectl rollout undo deployment/<service>
Para DB migrations: script de rollback SQL
Para configuración: revert del commit en Git

8. Protección de Aplicaciones Web Públicas (Q43)

8.1 WAF (Web Application Firewall)

Kong Gateway actúa como WAF con los siguientes plugins:
- Rate Limiting (protección contra DDoS)
- IP Restriction (whitelist/blacklist)
- Request Size Limiting (prevención de payloads grandes)
- Bot Detection
- CORS (Cross-Origin Resource Sharing)

8.2 Security Headers

Configurados en Kong para todas las respuestas:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'
Referrer-Policy: strict-origin-when-cross-origin

8.3 Monitoreo de WAF

Alertas configuradas para eventos de seguridad de Kong
Revisión de logs de WAF (rate limit hits, blocked IPs)
Actualización de reglas ante nuevas amenazas

9. Scripts de Página de Pago (Q1030)

9.1 Inventario de Scripts

Se mantiene un inventario de todos los scripts que se ejecutan en páginas de pago, incluyendo:

Scripts propios (first-party)
Scripts de terceros (analytics, fraud detection)
Justificación escrita de por qué cada script es necesario

9.2 Autorización e Integridad

Content Security Policy (CSP) restringe qué scripts pueden ejecutarse
Subresource Integrity (SRI) para scripts de terceros
Revisión trimestral del inventario de scripts

10. Entrenamiento de Codificación Segura (Q42)

10.1 Material de Entrenamiento

OWASP Top 10 aplicado a Node.js/TypeScript/NestJS
Prácticas seguras con PostgreSQL (parameterized queries, RLS)
Manejo seguro de datos de tarjetas (PCI DSS for developers)
Gestión de secretos y variables de entorno

10.2 Frecuencia

Anual: Todo el equipo de desarrollo y QA
Onboarding: Nuevos desarrolladores antes de acceder al código

10.3 Registros

Se mantienen registros de finalización de entrenamiento con:

Nombre del participante
Fecha de finalización
Material cubierto
Resultado de evaluación (si aplica)

Historial de Revisiones

Versión	Fecha	Autor	Cambios
1.0	2026-03-13	Líder de Desarrollo / Seguridad	Documento inicial

Aprobación

Rol	Nombre	Firma	Fecha
CISO / Oficial de Seguridad	_________________	_________________	//____
Gerencia Ejecutiva	_________________	_________________	//____

POL-005: Política de SDLC Seguro y Gestión de Cambios ​

1. Propósito ​

2. Ciclo de Vida de Desarrollo Seguro ​

2.1 Fases del SDLC ​

2.2 Requisitos de Seguridad por Fase ​

3. Estándares de Codificación Segura ​

3.1 Vulnerabilidades a Prevenir (OWASP Top 10) ​

3.2 Prácticas Prohibidas ​

4. Revisión de Código ​

4.1 Revisión Obligatoria ​

4.2 SAST Automatizado ​

4.3 Registros de Revisión ​

5. Separación de Entornos ​

5.1 Entornos ​

5.2 Separación Lógica ​

5.3 Separación de Deberes (Q39) ​

6. Datos de Prueba (Q40) ​

6.1 Generación de Datos de Prueba ​

6.2 Limpieza Pre-Producción ​

7. Gestión de Cambios ​

7.1 Tipos de Cambio ​

7.2 Información en Registros de Cambio ​

7.3 Plan de Reversión ​

8. Protección de Aplicaciones Web Públicas (Q43) ​

8.1 WAF (Web Application Firewall) ​

8.2 Security Headers ​

8.3 Monitoreo de WAF ​

9. Scripts de Página de Pago (Q1030) ​

9.1 Inventario de Scripts ​

9.2 Autorización e Integridad ​

10. Entrenamiento de Codificación Segura (Q42) ​

10.1 Material de Entrenamiento ​

10.2 Frecuencia ​

10.3 Registros ​

Historial de Revisiones ​

Aprobación ​