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
Top comments (0)