Gestión de Dependencias, Vulnerabilidades y Deprecaciones

Este documento registra el estado de las dependencias del proyecto gestiona-loteos-parcelas-agrado-backend, las vulnerabilidades identificadas por npm audit, y las estrategias para mitigarlas o gestionarlas proactivamente. El objetivo es asegurar un proyecto robusto, seguro y mantenible.

Fecha de Última Revisión: 17 de Mayo, 2025

1. Proceso de Auditoría y Gestión de Dependencias

1. Auditoría Regular: Se ejecuta npm audit periódicamente (ej. después de instalar nuevas dependencias, antes de un "release" interno importante, o en intervalos programados) para identificar vulnerabilidades conocidas.
2. Corrección Automática: Se intenta aplicar correcciones automáticas con npm audit fix.
3. Corrección Forzada (Evaluada): Si persisten vulnerabilidades y npm audit sugiere npm audit fix --force, se evalúa cuidadosamente el impacto de esta acción, revisando los "breaking changes" potenciales antes de ejecutarla. Cualquier aplicación de --force se documenta.
4. Análisis y Mitigación de No Resueltas: Las vulnerabilidades que no pueden ser resueltas automáticamente se analizan individualmente para determinar su impacto real en el contexto específico de este proyecto y se define una estrategia de mitigación.
5. Gestión de Paquetes Deprecados: Las advertencias sobre paquetes deprecados se analizan para entender las razones de la deprecación, el impacto en el proyecto y para planificar la migración a alternativas recomendadas en un plazo razonable.
6. Documentación: Todas las decisiones significativas, riesgos aceptados y planes de mitigación se documentan en esta página de la Wiki.

2. Vulnerabilidades Identificadas y Estrategias (Basado en npm audit del 16 de Mayo, 2025)

A continuación, se detallan las vulnerabilidades persistentes después de la ejecución de npm audit fix y npm audit fix --force, junto con la estrategia de mitigación para cada una.

2.1. Vulnerabilidades en xlsx (SheetJS)

• Vulnerabilidades Reportadas:
  • Prototype Pollution in sheetJS (GHSA-4r6h-8v6p-xvw6) - Severidad Alta.
  • SheetJS Regular Expression Denial of Service (ReDoS) (GHSA-5pgg-2g8v-p4x9) - Severidad Alta.
• Fix Automático Disponible: No (No fix available según npm audit).
• Impacto Potencial en "Gestor de Loteos":
  • Alto, si se procesan archivos Excel (.xlsx, .csv) maliciosamente manipulados subidos por administradores de loteo para la funcionalidad de "Carga Masiva de Residentes/Parcelas".
  • Riesgos incluyen corrupción de datos en la aplicación, comportamiento inesperado debido a la polución de prototipos, o denegación de servicio (alto consumo de CPU) en el proceso o worker encargado de la importación.
• Estrategia de Mitigación Decidida:
  1. Investigación Activa de Alternativas (Tarea Prioritaria): Se ha creado un Issue técnico ([ID_ISSUE_XLSX_ALT]) para investigar y evaluar librerías alternativas para el parseo de Excel/CSV en Node.js (ej. exceljs, fast-csv), priorizando la seguridad, el mantenimiento activo y la facilidad de uso. El objetivo es reemplazar xlsx si se encuentra una alternativa más segura y viable.
  2. Validación y Sanitización Rigurosa de la Entrada (Si se continúa con xlsx temporalmente):
     • El servicio de importación (UsuarioBatchImportService o similar) implementará validaciones exhaustivas sobre la estructura del archivo (nombres de columnas esperados, orden, tipos de datos básicos).
     • Se impondrán límites estrictos al tamaño del archivo y al número de filas procesables por carga.
     • Todos los datos leídos de las celdas del Excel serán tratados como no confiables y serán sanitizados y validados (usando class-validator en DTOs intermedios si es necesario) antes de cualquier operación de base de datos.
     • Se evitará la evaluación de fórmulas complejas o macros del archivo Excel si la librería lo permite.
  3. Procesamiento Asíncrono y Aislado en Colas (BullMQ): La funcionalidad de carga masiva se implementará para que el parseo y procesamiento del archivo ocurra en un "job" de una cola BullMQ, aislado del hilo principal de la aplicación. Esto limitará el impacto de un posible ReDoS al worker de la cola y permitirá aplicar timeouts y monitoreo específico a estos jobs.
  4. Monitoreo y Logging Específico: Se implementará logging detallado durante el proceso de importación para detectar archivos problemáticos, errores de parseo o comportamientos anómalos.
  5. Educación al Administrador del Loteo: Se proveerá una plantilla Excel muy clara y se indicará que solo se procesarán archivos que sigan estrictamente ese formato.
  6. Aceptación del Riesgo (Controlado y Temporal): Se acepta el riesgo residual de usar xlsx para el desarrollo inicial del "Release 1 Comercial" ÚNICAMENTE si las mitigaciones anteriores (especialmente validación estricta y procesamiento en cola) se implementan rigurosamente, y mientras se investiga una alternativa.

2.2. Vulnerabilidades en Cadena de Dependencias de mjml (vía @nestjs-modules/mailer)

• Vulnerabilidades Reportadas:
  • clean-css <4.1.11 (ReDoS) vía html-minifier.
  • jquery <=3.4.1 (XSS).
  • lodash.pick (Prototype Pollution) vía cheerio.
  • nth-check <2.0.1 (ReDoS) vía css-select.
  • request (SSRF) y tough-cookie (Prototype Pollution) vía jsdom.
• Librería Principal Afectada en el Proyecto: @nestjs-modules/mailer (actualmente en v1.11.2) a través de su dependencia (opcional para la funcionalidad central) mjml.
• Fix Automático Disponible: npm audit fix --force sugiere que podría intentar instalar [email protected] pero advierte de "