EVD-SECURE-DEV — Evidencia de Desarrollo Seguro

Campo	Valor
Documento	EVD-SECURE-DEV
Version	1.0
Clasificacion	Interno — Confidencial
Fecha de emision	2026-04-03
Proxima revision	2027-04-03
Propietario	CISO / Lider de Desarrollo
Requisito PCI DSS	6.1, 6.2, 6.3, 6.4, 6.5
Preguntas ControlCase	Q35, Q37, Q38, Q39, Q40, Q42, Q43, Q1030
Politica de referencia	`POL-005-SDLC_CHANGE_MANAGEMENT`
Organizacion	Fintrixs SAS
Infraestructura	DigitalOcean Kubernetes (DOKS) / AWS EKS

Indice de Preguntas ControlCase

Pregunta	Titulo	Seccion
Q35	Politica de SDLC y Desarrollo Seguro	2. Q35
Q37	Revision de Codigo y Escaneo de Vulnerabilidades	3. Q37
Q38	Separacion de Entornos (prod/dev)	4. Q38
Q39	Separacion de Funciones (prod vs dev users)	5. Q39
Q40	Datos de Prueba y Limpieza Pre-produccion	6. Q40
Q42	Entrenamiento de Codificacion Segura	7. Q42
Q43	WAF para Aplicaciones Web Publicas	8. Q43
Q1030	Scripts de Pagina de Pago	9. Q1030

1. Contexto de la Plataforma

Fintrixs opera una plataforma de procesamiento de pagos construida con una arquitectura de microservicios NestJS (TypeScript) sobre Kubernetes. El stack completo:

Capa	Tecnologia
Runtime	Node.js 20+, TypeScript 5.3+ (`strict: true`)
Framework	NestJS 10.3 con Guards, Interceptors, Pipes
Base de datos	PostgreSQL 16 con Row-Level Security (RLS)
Mensajeria	Apache Kafka (KafkaJS 2.2.4) — patron Outbox + Inbox
API Gateway	Kong 3.5 (declarativo, `deck sync`)
Orquestacion	Kubernetes (DigitalOcean DOKS / AWS EKS)
CI/CD	GitHub Actions
Frontend	Vue 3 (Composition API), Vite 5, Pinia, TailwindCSS
Repositorio	GitHub — `Fintrixs-SAS/backend_fintrixs_pay`

Microservicios en Scope PCI

2. Q35 — Politica de SDLC y Desarrollo Seguro

2.1 Politica Formal

Fintrixs mantiene la politica POL-005: Politica de SDLC Seguro y Gestion de Cambios (version 1.0, emitida 2026-03-13), que define el ciclo de vida completo de desarrollo seguro alineado con PCI DSS Requisito 6.

Ubicacion del documento: docs/security/policies/POL-005-SDLC_CHANGE_MANAGEMENT.md

2.2 Fases del SDLC

2.3 Controles Tecnicos Implementados en el SDLC

Control	Implementacion	Evidencia
TypeScript estricto	`"strict": true` en `tsconfig.json` de cada servicio	`backend/apps//tsconfig.json`, `backend/packages//tsconfig.json`
Validacion de inputs	DTOs con `class-validator` en todos los endpoints	`backend/apps/payments-api/src/payment-intent/dto/create-payment-intent.dto.ts`, `backend/apps/merchants/src/merchant-features/merchant-features.dto.ts`
Queries parametrizadas	Todos los accesos a PostgreSQL usan `$1, $2...` con `pg` pool	`backend/apps/merchants/src/merchant-features/merchant-features.service.ts`
Branch protection	`main` protegido: requiere PR + review aprobado	GitHub Settings > Branch protection rules
CI automatizado	Pipeline en cada push/PR: lint, audit, tests, build	`.github/workflows/backend-ci.yml`, `backend/.github/workflows/ci.yml`
Security audit	`npm audit --audit-level=high` en CI	`backend/.github/workflows/ci.yml` (job: `code-quality`)
JWT RS256	Autenticacion con clave asimetrica, verificacion en Guards	`backend/apps/payments-api/src/auth/jwt-auth.guard.ts`

2.4 Ejemplo: DTO con Validacion (class-validator)

El siguiente fragmento muestra como se valida la creacion de un PaymentIntent — cada campo tiene decoradores que rechazan datos invalidos antes de llegar al servicio:

