DEV Community

ANA CECILIA ESTEBAN RAMOS
ANA CECILIA ESTEBAN RAMOS

Posted on

Integración de DevSecOps con Bearer SAST y GitHub Actions: detección, bloqueo y remediación de vulnerabilidades

#cicd #devops #github #security

Autores: Saúl José Alvarado Urbano y Ana Cecilia Esteban Ramos

Repositorio: github.com/saulalvarado1/Bearer_Articulo

API en producción: bearer-articulo.onrender.com

Resumen

En el desarrollo de software moderno, la seguridad no debería incorporarse únicamente al final del proyecto o antes de publicar una aplicación en producción. El enfoque Shift-Left propone integrar controles de seguridad desde las primeras etapas del ciclo de vida del desarrollo de software.

En este artículo presentamos la implementación práctica de un flujo DevSecOps aplicado a una API REST desarrollada con Node.js y Express.

Para automatizar el análisis de seguridad se configuró un pipeline de Integración Continua mediante GitHub Actions, incorporando Bearer CLI como herramienta de análisis estático de seguridad de aplicaciones o SAST.

El objetivo fue comprobar cómo una vulnerabilidad introducida intencionalmente dentro del código puede ser detectada automáticamente antes de continuar con el proceso de despliegue.

Para la demostración se simuló la exposición de información sensible dentro de los logs de autenticación. Bearer detectó el problema, marcó el hallazgo con severidad alta y provocó que el pipeline finalizara con error.

Posteriormente se realizó la corrección del código y se ejecutó nuevamente el análisis hasta obtener un pipeline exitoso, permitiendo continuar con el flujo de despliegue de la aplicación en Render.

1. Arquitectura y stack tecnológico

La solución integra desarrollo, control de versiones, análisis estático de seguridad, automatización y despliegue en la nube.

[ Desarrollador ]
        │
        │ git push
        ▼
[ Repositorio GitHub ]
        │
        │ Trigger del Workflow
        ▼
[ GitHub Actions ]
        │
        ├──► Checkout del código
        │
        ├──► Escaneo SAST con Bearer CLI
        │         │
        │         ├── HIGH / CRITICAL
        │         │         ▼
        │         │   ❌ Pipeline fallido
        │         │
        │         └── Sin hallazgos graves
        │                   ▼
        │             ✅ Pipeline exitoso
        ▼
[ Despliegue en Render ]
Enter fullscreen mode Exit fullscreen mode

Componentes principales

  • Backend: Node.js y Express.
  • Herramienta SAST: Bearer CLI.
  • Integración continua: GitHub Actions.
  • Repositorio de código: GitHub.
  • Entorno Cloud / PaaS: Render.
  • Tipo de análisis: Static Application Security Testing.

La integración de estas tecnologías permite detectar determinados problemas de seguridad durante el desarrollo y antes de que el código vulnerable llegue al entorno productivo.

2. Configuración del pipeline de seguridad

Para automatizar la verificación de seguridad en cada cambio realizado sobre el repositorio se creó el archivo:

.github/workflows/bearer-scan.yml
Enter fullscreen mode Exit fullscreen mode

El workflow utilizado fue el siguiente:

name: Bearer SAST Scan & Security Pipeline

on:
  push:
    branches: [ "main", "master" ]

  pull_request:
    branches: [ "main", "master" ]

jobs:
  security_scan:
    name: Bearer SAST Security Analysis
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Run Bearer CLI Scanner
        uses: bearer/bearer-action@v2
        with:
          severity: "high,critical"
          diff: false
Enter fullscreen mode Exit fullscreen mode

Este workflow se activa automáticamente cuando se realiza un push o un pull request sobre las ramas configuradas.

GitHub Actions descarga el código fuente mediante actions/checkout y posteriormente ejecuta Bearer para analizar posibles vulnerabilidades.

La opción:

severity: "high,critical"
Enter fullscreen mode Exit fullscreen mode

permite considerar especialmente los hallazgos clasificados con severidad alta o crítica.

3. ¿Por qué utilizar Bearer?

Bearer es una herramienta orientada al análisis estático de seguridad.

Su utilidad dentro de un flujo DevSecOps consiste en analizar el código fuente y detectar patrones relacionados con problemas de seguridad y manejo inadecuado de información sensible.

Entre los elementos que puede ayudar a analizar se encuentran:

  • Datos personales.
  • Credenciales.
  • Información sensible.
  • Entradas provenientes de usuarios.
  • Flujos de información hacia puntos potencialmente inseguros.

