DEV Community: STEVIE GERALD MARCA AGUILAR

Seguridad automatizada en la nube: integración de Semgrep, Gitleaks y Trivy en un pipeline CI/CD

STEVIE GERALD MARCA AGUILAR — Fri, 16 Oct 2026 14:36:22 +0000

Por: Stevie Gerald Marca Aguilar y Usher Damiron Halanocca Rojas

Durante nuestro proyecto, integramos Semgrep, Gitleaks y Trivy en un pipeline de GitHub Actions, conectado al despliegue de una aplicación en Render. El propósito fue establecer una revisión automática de seguridad antes de autorizar la publicación de una nueva versión.

En este artículo explico cómo organizamos la solución, qué función cumple cada herramienta y qué aprendimos al analizar una aplicación con vulnerabilidades incorporadas intencionalmente.

¿Por qué incorporar seguridad al pipeline?

Durante el desarrollo pueden aparecer problemas que pasan desapercibidos en una revisión funcional. Por ejemplo, una aplicación puede permitir iniciar sesión correctamente y, al mismo tiempo, construir consultas SQL mediante concatenación o tener una clave privada escrita en sus archivos.

Entre los riesgos que consideramos estuvieron:

Credenciales y tokens almacenados directamente en el repositorio.
Dependencias con vulnerabilidades publicadas.
Consultas SQL construidas con datos ingresados por el usuario.
Ejecución de código mediante funciones inseguras.
Registro de información sensible en los mensajes de la aplicación.

Revisar estos aspectos manualmente en cada cambio requiere tiempo y puede producir omisiones. Por ello, incorporamos herramientas que ejecutan controles de forma automática y entregan resultados para su revisión.

Las herramientas utilizadas

Seleccionamos tres herramientas de código abierto que cubren aspectos diferentes del proyecto.

Herramienta	Tipo de análisis	Propósito en el proyecto
Semgrep	Análisis estático de código, SAST	Identificar patrones de programación potencialmente inseguros.
Gitleaks	Detección de secretos	Buscar credenciales y otros datos sensibles en el repositorio.
Trivy	Análisis de dependencias y configuración	Identificar vulnerabilidades conocidas y configuraciones inseguras.

Semgrep: revisión del código fuente

Semgrep analiza el código mediante reglas que describen patrones que queremos identificar. En nuestro caso, lo utilizamos para revisar una aplicación desarrollada con Node.js y Express.

El análisis se orientó a encontrar construcciones como consultas SQL inseguras, uso de eval() y otras prácticas que pueden comprometer la aplicación.

Su utilidad depende de las reglas seleccionadas y del contexto del código. Por eso, los resultados necesitan una revisión para determinar cuáles representan problemas reales.

Gitleaks: búsqueda de credenciales expuestas

Gitleaks permite detectar posibles secretos, como tokens, claves de acceso y credenciales incluidas en archivos versionados.

En el proyecto lo empleamos para revisar el repositorio y su historial disponible. Esto es relevante porque eliminar una contraseña del archivo actual no significa que desaparezca de los commits anteriores.

La detección tampoco debe considerarse infalible: algunas credenciales requieren reglas específicas y ciertos ejemplos pueden generar alertas que necesitan revisión.

Trivy: revisión de dependencias y configuraciones

Trivy permite analizar distintas partes de una aplicación, entre ellas sus dependencias, imágenes de contenedores y archivos de configuración compatibles.

En nuestra implementación lo utilizamos principalmente para identificar vulnerabilidades conocidas en las bibliotecas del proyecto. También exploramos el análisis de configuraciones, como las incluidas en un Dockerfile.

Sus reportes ayudan a reconocer qué componente está afectado y, cuando existe información disponible, qué versión incorpora una corrección.

La aplicación de demostración

Para evaluar las herramientas desarrollamos una API REST con Node.js y Express. La aplicación incluía funciones de autenticación, administración de usuarios y búsqueda.

Incorporamos errores de seguridad de manera intencional para observar el comportamiento de los escáneres.

Uno de los casos consistió en declarar un secreto directamente en el código:

const JWT_SECRET = 'clave_de_prueba_insegura';

También incluimos una consulta SQL construida con datos del usuario:

const query =
  `SELECT * FROM users WHERE username = '${username}'`;

Otro ejemplo fue la ejecución dinámica de una transformación:

const fn = eval(`(${transform})`);

Finalmente, agregamos registros que exponían contraseñas y versiones antiguas de algunas dependencias.

Estos casos permitieron comparar los distintos enfoques de análisis. Cada herramienta revisó una parte diferente del problema.

Ejecución de los análisis

Antes de configurar la automatización, ejecutamos las herramientas localmente para comprender sus resultados.

Análisis con Semgrep

Utilizamos conjuntos de reglas relacionados con Node.js, JavaScript y riesgos de seguridad web:

pip install semgrep

semgrep --config "p/nodejs" \
        --config "p/javascript" \
        --config "p/owasp-top-ten" \
        app/

La revisión permitió identificar patrones que debían evaluarse y corregirse dentro de la aplicación.

Análisis con Gitleaks

En la implementación descrita utilizamos el siguiente comando:

gitleaks detect --source . -v

El objetivo fue buscar posibles credenciales expuestas en el repositorio. El alcance efectivo de la revisión depende del historial disponible y de la configuración del escaneo.

Análisis con Trivy

Para revisar las dependencias ejecutamos:

trivy fs ./app

También realizamos un análisis de configuración:

trivy config .

Estos resultados permitieron identificar componentes y configuraciones que requerían atención.

Correcciones realizadas

Después de revisar los hallazgos, aplicamos cambios en el código y en la gestión de dependencias.

1. Uso de variables de entorno

Reemplazamos los secretos escritos directamente en los archivos por valores obtenidos desde el entorno:

const JWT_SECRET = process.env.JWT_SECRET;

if (!JWT_SECRET) {
  throw new Error('La variable JWT_SECRET no está configurada');
}

Esto permite configurar la credencial sin incluirla en el código fuente. Si una credencial real ya fue expuesta, también debe revocarse o reemplazarse; retirarla del archivo no resuelve por sí solo la exposición anterior.

2. Consultas parametrizadas

Sustituimos la concatenación de datos por parámetros:

const query = 'SELECT * FROM users WHERE username = ?';

db.get(query, [username], callback);

Así, el valor ingresado se proporciona por separado de la estructura de la consulta.

3. Sustitución de `eval()`

Reemplazamos la ejecución dinámica por un conjunto definido de operaciones permitidas:

const TRANSFORMS = {
  uppercase: (user) => ({
    ...user,
    username: user.username.toUpperCase()
  })
};

const fn = TRANSFORMS[transform];

if (!fn) {
  throw new Error('Transformación no permitida');
}

De esta manera, la aplicación selecciona una operación previamente implementada.

4. Actualización de dependencias

Revisamos las bibliotecas señaladas por Trivy y actualizamos las versiones correspondientes. Después repetimos los análisis para comprobar el efecto de las correcciones.

Resultados de la experiencia

Los resultados reportados en el proyecto mostraron una reducción de los hallazgos después de aplicar los cambios.

Herramienta	Resultado inicial reportado	Resultado posterior reportado
Semgrep	9 hallazgos	1 hallazgo, considerado falso positivo tras su revisión.
Gitleaks	3 posibles secretos	0 hallazgos en la revisión posterior.
Trivy	4 vulnerabilidades	0 vulnerabilidades críticas reportadas.

En Trivy, no encontrar vulnerabilidades críticas no equivale a no tener vulnerabilidades de otras severidades. La interpretación del resultado debe considerar los filtros utilizados.

Asimismo, la ausencia de alertas en cualquiera de las herramientas no garantiza que la aplicación esté libre de problemas de seguridad.

Integración con GitHub Actions

Una vez realizadas las pruebas locales, incorporamos los análisis al flujo automatizado del repositorio.

El pipeline se configuró para ejecutarse con los cambios enviados a la rama main. Organizamos el proceso en cuatro trabajos:

Análisis estático con Semgrep.
Detección de secretos con Gitleaks.
Revisión de dependencias con Trivy.
Solicitud de despliegue a Render.

La dependencia del trabajo de despliegue se expresó de esta forma:

deploy:
  needs: [semgrep, gitleaks, trivy]

Esto hace que ese trabajo espere la finalización satisfactoria de los tres análisis.

Para disponer del historial completo durante la revisión del repositorio, utilizamos:

with:
  fetch-depth: 0

En el análisis de Trivy configuramos el bloqueo ante vulnerabilidades críticas:

severity: 'CRITICAL'
exit-code: '1'

Por tanto, el criterio de aprobación de este análisis estuvo limitado a dicha severidad. Los hallazgos de niveles inferiores requieren una política adicional si también se desea bloquear el despliegue por ellos.

Despliegue de la aplicación en Render

Utilizamos Render como plataforma de despliegue de la API. La configuración del servicio definió el directorio de la aplicación, los comandos de instalación y ejecución, y la ruta de comprobación de salud.

services:
  - type: web
    name: vulnerable-demo-api
    runtime: node
    rootDir: app
    buildCommand: npm install
    startCommand: node server.js
    healthCheckPath: /health
    envVars:
      - key: JWT_SECRET
        sync: false

La solicitud de despliegue se realizó mediante un webhook cuya dirección se almacenó en GitHub Secrets como RENDER_DEPLOY_HOOK_URL.

El flujo planteado fue que GitHub Actions solicitara la publicación después de aprobar los controles. Para que esta condición se cumpla en toda la solución, la configuración de Render también debe evitar despliegues automáticos que omitan ese flujo.

Aprendizajes del proyecto

Integrar seguridad desde el desarrollo facilita detectar problemas antes de publicar. Los análisis automáticos aportan una revisión repetible en cada ejecución del pipeline.

Las herramientas se complementan. Semgrep revisa patrones del código, Gitleaks busca posibles secretos y Trivy analiza componentes y configuraciones compatibles.

Los reportes necesitan interpretación. Una alerta debe revisarse considerando el contexto, mientras que un análisis aprobado debe entenderse según sus reglas, filtros y alcance.

La gestión de secretos requiere más que eliminarlos del código. También es necesario proteger su almacenamiento y reemplazar cualquier credencial real que haya quedado expuesta.

Mantener las dependencias actualizadas es una tarea continua. Una versión sin alertas hoy puede presentar vulnerabilidades conocidas posteriormente.

Este proyecto nos permitió incorporar controles de seguridad al proceso de entrega de software y comprender cómo conectarlos con un despliegue en la nube. Además de ejecutar herramientas, aprendimos a revisar sus resultados y a definir qué condiciones deben cumplirse antes de publicar una nueva versión.

Aplicativo Prueba: https://articulo-marca-usher.onrender.com/
Video:https://studio.youtube.com/video/1DI_BEcRcOk/edit
Git Hub: https://github.com/Stevien04/Articulo-Marca-Usher.git

Respaldo y recuperación de MySQL con Railway Aiven y GitHub Actions

STEVIE GERALD MARCA AGUILAR — Sun, 04 Oct 2026 05:06:11 +0000

Integrantes:
Stevie Gerald Marca Aguilar
Soanny Geraldine Rivas Gutierrez

INTRODUCCIÓN
Un inventario necesita conservar información fiable sobre las existencias y los precios. Si se elimina un registro o se modifica por error, una copia anterior permite recuperar su contenido. El código del repositorio reconstruye la aplicación, pero recuperar los datos requiere un respaldo de MySQL.
El proyecto combina una aplicación de inventario en Node.js y Express con una base MySQL. Los scripts generan una exportación completa, la comprimen y la protegen mediante cifrado. GitHub Actions incluye un flujo diario de respaldo, mientras Railway publica la aplicación y la configuración contempla una conexión a MySQL administrado en Aiven.
El documento describe la arquitectura, la preparación del entorno y el procedimiento de recuperación. Incluye las pruebas locales reportadas y las capturas de la publicación del repositorio y de una ejecución manual del backup. La aplicación pública responde y confirma su conexión con MySQL; la ejecución diaria programada debe comprobarse en el historial de Actions.