typescript

// backend/apps/payments-api/src/payment-intent/dto/create-payment-intent.dto.ts
export class CreatePaymentIntentDto {
  @IsUUID()
  merchant_id: string;

  @IsInt()
  @Min(1, { message: 'Amount must be greater than 0' })
  amount: number;

  @IsEnum(CurrencyCode)
  @IsOptional()
  currency?: CurrencyCode = CurrencyCode.USD;

  @IsString()
  @IsOptional()
  description?: string;
}

2.5 Ejemplo: Queries Parametrizadas (SQL Injection Prevention)

Todos los servicios que acceden directamente a PostgreSQL usan queries parametrizadas con placeholders posicionales ($1, $2, etc.). Nunca se concatenan strings para construir SQL:

typescript

// backend/apps/merchants/src/merchant-features/merchant-features.service.ts
const res = await this.db.pool.query(
  `SELECT * FROM ${this.schema}.payment_links WHERE id = $1 AND merchant_id = $2`,
  [id, merchantId],
);

2.6 Flujo de Trabajo Git (Branch Protection)

3. Q37 — Revision de Codigo y Escaneo de Vulnerabilidades

3.1 Proceso de Code Review

Requisito	Implementacion
Herramienta	GitHub Pull Requests
Revisores requeridos	Minimo 1 persona diferente al autor
Calificacion del revisor	Experiencia demostrable en seguridad de aplicaciones
Alcance de la revision	Vulnerabilidades OWASP, logica de negocio, manejo de datos sensibles
Bloqueo de merge	PR no puede hacer merge sin review aprobado + CI verde
Historial	Todo queda registrado en el historial de PRs de GitHub

3.2 Pipeline de Seguridad Automatizado (CI/CD)

Pipelines activos:

Pipeline	Archivo	Trigger	Comprobaciones
Code Quality & Linting	`backend/.github/workflows/ci.yml`	Push a `main`, `develop`, `feature/**`; PRs	ESLint, `npm audit --audit-level=high`
Backend CI	`.github/workflows/backend-ci.yml`	Push/PR a `backend/`	Build, tests de service-factory, validacion de contratos
Security Scan (Trivy)	`backend/.github/workflows/ci.yml` (job: `security-scan`)	Push a `main`/`develop`	Trivy vulnerability scanner en imagenes Docker
Microservices Deploy	`.github/workflows/microservices-eks-deploy.yml`	Push a `main`, `workflow_dispatch`	Build Docker, push ECR, deploy EKS via Helm

3.3 Herramientas de Seguridad

Herramienta	Proposito	Estado	Evidencia
npm audit	Vulnerabilidades en dependencias	Activo en CI	`backend/.github/workflows/ci.yml` job `code-quality`
ESLint	Analisis estatico de codigo	Activo en CI	`npm run lint` en pipeline
Trivy	Escaneo de vulnerabilidades en imagenes Docker	Activo en CI	`backend/.github/workflows/ci.yml` job `security-scan`
GitHub Security (SARIF)	Dashboard de vulnerabilidades	Activo	Upload de resultados Trivy a GitHub Security
SonarQube	SAST integral	Pendiente de implementacion	Recomendacion: integrar `sonarcloud-github-action`
Snyk	SCA + SAST en tiempo real	Pendiente de implementacion	Recomendacion: `snyk test` en CI

Nota: Se recomienda la implementacion de SonarQube Cloud y/o Snyk como capas adicionales de SAST/SCA para complementar npm audit y Trivy. Estas herramientas proporcionarian cobertura mas profunda de codigo fuente y dependencias transitivas.

3.4 Cobertura OWASP Top 10

