DEV Community: Milton H

Análisis de seguridad de TestGenAI con ESLint Security y GitHub Actions

Milton H — Thu, 08 Oct 2026 01:27:54 +0000

Autor: Milton H. Flores Chino

TestGenAI es nuestro proyecto de Calidad y Pruebas de Software: una aplicación web para organizar requisitos, generar especificaciones y casos de prueba, revisar sus resultados y mantener trazabilidad. En esta revisión incorporé ESLint Security para analizar el código TypeScript con una herramienta distinta de Sonar, Semgrep y Snyk, utilizados en los laboratorios del curso.

El propósito fue obtener resultados reproducibles, revisar qué significaban las alertas y comprobar que las correcciones conservaban el comportamiento del sistema.

La aplicación y su arquitectura

El frontend utiliza HTML, CSS y JavaScript modular. El backend expone una API con Express y TypeScript, y conserva la información en PostgreSQL mediante Prisma. El sistema incluye un motor determinista de especificación y diseño de pruebas, además de adaptadores opcionales para Gemini y OpenAI.

La generación de casos no sustituye la revisión humana. Los requisitos, casos, revisiones, sesiones y ejecuciones se almacenan mediante doce modelos Prisma. El dashboard calcula cobertura de requisitos y distribución de estados a partir de los datos del proyecto.

Una herramienta diferente para el análisis estático

ESLint Security incorpora reglas para señalar patrones que pueden requerir revisión: accesos dinámicos a objetos, expresiones regulares potencialmente problemáticas, uso de eval y otras operaciones sensibles de Node.js. La documentación del plugin advierte que muchos resultados son falsos positivos y requieren clasificación humana.

Fuente: https://github.com/eslint-community/eslint-plugin-security

Instalé el plugin como dependencia de desarrollo y utilicé una configuración separada con el parser TypeScript y las reglas recomendadas. La configuración conserva las alertas; no elimina las reglas que detectaron resultados.

Comandos reproducibles desde backend:

npm ci
npm run prisma:generate
npm run security:scan
npm test

El alcance del análisis de seguridad es backend/src. Los tests, dependencias instaladas y archivos compilados no se incluyen en ese conteo.

Qué encontró el análisis

El análisis inicial encontró 50 alertas de seguridad: 39 accesos dinámicos a objetos, 10 expresiones regulares señaladas como potencialmente inseguras y un constructor RegExp no literal.

Estos resultados no equivalen a cincuenta vulnerabilidades confirmadas. Un acceso a un arreglo con un índice controlado o una expresión de longitud limitada pueden activar una regla sin demostrar una ruta explotable. La revisión debe comprobar quién controla la entrada, qué límites existen y cómo se usa el resultado.

La primera ejecución también reveló tres errores de configuración por comentarios de reglas TypeScript. Corregí la configuración cargando el plugin correspondiente; esos errores no forman parte del conteo de alertas de seguridad.

Corrección del patrón de tarjetas

Una alerta correspondía al patrón empleado para enmascarar números de tarjetas antes de enviar texto a un proveedor de IA. El patrón utilizaba una repetición anidada de bloques de cuatro dígitos.

Reescribí esa parte enumerando los cuatro grupos y sus separadores opcionales, conservando la alternativa para números de quince dígitos. La transformación elimina la alerta estática de ese patrón y conserva los formatos que la aplicación ya aceptaba. Esto no constituye una demostración de que la expresión original fuera explotable.

Añadí pruebas para números con espacios, con guiones y de quince dígitos. También comprobé que la función inversa restaura el dato original después del enmascaramiento.

El análisis posterior informa 49 alertas: 39 accesos dinámicos, 9 expresiones regulares y un RegExp no literal. Las restantes requieren revisión. No presento este resultado como una aplicación libre de vulnerabilidades.

La auditoría de dependencias como control complementario

El análisis de código y la auditoría de dependencias responden preguntas diferentes. npm audit identificó inicialmente 12 vulnerabilidades conocidas en el árbol instalado: 3 moderadas, 5 altas y 4 críticas.

Actualicé Vitest y la herramienta de cobertura a 4.1.11, lint-staged a 17.6.0 y dependencias compatibles. La consulta posterior de npm audit reportó cero vulnerabilidades conocidas. Este resultado se limita al árbol y a la información de la auditoría en el momento de ejecutarla.

La configuración de CI y Docker ahora utiliza Node.js 24, compatible con las herramientas actualizadas.

Automatización y evidencia

GitHub Actions ejecuta la instalación reproducible, el análisis de ESLint Security y la auditoría de dependencias. El workflow conserva el JSON del análisis como artefacto y añade un resumen con el número de archivos y alertas.

Los errores de ejecución provocan fallo. Las alertas de las reglas recomendadas se conservan para revisión y no equivalen automáticamente a un bloqueo del despliegue. Esa distinción evita confundir un job exitoso con la resolución de todos los problemas.

También corregí errores que impedían el pipeline anterior: la conexión SQLite cuando el backend exige PostgreSQL, el proveedor mock que ya no acepta la configuración y la referencia a un archivo Docker Compose inexistente.

