Seguridad, Gestión de Vulnerabilidades y Monitoreo del SENIAT

Este anexo demuestra que el sistema Zentto ERP cuenta con controles de seguridad operativos y con infraestructura dispuesta para que el SENIAT verifique y monitoree el sistema, en cumplimiento del artículo 3 (integridad, confiabilidad, inviolabilidad y acceso del SENIAT), el artículo 8 (obligaciones del proveedor) y las Disposiciones Finales de la Providencia Administrativa SNAT/2024/000121.

1. Seguridad y respaldos en el backoffice administrativo

El panel administrativo (backoffice) del ERP incorpora visibilidad operativa del estado de respaldos y de los eventos de seguridad y auditoría. Endpoints verificados en el repositorio zentto-web, módulo web/api/src/modules/backoffice/:

• GET /v1/backoffice/backups — último respaldo por contribuyente (tenant).
• GET /v1/backoffice/tenants/:companyId/backups — historial de respaldos del contribuyente.
• POST /v1/backoffice/tenants/:companyId/backup — ejecución de respaldo bajo demanda.

Cada respaldo se registra en sys."TenantBackup" con su estado y clave de almacenamiento; el servicio incluye verificación de conexión de almacenamiento y restauración. Las acciones administrativas sensibles quedan auditadas en audit.AuditLog (quién, cuándo y por qué). El detalle del plan se documenta en la página de respaldo, conservación y retención (10 años).

2. CI/CD con búsqueda de vulnerabilidades

Ningún cambio llega a producción sin pasar por el pipeline de seguridad. El repositorio zentto-web define el flujo .github/workflows/security.yml, que invoca el flujo reutilizable centralizado del ecosistema e incluye:

• SAST mediante análisis estático del código (Semgrep), con publicación de resultados (SARIF) al panel de escaneo de código (GitHub code scanning / CodeQL).
• Escaneo de dependencias con Trivy y OSV-Scanner.
• Detección de secretos con gitleaks.
• Security gate que bloquea el merge ante vulnerabilidades: umbral high en el flujo productivo y umbral critical en el flujo de desarrollo.

El gate se ejecuta en cada pull request y en cada cambio sobre las ramas developer y main, además de un análisis programado semanal. El cambio también debe superar la verificación de contrato (OpenAPI) y de tipos antes de desplegarse.

graph LR
  PR["Pull request / push"] --> SAST["SAST (Semgrep → SARIF)"]
  PR --> DEP["Dependencias (Trivy + OSV)"]
  PR --> SEC["Secretos (gitleaks)"]
  SAST --> GATESecurity gate<br/>prod: high · dev: critical
  DEP --> GATE
  SEC --> GATE
  GATE -->|falla| BLOCK["Merge bloqueado"]
  GATE -->|pasa| TYPES["Contrato OpenAPI + tipos"]
  TYPES --> BUILD["Build Docker + deploy"]
    

3. Gestión de secretos con HashiCorp Vault

Los secretos del ecosistema se centralizan en HashiCorp Vault (autenticación por AppRole y motor de secretos KV v2). En el runtime productivo, con VAULT_OVERRIDE activo, la fuente de verdad de los secretos es Vault y no archivos .env; no existen credenciales en el código fuente. El modelo contempla rotación de secretos y separación estricta entre los entornos de desarrollo y de producción (cada entorno usa su propio AppRole y su propia ruta de secretos). La integración se implementa en web/api/src/config/vault.ts del repositorio zentto-web. Este expediente no contiene secretos activos.

4. Autenticación con JWT en cookies httpOnly

La sesión se transporta en una cookie zentto_token con atributos httpOnly, Secure y SameSite. Al no ser accesible desde JavaScript del navegador ni almacenarse en localStorage, se reduce la exposición a robo de sesión por ataques de tipo XSS. La verificación del token es dual:

• RS256 (preferido) — verificado contra el JWKS público del servicio de autenticación (.well-known/jwks.json), con caché del conjunto de claves.
• HS256 (compatibilidad) — verificado con secreto local durante la transición.

Se complementa con expiración del token (2 horas), defensa CSRF por validación de Origin/Referer, CORS por lista blanca, endurecimiento de cabeceras con helmet y limitación de tasa en autenticación. Estos controles protegen la integridad e inviolabilidad de la información exigidas por el artículo 3 de la Providencia, al impedir que un tercero altere o suplante operaciones registradas.

5. Infraestructura de monitoreo para el SENIAT (acceso permanente)

El sistema dispone de capacidad permanente para que la Administración Tributaria verifique y monitoree la operación, conforme al artículo 3 y a las Disposiciones Finales:

• Clave de consulta y API. El SENIAT accede mediante la cabecera X-Seniat-Key sobre las rutas /seniat/*, que permiten verificar la integridad del ledger y consultar la información fiscal del contribuyente. El acceso es permanente mientras la clave esté vigente.
• Bitácora inmutable consultable. La cadena hash-encadenada de eventos (compliance."EventLedger") puede consultarse y verificarse en cualquier momento mediante GET /seniat/verify/:tenantId.
• Observabilidad operativa. El ecosistema cuenta con un stack de observabilidad operativo (registro de tráfico HTTP, trazas mediante observabilityMiddleware y auditoría de acceso en audit-trail), que respalda la trazabilidad de cada operación y de cada consulta.
• Reportes a solicitud. Los libros fiscales (ventas, compras, retenciones) se generan por período y quedan disponibles para la Administración Tributaria.

graph TD
  SENIAT["SENIAT — funcionario autorizado"] -->|X-Seniat-Key| API["API de consulta /seniat/*"]
  API --> VER["Verificación de integridad del ledger"]
  API --> REP["Libros fiscales por período"]
  API --> LED["Bitácora inmutable (EventLedger)"]
  VER --> AUD["Auditoría de acceso (audit.AccessLog)"]
  REP --> AUD
  LED --> AUD
  AUD --> OBS["Observabilidad: logs / trazas / auditoría"]
    

De este modo, cada acceso del SENIAT queda a su vez trazado en la bitácora de acceso, lo que garantiza un monitoreo verificable y auditable de extremo a extremo.

ZENTTO GLOBAL TECHNOLOGY, C.A. — RIF J-50849797-0 — Seguridad, CI/CD y monitoreo SENIAT (Art. 3 y 8 SNAT/2024/000121) — v1.0.0.