#	Vulnerabilidad OWASP	Control en Fintrixs	Evidencia
A01	Broken Access Control	RLS en PostgreSQL, JWT RS256 Guards, RBAC	`backend/db//core/.sql` (politicas RLS), `backend/apps/payments-api/src/auth/jwt-auth.guard.ts`
A02	Cryptographic Failures	AES-256-GCM en vault, JWT RS256, TLS 1.2+	`card-vault-service`, `auth-service`, Kong TLS config
A03	Injection (SQL, NoSQL)	Queries parametrizadas (`$1, $2...`), ORM TypeORM, DTOs `class-validator`	`merchant-features.service.ts`, `create-payment-intent.dto.ts`
A04	Insecure Design	Threat modeling en fase de diseno, separacion CDE/App	POL-005 seccion 2.2
A05	Security Misconfiguration	Hardening de imagenes Docker (`npm ci --omit=dev`), no defaults	`backend/apps/*/Dockerfile`
A06	Vulnerable Components	`npm audit`, Trivy en CI, GitHub Dependabot	CI pipeline, GitHub Security tab
A07	Auth Failures	JWT RS256, Argon2id para passwords, MFA, account lockout, session management	`auth-service`
A08	Data Integrity Failures	Event Outbox transaccional, inbox idempotente, firma de webhooks	`@fintrix/event-bus`, `@fintrix/event-inbox-pg`
A09	Logging Failures	`@fintrix/logging` estructurado, PCI-safe (masking de PAN), audit triggers	`backend/packages/logging/`
A10	SSRF	Validacion de URLs en webhooks, Kong rate limiting	`webhooks-service`, Kong plugins

3.5 Ejemplo: Row-Level Security (RLS)

Las tablas con datos por merchant implementan RLS para que cada query solo acceda a datos del merchant autenticado, sin depender de WHERE en el codigo aplicativo:

sql

-- backend/db/merchants_db/core/006_merchant_features.sql
-- Ejemplo: tabla payment_links con RLS
ALTER TABLE merchants_core.payment_links ENABLE ROW LEVEL SECURITY;

La variable de sesion app.current_merchant_id se inyecta desde el JWT via el paquete @fintrix/tenant-context.

4. Q38 — Separacion de Entornos

4.1 Entornos Definidos

Entorno	Proposito	Infraestructura	Datos	Acceso
Desarrollo (local)	Codificacion, unit tests	Docker Compose local	Datos sinteticos (seed scripts)	Desarrolladores
CI (GitHub Actions)	Tests automatizados	Runners `ubuntu-latest` + PostgreSQL 16 efimero	Datos generados por fixtures	Automatizado (sin acceso humano)
Staging	Pruebas de integracion	DOKS / EKS cluster `fintrix-staging-eks`	Datos sinteticos	Dev + QA
Produccion	Operacion real	DOKS / EKS cluster `fintrix-prod-eks`	Datos reales de tarjetahabientes	DevOps restringido (con MFA)

4.2 Arquitectura de Separacion

4.3 Controles de Separacion

Control	Implementacion	Evidencia
Bases de datos separadas	Cada entorno tiene su propia instancia de Managed PostgreSQL	Terraform configs en `backend/infra/terraform/`
Credenciales diferentes	Cada entorno usa Kubernetes Secrets / ConfigMaps unicos	`ConfigService` de NestJS lee `process.env` inyectado por K8s
Namespaces K8s	Namespaces separados por servicio/entorno	`kubectl get ns` — namespaces: `kong`, `payments-api`, `auth-service`, etc.
Network Policies	`default-deny-all` en namespace CDE	`backend/infra/kubernetes/network-policies.yaml`
Cloud Firewalls	Reglas de firewall independientes por subnet	`docs/pci-dss/firewall_rules.md`
Node Pools aislados	CDE en nodos con taint `pci-scope=true:NoSchedule`	`docs/pci-dss/scope_definition.md`
VPN para management	Acceso administrativo via WireGuard (:51820)	`docs/pci-dss/network_diagram.md`

4.4 Configuracion por Entorno (ConfigService)

Todos los servicios NestJS obtienen su configuracion via @nestjs/config (ConfigService), que lee variables de entorno inyectadas por Kubernetes Secrets/ConfigMaps. Nunca se usa process.env directamente en el codigo aplicativo:

typescript

// Patron estandar en todos los servicios
constructor(private readonly configService: ConfigService) {
  this.schema = this.configService.get('DB_SCHEMA', 'merchants_core');
  this.kongProxyUrl = this.configService.get('KONG_PROXY_URL', 'http://localhost:8000');
}

Variables criticas por entorno:

Variable	Desarrollo	Staging	Produccion
`DATABASE_URL`	`localhost:5432`	Managed PG staging	Managed PG produccion
`KAFKA_BROKERS`	`localhost:9092`	Kafka cluster staging	Kafka cluster produccion
`JWT_PUBLIC_KEY`	Clave de desarrollo	Clave staging	Clave produccion (RS256)
`KONG_PROXY_URL`	`localhost:8000`	Kong interno staging	Kong interno produccion
`ENCRYPTION_KEY`	Clave efimera de dev	Clave staging	Clave produccion (HSM)

