Un despliegue que depende del análisis de seguridad con GitHub Actions
Autor: Jhony Vargas Luque. Proyecto desarrollado junto con Gabriela Estefania Cohaila Alvarado. Un análisis de vulnerabilidades es más útil cuando participa en la decisión de publicar una versión. En este proyecto const
Autor: Jhony Vargas Luque. Proyecto desarrollado junto con Gabriela Estefania Cohaila Alvarado.
Un análisis de vulnerabilidades es más útil cuando participa en la decisión de publicar una versión. En este proyecto construimos Notas Seguras, una aplicación web de tareas, y conectamos sus pruebas y escaneos con GitHub Actions. La aplicación pública en GitHub Pages se actualiza solo cuando la versión corregida supera los controles configurados.
Este artículo complementa el de Gabriela. Ella explica los hallazgos de XSS y eval y sus correcciones; aquí explico cómo esos controles se incorporaron al despliegue automatizado.
Proyecto y evidencias
- Repositorio público.
- Aplicación pública en GitHub Pages.
- Ejecución comprobada de GitHub Actions.
- Evidencias del análisis.
- Video público del equipo, de máximo cinco minutos: https://youtu.be/xo5pPVDiBDA.
Notas Seguras permite crear, buscar, filtrar, completar y eliminar tareas. Está desarrollada con HTML, CSS y JavaScript. Usa localStorage del navegador, sin cuentas, sincronización ni backend de negocio.
El repositorio separa examples/vulnerable/, con componentes educativos inseguros, de app/, con la aplicación corregida. La baseline nunca se despliega: la construcción copia de forma explícita únicamente seis archivos de app/ al resultado de publicación.
Herramientas seleccionadas
Las guías de laboratorio revisadas usan SonarQube/SonarCloud, Snyk, Semgrep y tfsec. Para este trabajo utilizamos Bearer CLI 2.1.1 y ESLint 10.12.0 con eslint-plugin-no-unsanitized 4.1.5, herramientas que no aparecen en esas guías. Bearer figura en el catálogo de OWASP y en el directorio de NIST.
Bearer detectó dos inserciones HTML inseguras en la baseline. ESLint detectó los mismos dos puntos y un uso adicional de eval. Tras las correcciones, Bearer y ESLint terminaron sin hallazgos sobre la aplicación publicada, y las cinco pruebas de regresión pasaron.
Pipeline de seguridad y publicación
El archivo .github/workflows/security-and-deploy.yml se activa con un push a main, una solicitud de cambio o una ejecución manual. En una solicitud de cambio se realizan controles, pero no se publica. Para cambios en main, el trabajo security realiza esta secuencia:
- Descarga el código y configura Node.js 24.
- Instala dependencias reproducibles con
npm ci. - Ejecuta las cinco pruebas de regresión.
- Analiza la baseline y la aplicación con ESLint.
- Descarga Bearer, comprueba el SHA256 de la versión oficial y analiza ambos alcances.
- Genera el resumen, conserva los informes y construye la app.
El despliegue depende del trabajo anterior:
deploy:
needs: security
permissions:
pages: write
id-token: write
needs: security evita que una nueva versión se publique antes de que los controles hayan terminado correctamente. Si falla una prueba, el escaneo de app/ o la construcción, esa nueva versión no llega a GitHub Pages. El sitio que ya estaba publicado puede seguir disponible, pero el cambio con fallos no se despliega.
El trabajo de seguridad tiene permiso de lectura. Los permisos para publicar Pages se entregan solo en el trabajo de despliegue, por lo que no se necesita guardar una clave personal de nube en el código.
Evitar que el pipeline oculte fallos
La baseline contiene problemas intencionales. Por eso su análisis con Bearer espera un código de salida 1. Esa excepción no se usa para app/: el código publicable debe terminar con éxito normal, sin forzar --exit-code 0 ni utilizar continue-on-error.
El comparador de ESLint exige tres errores en los ejemplos y cero en la aplicación. Así se comprueba que la baseline sigue siendo analizada y que el resultado final no se consigue desactivando reglas.
| Medición | Componentes vulnerables | Aplicación corregida |
|---|---|---|
| Bearer CLI | 2 hallazgos altos | 0 |
| ESLint con reglas de seguridad | 3 errores | 0 |
| Pruebas automatizadas | No aplica | 5 aprobadas |
Los dos hallazgos de Bearer y los dos hallazgos de inserción HTML de ESLint describen los mismos dos puntos de código. No deben sumarse como cuatro vulnerabilidades únicas. El uso de eval fue reportado por ESLint en este ejemplo y no por Bearer.
Reproducibilidad y publicación
Los informes se conservan como artefacto security-reports de GitHub Actions y existe una copia de referencia en evidence/. Para repetir los controles:
npm ci
npm test
npm run scan:eslint
bash scripts/install-bearer.sh
bash scripts/scan-bearer.sh
node scripts/summarize.mjs
npm run build
Los scripts de Bearer requieren Linux x86_64 o Ubuntu en WSL. El instalador descarga la versión oficial y comprueba su SHA256. Las acciones de GitHub están fijadas por SHA de commit y las dependencias por package-lock.json.
GitHub Pages cumple el requisito de proveedor SaaS público: aloja la aplicación estática por HTTPS. GitHub Actions automatiza el análisis, la construcción y el despliegue. Se utiliza un repositorio público y runners estándar, sin contratar un servicio de pago.
Conclusión
La automatización convierte el análisis en una condición de publicación. La versión corregida solo se despliega después de superar pruebas, ESLint y Bearer. La combinación de herramientas aportó cobertura complementaria: Bearer encontró los usos de HTML inseguro y ESLint añadió el caso de eval.
Cero hallazgos describe el alcance, las versiones y las reglas ejecutadas; no significa seguridad absoluta. No se realizaron pruebas dinámicas, una auditoría completa de infraestructura ni un análisis exhaustivo de dependencias. Esta limitación forma parte de una presentación responsable de los resultados.
Referencias
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.