La suite local posterior pasó 59 pruebas. El reporte de cobertura previo, con 52 pruebas, midió 16,43 % de líneas. La cobertura general sigue siendo limitada; no basta con contar pruebas aprobadas para dar por verificado todo el backend.

Como control complementario, la ejecución de Semgrep encontró una configuración AES-GCM sin longitud explícita de etiqueta en CryptoVault. Especifiqué authTagLength de 16 bytes tanto en cifrado como en descifrado. Dos pruebas verifican la restauración del texto y el rechazo de etiquetas alteradas o payloads incompletos. La nueva ejecución de Semgrep terminó con cero hallazgos de las reglas JavaScript y TypeScript seleccionadas; esto no resuelve las 49 alertas independientes de ESLint Security.

SonarQube Community también se ejecutó en un servicio temporal del runner. El primer análisis informó 192 bugs y 14 vulnerabilidades clasificadas por sus reglas. Después de sustituir la fuente de aleatoriedad por primitivas criptográficas y corregir las comprobaciones de longitud del visor de diferencias, reportó 190 bugs y cero vulnerabilidades. Las 190 alertas restantes corresponden a propiedades BDD llamadas then. La inspección de tipos confirmó datos no invocables; conservé la revisión como evidencia de candidatos a falso positivo, sin afirmar que su estado esté cerrado en SonarQube. En ambas consultas se reportaron cero hotspots.

Infraestructura y documentación

La configuración Terraform aprovisiona PostgreSQL y la aplicación mediante Docker dentro de un runner efímero, verifica su funcionamiento y destruye los recursos al terminar. Este entorno permite probar la infraestructura, pero no constituye por sí solo una publicación web persistente.

La prueba integrada pasó registro, creación de proyecto y requisito y consulta de métricas desde PostgreSQL. También corrigió una brecha de persistencia: la migración original creaba ocho tablas y el código utilizaba doce modelos. Añadí una migración aditiva y el workflow comprobó que el esquema aplicado coincide con Prisma.

La documentación automática se genera desde el esquema Prisma y el árbol de sintaxis TypeScript: diccionario de datos, entidad relación, clases, componentes, despliegue y detalles de métodos y propiedades. Cada evidencia debe vincularse con la revisión concreta del código analizado.

Lo aprendido

Esta revisión permitió distinguir alertas de código, vulnerabilidades conocidas en dependencias y errores de automatización. Una corrección útil necesita evidencia antes y después y pruebas que preserven el comportamiento esperado.

El trabajo continúa con la clasificación de las alertas pendientes y la ampliación de la cobertura. Mantener visibles esos límites permite evaluar el proyecto con sus resultados reales.

Enlaces del proyecto

Repositorio público autorizado, con una copia del código analizado:
https://github.com/miltom123/testgenai-sast

Aplicación publicada por el equipo:
https://testgenai-calidad.vercel.app/

Verifiqué su pantalla de inicio de sesión. Esa observación confirma el acceso público al frontend; no acredita el backend ni que Vercel haya desplegado la revisión analizada. La automatización Terraform descrita corresponde a un entorno de prueba efímero.

Documentación técnica publicada automáticamente en GitHub Pages:
https://miltom123.github.io/testgenai-sast/

Video del proceso, de menos de cinco minutos, con capturas reales y narración sintética genérica:
https://youtu.be/uVTdcjrnKI0

Ejecución pública ESLint Security:
https://github.com/miltom123/testgenai-sast/actions/runs/37712519312

CI y pruebas de la copia pública:
https://github.com/miltom123/testgenai-sast/actions/runs/37712519236

Semgrep:
https://github.com/miltom123/testgenai-sast/actions/runs/37712519238

Release y verificación Terraform:
https://github.com/miltom123/testgenai-sast/actions/runs/37712598185

Documentación y publicación en Pages:
https://github.com/miltom123/testgenai-sast/actions/runs/37712519237

Respaldos de PostgreSQL del entorno local a la nube con Docker y GitHub Actions

Milton H — Sat, 03 Oct 2026 22:33:14 +0000

Autor: Milton H. Flores Chino

Proyecto grupal de Base de Datos II, desarrollado junto con Yerry Maycol Tarqui Collatupa.

Una estrategia de respaldo debe permitir recuperar información y ejecutarse con regularidad. En nuestro proyecto trabajamos ese ciclo con PostgreSQL: preparación de datos, generación de copias, restauración en otra base y automatización de respaldos de una instancia en la nube.

En este artículo presento el recorrido del proyecto y mi análisis de las decisiones que tomamos. Utilizamos PostgreSQL, Docker, PowerShell, FastAPI, Render y GitHub Actions.

Enlaces del proyecto

Preparar un entorno reproducible

Comenzamos configurando PostgreSQL en Docker Compose. Separamos las credenciales del código mediante variables de entorno; el repositorio incluye una plantilla .env.example para facilitar la preparación de otra instalación.