5. Q39 — Separacion de Funciones

5.1 Matriz de Acceso por Rol

Rol	Desarrollo	Staging	Produccion	Descripcion
Desarrollador	Read/Write	Read	Sin acceso	Escribe codigo, crea PRs
QA	Read	Read/Write	Sin acceso	Valida en staging
DevOps / SRE	Read	Read	Read/Write (MFA)	Opera produccion
CI/CD Pipeline	N/A	Deploy auto	Deploy auto (con aprobacion)	Automatizado
CISO	Read	Read	Read (audit only)	Supervision de seguridad

5.2 Flujo de Deploy a Produccion

5.3 Controles Implementados

Control	Mecanismo	Evidencia
Branch protection	`main` protegido: no push directo, requiere PR + review	GitHub Settings → Branch protection rules
PR reviews obligatorios	Minimo 1 reviewer diferente al autor	GitHub Branch protection: "Require pull request reviews"
CI gate	Merge bloqueado si CI falla (lint, tests, audit)	`.github/workflows/backend-ci.yml`, `ci.yml`
Environment protection	Deploy a produccion requiere aprobacion explicita	`.github/workflows/microservices-eks-deploy.yml` linea `environment: production`
RBAC en Kubernetes	GitHubActions role no puede crear namespaces (cluster-scope limitado)	Pipeline: `kubectl get ns "$NS"` verifica pre-existencia
Runners diferenciados	Staging: self-hosted `fintrix-vpc/staging`; Produccion: `fintrix-vpc/production`	`microservices-eks-deploy.yml` linea 36
AWS IAM roles separados	Staging: `AWS_ROLE_ARN_STAGING`; Produccion: `AWS_ROLE_ARN_PRODUCTION`	OIDC federation en pipeline
Sin acceso directo a prod DB	Desarrolladores no tienen credenciales de produccion	Secrets gestionados via K8s Secrets, no compartidos

5.4 Evidencia: GitHub Actions Environment Protection

El pipeline microservices-eks-deploy.yml implementa separacion de entornos a nivel de GitHub:

yaml

# .github/workflows/microservices-eks-deploy.yml
environment: ${{ (github.event_name == 'workflow_dispatch'
  && github.event.inputs.environment == 'production')
  && 'production' || 'staging' }}

Produccion requiere aprobacion manual en GitHub Environment "production" antes de ejecutar el deploy.

6. Q40 — Datos de Prueba y Limpieza Pre-produccion

6.1 Generacion de Datos Sinteticos

Fintrixs genera datos de prueba exclusivamente sinteticos para entornos de desarrollo, CI y staging. Nunca se usan datos reales de tarjetahabientes en entornos inferiores.

Seed scripts:

Script	Ubicacion	Contenido
Seed de payment intents	`backend/db/payments_db/core/002_seed_payment_intents.sql`	53 transacciones con datos ficticios
Seed de merchant features	`backend/db/merchants_db/core/007_seed_merchant_features.sql`	Datos ficticios de merchants
Seeds de servicios generados	`backend/db/*/core/generated/001_tables.sql`	Tablas + datos para service factory

6.2 PANs de Prueba

Se utilizan exclusivamente PANs de prueba estandar de la industria. Los PANs de prueba no son numeros de tarjeta reales y son reconocidos por todos los procesadores como datos de test:

PAN de Prueba	Marca	Proposito
`4111 1111 1111 1111`	Visa	Aprobacion exitosa
`5500 0000 0000 0004`	Mastercard	Aprobacion exitosa
`visa_4242`	Visa (tokenizado)	Referencia en metadata de seed
`mastercard_5555`	Mastercard (tokenizado)	Referencia en metadata de seed

Evidencia en seed scripts — los datos usan referencias tokenizadas, nunca PANs completos:

sql

-- backend/db/payments_db/core/002_seed_payment_intents.sql
methods TEXT[] := ARRAY[
  'visa_4242','mastercard_5555','pse','visa_4242','nequi', ...
];
-- Solo se almacenan referencias tokenizadas, no PANs reales

6.3 Datos Ficticios en Seeds