Esto permite incorporar seguridad dentro del proceso normal de desarrollo en lugar de dejar el análisis únicamente para una etapa final.

4. Introducción intencional de una vulnerabilidad

Para comprobar el funcionamiento del pipeline se introdujo intencionalmente una vulnerabilidad dentro del endpoint de autenticación:

/api/login
Enter fullscreen mode Exit fullscreen mode

El problema consistía en almacenar dentro de los logs tanto el correo electrónico como la contraseña ingresada por el usuario.

Código vulnerable 

app.post('/api/login', (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({
      error: 'Email y contraseña requeridos'
    });
  }

  // Datos sensibles enviados directamente a los logs
  console.log(
    `[AUTH-LOG] Intento de login para usuario: ${email} con credencial: ${password}`
  );

  const user = users.find(u => u.email === email);

  if (user && password === 'admin123') {
    return res.json({
      message: 'Autenticación exitosa',
      token: 'jwt-simulated-token-bearer-demo',
      user: {
        id: user.id,
        email: user.email,
        name: user.name
      }
    });
  }

  return res.status(401).json({
    error: 'Credenciales inválidas'
  });
});
Enter fullscreen mode Exit fullscreen mode

La parte problemática se encuentra en:

console.log(
  `[AUTH-LOG] Intento de login para usuario: ${email} con credencial: ${password}`
);
Enter fullscreen mode Exit fullscreen mode

La contraseña y otros datos proporcionados por el usuario son enviados directamente a los logs.

Esto representa un riesgo porque los registros de una aplicación pueden almacenarse durante largos periodos, ser consultados por administradores o integrarse con servicios externos de monitoreo.

5. Detección automática de la vulnerabilidad

Después de introducir el código vulnerable se realizó un nuevo push al repositorio remoto.

GitHub Actions detectó el cambio y ejecutó automáticamente el workflow configurado.

Bearer analizó el proyecto y detectó un hallazgo de severidad HIGH.

Resultado del análisis 

HIGH: Unsanitized user input in format string [CWE-134]

File: server.js:54

54  console.log(
      `[AUTH-LOG] Intento de login para usuario: ${email}
      con credencial: ${password}`
    );

87 checks, 1 findings

CRITICAL: 0
HIGH: 1 (CWE-134)

Error: Process completed with exit code 1.
Enter fullscreen mode Exit fullscreen mode

Al detectar el hallazgo, el proceso terminó con código de salida 1.

El flujo quedó de la siguiente manera:

Código vulnerable
      │
      ▼
GitHub Actions
      │
      ▼
Bearer SAST
      │
      ▼
Hallazgo HIGH
      │
      ▼
❌ Pipeline fallido
Enter fullscreen mode Exit fullscreen mode

Este comportamiento permite utilizar el análisis de seguridad como una compuerta de calidad, evitando que determinados cambios inseguros continúen normalmente dentro del flujo de integración.

6. Impacto del problema detectado

Registrar credenciales o información sensible directamente dentro de los logs puede provocar exposición de datos.

Por ejemplo, una contraseña escrita en texto claro podría quedar disponible para:

  • Administradores del sistema.
  • Plataformas de monitoreo.
  • Herramientas de agregación de logs.
  • Personal con permisos sobre el entorno.
  • Copias históricas de registros.

Por esta razón, los logs deben almacenar únicamente la información necesaria para diagnosticar eventos sin revelar datos privados o credenciales.

7. Remediación de la vulnerabilidad

Después de identificar el problema se modificó el código del endpoint de autenticación.

La corrección se basó en tres medidas:

  1. Eliminar el registro de contraseñas.
  2. Evitar enviar información sensible directamente hacia los logs.
  3. Registrar solamente el evento necesario para mantener trazabilidad.

Código corregido 

app.post('/api/login', (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({
      error: 'Email y contraseña requeridos'
    });
  }

  // Registro del evento sin exponer información sensible
  console.log('[AUTH-LOG] Intento de login');

  const user = users.find(u => u.email === email);

  if (user && password === 'admin123') {
    return res.json({
      message: 'Autenticación exitosa',
      token: 'jwt-simulated-token-bearer-demo',
      user: {
        id: user.id,
        email: user.email,
        name: user.name
      }
    });
  }

  return res.status(401).json({
    error: 'Credenciales inválidas'
  });
});
Enter fullscreen mode Exit fullscreen mode

Ahora el sistema únicamente registra:

console.log('[AUTH-LOG] Intento de login');
Enter fullscreen mode Exit fullscreen mode