1. Arquitectura del inventario
El inventario permite listar productos, registrar nuevas entradas y eliminar registros. Cada producto contiene ID, nombre, precio, cantidad disponible y fecha de creación. Este modelo facilita comparar la información original con los datos obtenidos después de restaurar una copia.

La Tabla 1 presenta componentes y responsabilidades de la solución.
Tabla 1
Componentes y responsabilidades de la solución

Las pruebas de desarrollo se realizan en el entorno local. Railway ejecuta la API en la nube y la configuración de conexión permite utilizar MySQL en Aiven. El proceso de Actions accede a la base configurada y conserva la copia como artefacto cifrado. El repositorio almacena el código; los archivos de respaldo se descargan aparte y tienen una retención limitada.

Criterios para conservar las copias Para esta base de demostración se eligió una exportación lógica completa. La copia reúne las tablas y sus registros en un archivo SQL que puede revisarse después del descifrado. El procedimiento no incluye respaldos incrementales ni recuperación a un instante específico mediante binlogs.

La Tabla 2 reúne la frecuencia, la conservación y las condiciones necesarias para recuperar una copia.

Una copia diaria exitosa permite recuperar el estado guardado en la última ejecución. Por ello, podrían perderse los cambios posteriores, aproximadamente los de un día si se cumple el horario. Los fallos o retrasos aumentan ese intervalo. El tiempo de recuperación debe medirse con la cantidad real de datos; este proyecto no garantiza un RTO concreto.

3. Organización y puesta en marcha

El proyecto organiza la API, la interfaz y las herramientas de mantenimiento en carpetas separadas. Los archivos de configuración permiten reproducir el entorno local y definir los procesos de pruebas, publicación y respaldo. La Tabla 3 identifica sus elementos principales.

En Windows se prepara el archivo de variables a partir de la plantilla y se asignan claves propias. Docker Desktop debe utilizar contenedores Linux. Desde la carpeta del proyecto, estos comandos levantan los servicios y consultan su estado.

Los datos de MySQL permanecen en un volumen de Docker. MYSQL_DATABASE, MYSQL_USER y MYSQL_PASSWORD se aplican al inicializar un volumen nuevo. Cambiar esos valores posteriormente no actualiza las cuentas existentes. La aplicación establece la conexión con DB_HOST, DB_PORT, DB_USER, DB_PASSWORD y DB_NAME.
La configuración de laboratorio admite DB_SSL=false en la red local. La conexión externa a Aiven requiere DB_SSL=true y su certificado CA. La comprobación TLS debe validar la confianza del certificado y el nombre del servidor.

*4.Estructura de datos y operaciones de la API
*

La tabla productos usa InnoDB y guarda el precio con dos decimales. El stock no admite cantidades negativas. El SQL actúa sobre la base seleccionada por la conexión, sin imponer un nombre mediante USE; así puede importarse en una base de recuperación distinta.

La API ofrece consultas públicas y operaciones de escritura protegidas. Registrar o eliminar productos exige enviar X-API-Key, cuyo valor se define en ADMIN_API_KEY. También se comprueba que el precio sea numérico y no negativo, con hasta dos decimales, y que el stock sea un entero no negativo.

Las rutas y sus funciones se presentan en la Tabla 4.

5.Generación y protección del respaldo

Antes de exportar, backup.sh comprueba la configuración y crea un espacio temporal privado. La contraseña se entrega al cliente MySQL mediante un archivo de opciones, evitando incluirla en los argumentos del proceso. Ese archivo se retira cuando finaliza la ejecución.
La exportación se realiza con las siguientes opciones de mysqldump.