Los scripts de seed usan nombres, emails y montos completamente ficticios:

sql

customers TEXT[] := ARRAY[
  'Carlos Rodriguez','Maria Lopez','TechCorp SAS','Ana Martinez', ...
];
emails TEXT[] := ARRAY[
  'carlos@email.com','maria@email.com','billing@techcorp.co', ...
];

6.4 Controles de Limpieza Pre-produccion

Control	Implementacion	Verificacion
No seed en produccion	Los scripts de seed (`002_seed_*.sql`) no se ejecutan en produccion	Pipeline de deploy no incluye paso de seed
No datos hardcodeados	CI verifica que no existan credenciales ni datos reales en codigo	`npm audit` + code review
No cuentas de prueba en prod	Usuarios de test solo existen en dev/staging	Revision pre-deploy
Variables correctas	ConfigService garantiza que cada entorno apunta a su propia infraestructura	K8s Secrets por namespace
CI efimero	PostgreSQL de CI es un service container que se destruye al terminar el job	`backend/.github/workflows/ci.yml` — servicio `postgres` efimero

6.5 Flujo de Validacion Pre-produccion

7. Q42 — Entrenamiento de Codificacion Segura

7.1 Estado Actual

Aspecto	Estado
Plataforma de entrenamiento	ControlCase — pendiente de completar registro
Material preparado	OWASP Top 10, PCI DSS for developers, NestJS security best practices
Equipo objetivo	Todo el equipo de desarrollo y QA
Frecuencia planificada	Anual + onboarding de nuevos miembros

7.2 Composicion del Equipo

Rol	Cantidad	Responsabilidad PCI
Lider de Desarrollo / Arquitecto	1	Arquitectura CDE, threat modeling, code review
Desarrollador Backend Sr.	2	Desarrollo de microservicios en scope PCI
Desarrollador Frontend	1	Dashboard Vue 3, paginas de checkout
DevOps / SRE	1	Infraestructura K8s, pipelines CI/CD

7.3 Temas de Entrenamiento Planificados

Tema	Contenido	Duracion est.
OWASP Top 10 para Node.js/NestJS	Injection, auth, XSS, SSRF aplicados al stack actual	4 horas
PCI DSS para Desarrolladores	Requisitos 6.x, manejo de PAN, scope CDE	3 horas
PostgreSQL Seguro	Queries parametrizadas, RLS, gestion de privilegios	2 horas
Gestion de Secretos	Variables de entorno, ConfigService, K8s Secrets, nunca hardcodear	1 hora
Secure Code Review	Que buscar en un PR, patrones de riesgo, checklist	2 horas
Docker/K8s Security	Hardening de imagenes, Network Policies, Pod Security Standards	2 horas

7.4 Registros de Entrenamiento

Se mantendran registros de finalizacion con:

Nombre del participante
Fecha de finalizacion
Material cubierto
Resultado de evaluacion (cuando aplique)
Certificado de la plataforma ControlCase

Accion pendiente: Completar el proceso de registro en la plataforma ControlCase y programar las primeras sesiones de entrenamiento. Fecha objetivo: Q2 2026.

8. Q43 — WAF para Aplicaciones Web Publicas

8.1 Arquitectura de Proteccion Web

8.2 Kong como WAF (Implementacion Actual)

Kong Gateway actua como capa de proteccion WAF con los siguientes plugins configurados en backend/infra/kong/kong.yaml:

Plugin	Funcion	Configuracion
CORS	Controla origenes permitidos, metodos y headers	Activo globalmente. Headers: `Authorization`, `X-Merchant-Id`, `Content-Type`, etc.
JWT	Validacion de tokens RS256 en rutas protegidas	`claims_to_verify: [exp]`, `algorithm: RS256`
Rate Limiting	Proteccion contra DDoS y abuso	Configurado por ruta critica
Request Size Limiting	Previene payloads excesivos	Limite configurable por ruta
IP Restriction	Whitelist/blacklist de IPs	Disponible para rutas administrativas
Bot Detection	Identificacion de trafico automatizado	Reglas basadas en User-Agent

8.3 Security Headers

Configurados en Kong para todas las respuestas HTTP:

Header	Valor	Proposito
`Strict-Transport-Security`	`max-age=31536000; includeSubDomains`	Forzar HTTPS
`X-Content-Type-Options`	`nosniff`	Prevenir MIME sniffing
`X-Frame-Options`	`DENY`	Prevenir clickjacking
`X-XSS-Protection`	`1; mode=block`	Filtro XSS del navegador
`Content-Security-Policy`	`default-src 'self'`	Restringir origenes de recursos
`Referrer-Policy`	`strict-origin-when-cross-origin`	Controlar informacion de referrer

8.4 DigitalOcean Cloud Firewall

Fintrixs utiliza Cloud Firewalls de DigitalOcean como primera capa de defensa perimetral:

Firewall	Subnet	Regla principal
DMZ FW	`10.100.1.0/24`	Solo acepta HTTPS 443 desde Internet
CDE FW	`10.100.10.0/24`	Solo acepta trafico desde LB y puertos especificos desde App
App FW	`10.100.20.0/24`	Trafico inter-servicio, sin acceso directo desde Internet
Mgmt FW	`10.100.30.0/24`	Solo VPN (WireGuard :51820)

Detalle completo: docs/pci-dss/firewall_rules.md

8.5 Recomendacion: WAF Dedicado

Si bien Kong proporciona funcionalidades de WAF basicas (rate limiting, headers, JWT), se recomienda implementar un WAF dedicado para cumplimiento completo de PCI DSS 6.4:

Opcion	Ventajas	Consideraciones
Cloudflare WAF	Managed rules OWASP, DDoS protection, bot management	Requiere cambiar DNS a Cloudflare
DigitalOcean App Firewall	Integracion nativa con DOKS, sin cambio de DNS	Funcionalidades mas limitadas
AWS WAF (si en EKS)	Integracion nativa con ALB/CloudFront, reglas managed	Solo para workloads en AWS

Accion recomendada: Evaluar e implementar Cloudflare WAF como capa adicional frente al Load Balancer para obtener proteccion OWASP managed rules y DDoS avanzado.

9. Q1030 — Scripts de Pagina de Pago

9.1 Arquitectura de la Pagina de Pago

Fintrixs opera una SPA (Single Page Application) construida con Vue 3 que incluye funcionalidad de checkout/pago. La aplicacion se sirve como un bundle compilado por Vite:

9.2 Inventario de Scripts en Pagina de Pago

Script	Tipo	Origen	Justificacion	Hash SRI
`main.ts` (Vue 3 app bundle)	First-party	Build Vite	Aplicacion principal del dashboard/checkout	Generado en build
`vue.runtime.esm-bundler.js`	First-party (bundled)	npm dependency, incluido en build	Framework de UI	Incluido en bundle
`pinia`	First-party (bundled)	npm dependency, incluido en build	Estado global de la aplicacion	Incluido en bundle
`axios`	First-party (bundled)	npm dependency, incluido en build	Cliente HTTP para API calls	Incluido en bundle

9.3 Ausencia de Scripts de Terceros

La pagina de pago de Fintrixs no carga scripts de terceros (no hay Google Analytics, Facebook Pixel, ni SDKs de payment processors externos en la pagina de checkout). Todas las dependencias se incluyen en el bundle de Vite durante el build:

html

<!-- frontend/apps/fintrix-dashboard/index.html -->
<!doctype html>
<html lang="es">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/fintrix-logo.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Fintrix Dashboard - Pasarela de Pagos</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

Solo se carga un unico script (/src/main.ts compilado por Vite) — todos los demas modulos estan incluidos en el bundle.

9.4 Content Security Policy (CSP)

CSP se configura como header HTTP en Kong Gateway para restringir que scripts pueden ejecutarse:

Content-Security-Policy: default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data:;
  connect-src 'self' https://api.fintrixs.com;
  font-src 'self';
  frame-ancestors 'none';

Directiva	Valor	Efecto
`default-src`	`'self'`	Solo recursos del mismo origen por defecto
`script-src`	`'self'`	Solo scripts first-party; bloquea scripts externos e inline
`connect-src`	`'self' https://api.fintrixs.com`	Solo API calls al backend propio
`frame-ancestors`	`'none'`	Previene embedding en iframes (clickjacking)

9.5 Subresource Integrity (SRI)

Para assets servidos desde CDN (si aplica en produccion), se genera SRI hash durante el build de Vite:

Mecanismo	Estado	Descripcion
Vite build hashing	Activo	Cada archivo incluye hash en el nombre (`main.a1b2c3.js`)
SRI tags en HTML	Configurable	Disponible via plugin `vite-plugin-sri` si se sirven desde CDN externo
Verificacion de integridad	Activo	Vite genera hashes unicos por build; cualquier modificacion invalida el cache

9.6 Vite Proxy en Desarrollo

En desarrollo local, las llamadas API se proxean a Kong Gateway local, sin exponer endpoints directamente:

typescript

// frontend/apps/fintrix-dashboard/vite.config.ts
server: {
  port: 5173,
  proxy: {
    '/api': {
      target: 'http://localhost:8000', // Kong Gateway
      changeOrigin: true,
      secure: false
    }
  }
}

9.7 Proceso de Revision Trimestral de Scripts

Paso	Actividad	Responsable
1	Inventariar todos los scripts cargados en paginas de pago	Desarrollador Frontend
2	Verificar que no se hayan agregado scripts de terceros	Lider de Desarrollo
3	Validar que CSP headers estan configurados correctamente	DevOps
4	Revisar `package.json` por dependencias nuevas	Code Review en PR
5	Documentar cualquier cambio en este inventario	CISO

10. Resumen de Evidencias y Ubicaciones

Evidencia	Ubicacion en el Repositorio
Politica SDLC	`docs/security/policies/POL-005-SDLC_CHANGE_MANAGEMENT.md`
Pipeline CI — Code Quality	`backend/.github/workflows/ci.yml`
Pipeline CI — Backend	`.github/workflows/backend-ci.yml`
Pipeline Deploy	`.github/workflows/microservices-eks-deploy.yml`
Configuracion Kong	`backend/infra/kong/kong.yaml`
DTOs con class-validator	`backend/apps/payments-api/src/payment-intent/dto/create-payment-intent.dto.ts`
DTOs merchant features	`backend/apps/merchants/src/merchant-features/merchant-features.dto.ts`
Queries parametrizadas	`backend/apps/merchants/src/merchant-features/merchant-features.service.ts`
JWT RS256 Guard	`backend/apps/payments-api/src/auth/jwt-auth.guard.ts`
Seed data (sintetico)	`backend/db/payments_db/core/002_seed_payment_intents.sql`
RLS policies	`backend/db/merchants_db/core/006_merchant_features.sql`, `backend/db//core/.sql`
Network diagram	`docs/pci-dss/network_diagram.md`
Firewall rules	`docs/pci-dss/firewall_rules.md`
Scope definition	`docs/pci-dss/scope_definition.md`
Frontend SPA	`frontend/apps/fintrix-dashboard/index.html`
Vite config	`frontend/apps/fintrix-dashboard/vite.config.ts`
Trivy security scan	`backend/.github/workflows/ci.yml` (job: `security-scan`)

Historial de Revisiones

Version	Fecha	Autor	Cambios
1.0	2026-04-03	Lider de Desarrollo / Seguridad	Documento inicial — evidencias Q35, Q37, Q38, Q39, Q40, Q42, Q43, Q1030

Aprobacion

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

EVD-SECURE-DEV — Evidencia de Desarrollo Seguro ​

Indice de Preguntas ControlCase ​

1. Contexto de la Plataforma ​

Microservicios en Scope PCI ​

2. Q35 — Politica de SDLC y Desarrollo Seguro ​

2.1 Politica Formal ​

2.2 Fases del SDLC ​

2.3 Controles Tecnicos Implementados en el SDLC ​

2.4 Ejemplo: DTO con Validacion (class-validator) ​

2.5 Ejemplo: Queries Parametrizadas (SQL Injection Prevention) ​

2.6 Flujo de Trabajo Git (Branch Protection) ​

3. Q37 — Revision de Codigo y Escaneo de Vulnerabilidades ​

3.1 Proceso de Code Review ​

3.2 Pipeline de Seguridad Automatizado (CI/CD) ​

3.3 Herramientas de Seguridad ​

3.4 Cobertura OWASP Top 10 ​

3.5 Ejemplo: Row-Level Security (RLS) ​

4. Q38 — Separacion de Entornos ​

4.1 Entornos Definidos ​

4.2 Arquitectura de Separacion ​

4.3 Controles de Separacion ​

4.4 Configuracion por Entorno (ConfigService) ​

5. Q39 — Separacion de Funciones ​