Después creamos las tablas y cargamos datos de prueba con un script SQL. Estos datos nos dieron una referencia para comprobar que la aplicación podía consultar PostgreSQL y que una restauración recuperaba la información esperada.

Docker nos permitió organizar la base de datos y la aplicación en servicios. Para levantar el entorno del proyecto se utiliza:

docker compose up -d --build

Generar el respaldo y comprobar la recuperación

Implementamos un script de PowerShell para producir respaldos locales con pg_dump. Luego configuramos el Programador de tareas de Windows para ejecutar el script de forma periódica. La automatización local depende de que el equipo esté disponible en el horario previsto.

PostgreSQL permite generar un respaldo lógico en formato personalizado con -Fc y recuperarlo mediante pg_restore. Estos comandos ilustran el procedimiento; las variables de conexión deben configurarse para cada entorno:

pg_dump --dbname="$DATABASE_URL" -Fc --no-owner --no-privileges -f backup.dump
pg_restore --dbname="$RESTORE_DATABASE_URL" --no-owner --no-privileges backup.dump

La base de destino debe existir y ser independiente de la base de trabajo. Así se puede evaluar la recuperación sin sobrescribir los datos originales. En el desarrollo documentamos la selección del respaldo, su copia al contenedor, la creación de la base de destino y la restauración.

Según la documentación de PostgreSQL, un archivo de formato personalizado se restaura con pg_restore. Además, pg_dump respalda una base individual; los roles y otros objetos globales requieren un tratamiento adicional.

Mi principal conclusión de esta etapa es que guardar un archivo es solo una parte del proceso. La prueba de recuperación debe comprobar las tablas, los registros y las consultas que necesita la aplicación.

Consultar los datos desde FastAPI

Creamos una API con FastAPI para consultar los datos. Durante el desarrollo local comprobamos el estado del servicio, la conexión con PostgreSQL, el listado de productos y la documentación interactiva.

Los endpoints del proyecto son:

Endpoint	Propósito
`/`	Consultar el estado general de la API
`/health`	Comprobar la conexión con PostgreSQL
`/productos`	Consultar los productos almacenados
`/docs`	Explorar la documentación Swagger

La API ayuda a evaluar el sistema desde el punto de vista de quien consume los datos. Tras una recuperación, verificar consultas representativas permite detectar problemas que el tamaño del archivo de respaldo no revela.

Publicar en la nube y automatizar el despliegue

Publicamos el código en GitHub y desplegamos PostgreSQL y FastAPI en Render. La entrega incluye la dirección pública de Swagger para que se puedan revisar los endpoints.

También configuramos el despliegue automático: Render toma los cambios de la rama main del repositorio y genera un nuevo despliegue cuando se envían commits. En el informe registramos la modificación de la aplicación, el envío de los cambios y la verificación del proceso.

Este flujo permite mantener una relación clara entre la versión del código y la aplicación publicada. La automatización del despliegue y la automatización del respaldo resuelven necesidades distintas: una actualiza el servicio y la otra conserva una copia de los datos.

Respaldar PostgreSQL en Render con GitHub Actions

Para la instancia en la nube implementamos un workflow de GitHub Actions y un repositorio privado dedicado a los respaldos. De esta manera, la ejecución programada puede realizarse aunque nuestra computadora esté apagada.

El flujo genera una copia con pg_dump, comprueba que el archivo tenga contenido, lo cifra mediante OpenSSL y almacena el resultado con extensión .dump.enc. Las credenciales de conexión y la frase de cifrado se gestionan mediante GitHub Secrets.

La programación documentada utiliza 17 10 * * *: corresponde a las 10:17 UTC, es decir, a las 5:17 a. m. en Perú. El workflow también permite una ejecución manual para verificar su funcionamiento. El informe incluye evidencias de la ejecución manual, de una ejecución programada y de los archivos cifrados generados.

En el repositorio público puede consultarse una versión de ejemplo del workflow. Las copias reales permanecen en el repositorio privado destinado a respaldos.

Qué mejoraría en una siguiente versión

Para ampliar esta solución propondría definir una política de retención, alertas de fallo y pruebas periódicas de restauración. También mediría el tiempo necesario para recuperar el servicio y la cantidad de información que se podría perder entre dos respaldos.

Estas son mejoras propuestas, no funcionalidades que doy por implementadas en esta entrega. La comprobación de que un archivo existe y tiene contenido ayuda a detectar errores básicos, pero debe complementarse con una recuperación real. Asimismo, conviene conservar la clave de descifrado por separado y mantener copias en más de un destino.

Aprendizaje del proyecto

Este trabajo nos permitió conectar la administración de PostgreSQL con una aplicación desplegada y con procesos automáticos. Desde mi perspectiva, el valor de una estrategia de respaldo está en poder repetir la recuperación y demostrar que los datos vuelven a ser utilizables.

El código público, la aplicación en Render y el video enlazados al inicio reúnen los recursos de esta implementación. El desarrollo técnico es grupal y esta explicación corresponde a mi artículo individual sobre el proyecto.