La opción --single-transaction obtiene una vista consistente de los datos en tablas InnoDB. Mientras se genera la copia deben evitarse cambios de estructura como ALTER, DROP y TRUNCATE. La exportación cubre la base de la aplicación, pero no incluye las cuentas del servidor, los procedimientos ni los eventos (Oracle, s. f.).
Una vez validada la compresión, crypto.js obtiene la clave mediante scrypt y una sal aleatoria. AES 256 GCM protege el contenido con un nonce aleatorio y una etiqueta de autenticación. El archivo se identifica con la fecha y un valor aleatorio, y se acompaña de un checksum SHA 256. La frase de cifrado debe conservarse por separado mientras se necesiten las copias.
El respaldo local puede ejecutarse desde PowerShell utilizando el contenedor de herramientas.
docker compose --profile tools run --rm tools scripts/backup.sh
Get-ChildItem backups
El archivo .sql.gz.enc contiene datos comprimidos y cifrados; requiere el procedimiento de descifrado antes de leer el SQL. Debe conservarse junto a su archivo de checksum. La retención local elimina copias por antigüedad: siete días no significan necesariamente siete archivos, porque pueden realizarse varias ejecuciones en una misma fecha.

*6.Restauración y comprobación de los datos
*

El script restore.sh recupera la información en otra base para proteger el inventario activo. Primero exige que el destino sea diferente de DB_NAME y esté vacío. Después comprueba el checksum, valida el descifrado y revisa el archivo comprimido antes de importar el SQL.
En el entorno de práctica, una cuenta administradora prepara la base de destino y otorga los permisos necesarios al usuario utilizado por el proyecto.

La prueba local reportada se ejecutó con MySQL 8.0.46. Se añadió un cuarto producto y se generó el respaldo. Al restaurarlo, se verificaron las cuatro filas y la igualdad de sus campos. Después se eliminó el registro de prueba desde la API y se comprobó que continuaba disponible en la base recuperada.

También se verificó que el procedimiento rechazara una copia alterada, un destino con tablas y un destino con el mismo nombre de la base activa. La importación completa no constituye una operación atómica: ante un fallo parcial, hay que revisar los objetos creados antes de repetirla.

*7.Conexión de MySQL y publicación en Railway
*

Para utilizar MySQL en Aiven se toman de su consola el host, el puerto, el usuario, la contraseña y la base, además del certificado CA. Deben emplearse los valores reales del servicio: la base puede ser defaultdb y el puerto puede diferir de 3306. Las guías de conexión explican estos parámetros y el uso del certificado (Aiven, s. f.-a, s. f.-b).
Railway ejecuta el servicio Node.js a partir del Dockerfile. Las variables de entorno indican cómo conectarse a MySQL. El archivo railway.json ejecuta la inicialización antes del despliegue y utiliza /health para revisar el servicio. La inicialización está preparada para conservar una tabla que ya exista.

La aplicación publicada dispone de un dominio de Railway. En la comprobación realizada, la página devolvió HTTP 200 y /health respondió con status ok y database MySQL. El servicio escucha en 0.0.0.0 y toma el puerto del entorno. Esta respuesta confirma conectividad con MySQL, pero por sí sola no identifica su proveedor.
El runner de GitHub Actions necesita acceso de red a la base remota. Si se restringen las direcciones permitidas, debe habilitarse la salida del runner o utilizar uno autorizado. Los valores sensibles se almacenan en Secrets y la conexión externa mantiene la verificación TLS.

**
8.Validación del código y publicación automática**

La automatización distingue las pruebas del código, el despliegue y la copia de datos. El archivo ci.yml define pruebas de API y cifrado y una recuperación con MySQL 8.4. El flujo deploy.yml espera el resultado de CI en main para publicar el commit que superó las comprobaciones.
El flujo de despliegue recibe la finalización de CI mediante este evento.

El despliegue exige una ejecución de CI exitosa originada por un push del propio repositorio y la variable DEPLOY_ENABLED=true. Utiliza RAILWAY_TOKEN y RAILWAY_SERVICE_ID para seleccionar el servicio. Railway describe los Project Tokens para esta automatización (Railway, s. f.-a).

Después de railway up se consulta /health en el dominio público. Para comprobar el flujo completo puede modificarse un texto visible, enviar el commit a main y revisar CI, el despliegue y el cambio publicado. Conviene elegir un único mecanismo de publicación para evitar ejecuciones duplicadas. La documentación de railway up describe su comportamiento y opciones (Railway, s. f.-b).