De esta forma se mantiene la trazabilidad del evento sin guardar directamente la contraseña ni otros datos sensibles.

8. Verificación de la remediación

La corrección fue enviada al repositorio mediante el commit:

fix: remove sensitive login data from logs
Enter fullscreen mode Exit fullscreen mode

Después del nuevo push, GitHub Actions volvió a ejecutar automáticamente Bearer sobre el proyecto.

Resultado del nuevo análisis

  • Checks ejecutados: 87
  • Hallazgos críticos: 0
  • Hallazgos altos: 0
  • Estado final del pipeline: SUCCESS ✅

El flujo resultante fue:

Código corregido
      │
      ▼
git push
      │
      ▼
GitHub Actions
      │
      ▼
Bearer SAST
      │
      ▼
0 HIGH / 0 CRITICAL
      │
      ▼
✅ Pipeline exitoso
Enter fullscreen mode Exit fullscreen mode

El resultado demuestra cómo una herramienta SAST puede utilizarse para detectar un problema, bloquear el flujo y posteriormente verificar que la vulnerabilidad haya sido corregida.

9. Despliegue en la nube

Una vez corregido el código y aprobado el análisis de seguridad, la aplicación puede continuar dentro del flujo de despliegue.

La API se encuentra publicada en Render:

https://bearer-articulo.onrender.com

El proceso completo implementado puede resumirse así:

Desarrollo
    │
    ▼
GitHub
    │
    ▼
GitHub Actions
    │
    ▼
Bearer SAST
    │
    ├── Vulnerabilidad detectada
    │          │
    │          ▼
    │      ❌ Bloqueo
    │
    └── Código aprobado
               │
               ▼
         ✅ Pipeline exitoso
               │
               ▼
             Render
Enter fullscreen mode Exit fullscreen mode

De esta manera, el análisis de seguridad forma parte del flujo de desarrollo y automatización.

10. Lecciones aprendidas

Seguridad desde etapas tempranas

Incorporar herramientas de análisis durante el desarrollo permite identificar determinados problemas antes de que lleguen al entorno de producción.

Automatización

GitHub Actions permite ejecutar el análisis de manera repetible cada vez que se realizan cambios importantes en el repositorio.

Protección de datos sensibles

Las contraseñas, tokens y credenciales no deben almacenarse directamente dentro de los logs de una aplicación.

Compuertas de seguridad

Configurar el pipeline para detectar hallazgos de severidad alta o crítica permite detener el flujo cuando se identifica un problema relevante.

Seguridad integrada al desarrollo

El enfoque DevSecOps permite incorporar la seguridad como una actividad continua dentro del ciclo de desarrollo y no únicamente como una revisión final.

11. Resultado final

La implementación permitió comprobar un flujo completo de detección y corrección:

1. Se desarrolla la API
        │
        ▼
2. Se introduce una vulnerabilidad
        │
        ▼
3. Se realiza git push
        │
        ▼
4. GitHub Actions ejecuta Bearer
        │
        ▼
5. Bearer detecta HIGH
        │
        ▼
6. Pipeline falla ❌
        │
        ▼
7. Se corrige el código
        │
        ▼
8. Se realiza nuevo push
        │
        ▼
9. Bearer analiza nuevamente
        │
        ▼
10. 0 HIGH / 0 CRITICAL
        │
        ▼
11. Pipeline exitoso ✅
        │
        ▼
12. Aplicación disponible en Render
Enter fullscreen mode Exit fullscreen mode

Conclusiones

La implementación permitió demostrar de manera práctica cómo integrar DevSecOps dentro de un proyecto utilizando GitHub Actions y Bearer SAST.

La vulnerabilidad introducida intencionalmente permitió comprobar que Bearer podía detectar un problema relacionado con el manejo de información proveniente del usuario y provocar que el pipeline finalizara con error.

Después de aplicar la remediación, el nuevo análisis finalizó correctamente sin hallazgos altos o críticos.

Este proceso demuestra la utilidad de incorporar análisis estático de seguridad dentro de la Integración Continua.

GitHub Actions permite automatizar la ejecución del análisis, mientras que Bearer proporciona una capa adicional de revisión del código antes de continuar con el proceso de entrega.

Finalmente, la aplicación fue publicada en Render, completando un flujo que integra desarrollo, control de versiones, análisis SAST, remediación, validación y despliegue en la nube.

Recursos y enlaces

Autores

Saúl José Alvarado Urbano

Ana Cecilia Esteban Ramos

Escuela Profesional de Ingeniería de Sistemas

Curso de Calidad de Software

Top comments (0)