5.1 Matriz de Acceso por Rol ​

5.2 Flujo de Deploy a Produccion ​

5.3 Controles Implementados ​

5.4 Evidencia: GitHub Actions Environment Protection ​

6. Q40 — Datos de Prueba y Limpieza Pre-produccion ​

6.1 Generacion de Datos Sinteticos ​

6.2 PANs de Prueba ​

6.3 Datos Ficticios en Seeds ​

6.4 Controles de Limpieza Pre-produccion ​

6.5 Flujo de Validacion Pre-produccion ​

7. Q42 — Entrenamiento de Codificacion Segura ​

7.1 Estado Actual ​

7.2 Composicion del Equipo ​

7.3 Temas de Entrenamiento Planificados ​

7.4 Registros de Entrenamiento ​

8. Q43 — WAF para Aplicaciones Web Publicas ​

8.1 Arquitectura de Proteccion Web ​

8.2 Kong como WAF (Implementacion Actual) ​

8.3 Security Headers ​

8.4 DigitalOcean Cloud Firewall ​

8.5 Recomendacion: WAF Dedicado ​

9. Q1030 — Scripts de Pagina de Pago ​

9.1 Arquitectura de la Pagina de Pago ​

9.2 Inventario de Scripts en Pagina de Pago ​

9.3 Ausencia de Scripts de Terceros ​

9.4 Content Security Policy (CSP) ​

9.5 Subresource Integrity (SRI) ​

9.6 Vite Proxy en Desarrollo ​

9.7 Proceso de Revision Trimestral de Scripts ​

10. Resumen de Evidencias y Ubicaciones ​

Historial de Revisiones ​

Aprobacion ​

EVD-SECURE-DEV — Evidencia de Desarrollo Seguro

Indice de Preguntas ControlCase

1. Contexto de la Plataforma

Microservicios en Scope PCI

2. Q35 — Politica de SDLC y Desarrollo Seguro

2.1 Politica Formal

2.2 Fases del SDLC

2.3 Controles Tecnicos Implementados en el SDLC

2.4 Ejemplo: DTO con Validacion (class-validator)

2.5 Ejemplo: Queries Parametrizadas (SQL Injection Prevention)

2.6 Flujo de Trabajo Git (Branch Protection)

3. Q37 — Revision de Codigo y Escaneo de Vulnerabilidades

3.1 Proceso de Code Review

3.2 Pipeline de Seguridad Automatizado (CI/CD)

3.3 Herramientas de Seguridad

3.4 Cobertura OWASP Top 10

3.5 Ejemplo: Row-Level Security (RLS)

4. Q38 — Separacion de Entornos

4.1 Entornos Definidos

4.2 Arquitectura de Separacion

4.3 Controles de Separacion

4.4 Configuracion por Entorno (ConfigService)

5. Q39 — Separacion de Funciones

5.1 Matriz de Acceso por Rol

5.2 Flujo de Deploy a Produccion

5.3 Controles Implementados

5.4 Evidencia: GitHub Actions Environment Protection

6. Q40 — Datos de Prueba y Limpieza Pre-produccion

6.1 Generacion de Datos Sinteticos

6.2 PANs de Prueba

6.3 Datos Ficticios en Seeds

6.4 Controles de Limpieza Pre-produccion

6.5 Flujo de Validacion Pre-produccion

7. Q42 — Entrenamiento de Codificacion Segura

7.1 Estado Actual

7.2 Composicion del Equipo

7.3 Temas de Entrenamiento Planificados

7.4 Registros de Entrenamiento

8. Q43 — WAF para Aplicaciones Web Publicas

8.1 Arquitectura de Proteccion Web

8.2 Kong como WAF (Implementacion Actual)

8.3 Security Headers

8.4 DigitalOcean Cloud Firewall

8.5 Recomendacion: WAF Dedicado

9. Q1030 — Scripts de Pagina de Pago

9.1 Arquitectura de la Pagina de Pago

9.2 Inventario de Scripts en Pagina de Pago

9.3 Ausencia de Scripts de Terceros

9.4 Content Security Policy (CSP)

9.5 Subresource Integrity (SRI)

9.6 Vite Proxy en Desarrollo

9.7 Proceso de Revision Trimestral de Scripts

10. Resumen de Evidencias y Ubicaciones

Historial de Revisiones

Aprobacion