9. Copias remotas mediante GitHub Actions

El flujo backup.yml construye un contenedor con el cliente MySQL 8.4 y llama al mismo script usado en las pruebas locales. Las credenciales de la base y la frase de cifrado se obtienen de Secrets. El artefacto conserva el resultado cifrado y su checksum.
Estas definiciones establecen el horario previsto y la conservación del artefacto.

La ejecución requiere BACKUP_ENABLED=true. Se configuran DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME, DB_SSL_CA y BACKUP_PASSPHRASE como Secrets. Para Aiven, BACKUP_DB_SSL debe estar en true. La cuenta de respaldo necesita acceso de lectura y los permisos de los objetos incluidos en la exportación.
La captura incorporada muestra una ejecución iniciada con workflow_dispatch que terminó correctamente y produjo un artefacto descargable. Este resultado acredita una prueba manual. Para verificar el horario diario hay que revisar una ejecución identificada como Scheduled. También debe descargarse la copia y comprobar su restauración en una base vacía usando la misma frase de cifrado.
Los artefactos se descargan desde la página de la ejecución en GitHub Actions; git clone solo obtiene los archivos versionados del repositorio (GitHub, s. f.).

*10. Resultados y evidencias del proyecto
*

La Figura 5 documenta el registro de un producto en el inventario local. Esta prueba permite observar la validación y la actualización de la lista, pero no demuestra por sí misma una recuperación ni un despliegue remoto.

Las pruebas de recuperación reportadas corresponden a MySQL 8.0.46. El entorno de Docker y los workflows emplean MySQL 8.4. Las nuevas capturas documentan el repositorio público y un backup manual exitoso. La respuesta de /health confirma que la aplicación pública llega a MySQL. Aún debe documentarse la ejecución programada y la restauración del respaldo remoto.

Conclusiones

El ejercicio de restauración permitió recuperar un estado anterior del inventario y comparar sus registros. Trabajar con una base de destino independiente evitó sobrescribir los datos activos durante la validación.
La propuesta integra la comprobación del software, su publicación y la protección de sus datos en flujos separados. Railway mantiene accesible la API; la configuración permite conectar MySQL en Aiven, y GitHub Actions ejecuta las tareas definidas en el repositorio.
Para una demostración con pocos datos, la exportación completa ofrece un procedimiento fácil de revisar. Un uso en producción requeriría definir el RPO y la retención según el negocio, añadir alertas y ensayos de recuperación y guardar otra copia independiente. El proyecto no implementa por sí solo una estrategia completa 3 2 1 ni recuperación PITR.

Enlaces de la entrega Repositorio público del proyecto: https://github.com/Soanny/mysql-backup-strategy_Stevie-Marca_Soanny-Rivas Aplicación pública en Railway: https://mysql-backup-strategystevie-marcasoanny-rivas-production.up.railway.app/ Video público de máximo cinco minutos: https://www.youtube.com/watch?v=ViPQl8gZ20U

Referencias
Aiven. (s. f.-a). Connect to Aiven for MySQL® from the command line. Recuperado el 3 de octubre de 2026, de https://aiven.io/docs/products/mysql/howto/connect-from-clI
Aiven. (s. f.-b). Connect to Aiven for MySQL® with MySQL Workbench. Recuperado el 3 de octubre de 2026, de https://aiven.io/docs/products/mysql/howto/connect-from-mysql-workbench
GitHub. (s. f.). Downloading workflow artifacts. Recuperado el 3 de octubre de 2026, de https://docs.github.com/en/actions/how-tos/manage-workflow-runs/download-workflow-artifacts
Oracle. (s. f.). 6.5.4 mysqldump — A database backup program. Recuperado el 3 de octubre de 2026, de https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html
Railway. (s. f.-a). Deploying with the CLI. Recuperado el 3 de octubre de 2026, de https://docs.railway.com/cli/deploying
Railway. (s. f.-b). railway up. Recuperado el 3 de octubre de 2026, de https://docs.railway.com/cli/up