DEV Community: ANA CECILIA ESTEBAN RAMOS

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

ANA CECILIA ESTEBAN RAMOS — Mon, 05 Oct 2026 17:25:47 +0000

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 ]

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

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

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"

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

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'
  });
});

La parte problemática se encuentra en:

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

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.

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

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:

Eliminar el registro de contraseñas.
Evitar enviar información sensible directamente hacia los logs.
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'
  });
});

Ahora el sistema únicamente registra:

console.log('[AUTH-LOG] Intento de login');

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

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

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

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

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

Código fuente completo: GitHub - saulalvarado1/Bearer_Articulo
Aplicación en vivo: https://bearer-articulo.onrender.com
Documentación oficial de Bearer: https://docs.bearer.com/
CWE-134 - Use of Externally-Controlled Format String: https://cwe.mitre.org/data/definitions/134.html
CWE-532 - Insertion of Sensitive Information into Log File: https://cwe.mitre.org/data/definitions/532.html

Autores

Saúl José Alvarado Urbano

Ana Cecilia Esteban Ramos

Escuela Profesional de Ingeniería de Sistemas

Curso de Calidad de Software

Estrategias de respaldo de bases de datos con PostgreSQL, Django y despliegue automatizado en la nube

ANA CECILIA ESTEBAN RAMOS — Mon, 05 Oct 2026 02:02:20 +0000

Autora: Ana Cecilia Esteban Ramos

Proyecto desarrollado con: Saúl José Alvarado Urbano

Repositorio: github.com/anaesteban1/database-backup-strategies

Aplicación en vivo: database-backup-strategies.onrender.com

Base de datos: PostgreSQL

Cloud / PaaS: Render

Resumen

La protección de la información es una responsabilidad fundamental en cualquier sistema que utilice una base de datos. Una eliminación accidental, un error de aplicación, una falla de infraestructura o una operación incorrecta pueden ocasionar pérdida de información si no existe una estrategia adecuada de respaldo y recuperación.

En este artículo presentamos la implementación práctica de una estrategia de respaldo y restauración de bases de datos utilizando PostgreSQL, evitando Microsoft SQL Server. Para ello desarrollamos una aplicación web con Python y Django, utilizamos GitHub como repositorio público, implementamos respaldos lógicos mediante pg_dump, documentamos el proceso de recuperación con pg_restore y publicamos la solución en Render.

Además, el repositorio se encuentra integrado con Render mediante Auto-Deploy, permitiendo que cada cambio enviado a la rama principal genere automáticamente una nueva versión de la aplicación desplegada en la nube.

El proyecto permite demostrar que el respaldo de una base de datos y el despliegue automatizado son procesos diferentes, pero complementarios dentro de una solución orientada a disponibilidad, recuperación y continuidad del servicio.

1. Arquitectura y stack tecnológico

La solución desarrollada separa la aplicación web, la base de datos, el proceso de respaldo y el flujo de despliegue.

[ Usuario ]
     │
     ▼
[ Aplicación Django ]
     │
     ▼
[ PostgreSQL ]
     │
     ├────────────► pg_dump
     │                  │
     │                  ▼
     │          [ Archivo de respaldo ]
     │                  │
     │                  ▼
     └────────────► pg_restore
                        │
                        ▼
             [ Base de datos recuperada ]

De manera paralela, el despliegue de la aplicación sigue el siguiente flujo:

[ Desarrollador ]
       │
       │ git push
       ▼
[ GitHub Repository ]
       │
       │ Detecta nuevo commit
       ▼
[ Render Auto-Deploy ]
       │
       ├─► Build
       ├─► Migraciones
       ├─► Deploy
       │
       ▼
[ Aplicación en Producción ]

Componentes principales

Backend: Python + Django.
Base de datos: PostgreSQL.
Herramienta de respaldo: pg_dump.
Herramienta de restauración: pg_restore.
Control de versiones: Git.
Repositorio público: GitHub.
Plataforma Cloud / PaaS: Render.
Automatización del despliegue: Render Auto-Deploy.

2. Repositorio público del proyecto

Uno de los requisitos principales del proyecto consiste en mantener el código fuente de la aplicación dentro de un repositorio público.

El proyecto completo se encuentra disponible en GitHub:

👉 Repositorio: anaesteban1/database-backup-strategies

Dentro del repositorio se encuentran los principales componentes de la solución:

database-backup-strategies/
│
├── backup_project/
├── backups/
├── scripts/
│   └── backup_postgres.ps1
├── templates/
│   └── backups/
├── manage.py
├── requirements.txt
├── render.yaml
└── README.md

El repositorio también conserva el historial de commits realizados durante el desarrollo, permitiendo evidenciar las contribuciones realizadas por los integrantes del equipo.

Importancia de GitHub: además de almacenar el código fuente, permite conservar trazabilidad sobre los cambios realizados y facilita la integración con herramientas de despliegue continuo.

3. Estrategia de respaldo con PostgreSQL

La estrategia implementada utiliza las herramientas nativas de PostgreSQL para generar respaldos lógicos de la información.

Se consideraron tres aspectos principales:

Respaldo lógico completo.
Automatización mediante script.
Retención de diferentes versiones del respaldo.

3.1. Respaldo lógico completo con `pg_dump`

PostgreSQL proporciona la herramienta pg_dump, utilizada para exportar una base de datos y generar un respaldo lógico.

En PowerShell se puede ejecutar:

pg_dump `
  --dbname=$env:DATABASE_URL `
  --format=custom `
  --file=postgres_backup.dump

La opción:

--format=custom

genera un archivo en formato personalizado de PostgreSQL.

El resultado será un archivo similar a:

postgres_backup.dump

Este formato es especialmente útil porque posteriormente puede utilizarse con pg_restore.

Flujo del respaldo

[ PostgreSQL ]
      │
      ▼
   pg_dump
      │
      ▼
[ Archivo .dump ]

3.2. Identificación de respaldos mediante fecha y hora

Si todos los respaldos utilizaran exactamente el mismo nombre, una nueva ejecución podría reemplazar una copia anterior.

Para evitarlo se utiliza una marca de tiempo:

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"

$backupFile = "postgres_backup_$timestamp.dump"

Esto permite generar archivos como:

postgres_backup_2026-10-03_18-30-15.dump
postgres_backup_2026-10-04_09-15-32.dump
postgres_backup_2026-10-04_18-40-22.dump

De esta manera se pueden conservar diferentes versiones e identificar fácilmente cuándo fue generado cada respaldo.

3.3. Automatización del respaldo

Realizar respaldos únicamente de manera manual puede representar un riesgo, debido a que el proceso depende de que una persona recuerde ejecutarlo.

Por esta razón se implementó el script:

scripts/backup_postgres.ps1

El flujo del script es el siguiente:

[ Inicio ]
    │
    ▼
¿Existe DATABASE_URL?
    │
    ▼
¿Está disponible pg_dump?
    │
    ▼
Generar timestamp
    │
    ▼
Ejecutar pg_dump
    │
    ▼
Crear archivo .dump
    │
    ▼
Verificar resultado

Una parte esencial del script es:

if (-not $env:DATABASE_URL) {
    Write-Host "Falta la variable DATABASE_URL."
    exit 1
}

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"

$backupFile = Join-Path `
    $OutputDirectory `
    "postgres_backup_$timestamp.dump"

pg_dump `
    --dbname=$env:DATABASE_URL `
    --format=custom `
    --file=$backupFile

El script permite estandarizar el proceso de respaldo y puede integrarse posteriormente con un mecanismo de programación de tareas.

Nota: el proyecto implementa el script necesario para automatizar el proceso. La periodicidad puede definirse posteriormente mediante un programador de tareas, un flujo CI/CD o un servicio especializado de automatización.

4. Estrategia de retención

Generar un respaldo no es suficiente. También es necesario determinar durante cuánto tiempo deberían conservarse las diferentes copias.

Una posible política de retención podría ser:

Respaldos diarios    → 7 días
Respaldos semanales  → 4 semanas
Respaldos mensuales  → 12 meses

Estos tiempos son únicamente un ejemplo de política y deben adaptarse a las necesidades reales de cada organización.

En el proyecto, la utilización de fecha y hora en el nombre de cada archivo constituye la base necesaria para conservar múltiples versiones.

En un entorno productivo también sería recomendable almacenar las copias importantes en una ubicación diferente del servidor principal.

Buena práctica: mantener la aplicación y todos sus respaldos en el mismo servidor puede provocar que una sola falla afecte tanto a los datos originales como a sus copias.

5. Restauración mediante `pg_restore`

Un respaldo solamente resulta útil si puede utilizarse para recuperar la información.

Los archivos generados mediante pg_dump en formato personalizado pueden restaurarse utilizando pg_restore.

Ejemplo:

pg_restore `
  --dbname=$env:DATABASE_URL `
  postgres_backup.dump

El proceso completo puede representarse así:

[ PostgreSQL ]
      │
      ▼
   pg_dump
      │
      ▼
[ Backup .dump ]
      │
      ▼
  pg_restore
      │
      ▼
[ PostgreSQL restaurado ]

Además de generar respaldos, una estrategia correcta debería realizar periódicamente pruebas de recuperación.

Principio importante: la existencia de un archivo de respaldo no garantiza por sí sola que la información pueda recuperarse. La restauración también debe ser comprobada.

6. Despliegue automatizado con GitHub y Render

Otro requisito del proyecto consiste en desplegar la aplicación mediante un mecanismo automatizado.

Para ello se conectó directamente el repositorio de GitHub con Render.

El flujo implementado es:

[ Proyecto local ]
       │
       ▼
git add .
       │
       ▼
git commit
       │
       ▼
git push origin main
       │
       ▼
[ GitHub ]
       │
       ▼
[ Render Auto-Deploy ]
       │
       ├─► Construcción
       ├─► Instalación de dependencias
       ├─► Migraciones
       └─► Deploy
       │
       ▼
[ Aplicación Live ]

Para comprobar el funcionamiento se realizó el siguiente commit:

git add .
git commit -m "Verifica despliegue automatico desde GitHub"
git push origin main

Después del push, Render detectó automáticamente el nuevo commit y generó un nuevo despliegue.

El historial de Render mostró:

Verifica despliegue automatico desde GitHub

Trigger: Auto-Deploy
Estado: Live

Esto permitió verificar experimentalmente el requisito de Deploy through automation.

Posteriormente, un commit realizado por Saúl Alvarado para documentar el proceso de restauración también activó un nuevo Auto-Deploy.

7. Publicación en nube pública

La aplicación fue desplegada públicamente utilizando Render, una plataforma como servicio que permite alojar aplicaciones web.

La aplicación está disponible en:

👉 Producción: https://database-backup-strategies.onrender.com

En la interfaz se muestra el estado actual:

Aplicación activa ✅
Despliegue automático GitHub → Render ✅
Motor actual: POSTGRESQL

La aplicación permite registrar información de prueba que posteriormente puede formar parte de los respaldos realizados sobre la base de datos.

Con esto se cumplen dos de los requisitos principales del proyecto:

✅ Aplicación publicada en nube pública
✅ Uso de PostgreSQL en lugar de Microsoft SQL Server

8. Variables de entorno y protección de credenciales

Debido a que el repositorio es público, las credenciales de la base de datos no deben almacenarse directamente dentro del código fuente.

La aplicación utiliza variables de entorno:

DATABASE_URL
SECRET_KEY
DEBUG

Por ejemplo:

DATABASES = {
    "default": dj_database_url.config(
        default=f"sqlite:///{BASE_DIR / 'db.sqlite3'}",
        conn_max_age=600,
        conn_health_checks=True,
    )
}

La variable DATABASE_URL permite proporcionar la conexión de PostgreSQL desde el entorno cloud sin publicar directamente:

Usuario
Contraseña
Host
Puerto
Nombre de la base de datos

Buena práctica: las credenciales y secretos nunca deberían almacenarse directamente dentro de un repositorio público.

9. Diferencia entre respaldo y Auto-Deploy

Durante el desarrollo también fue importante diferenciar dos conceptos que pueden confundirse: respaldo de base de datos y despliegue automatizado.

Auto-Deploy

Protege y automatiza el proceso de entrega del software:

Nuevo código
    │
    ▼
GitHub
    │
    ▼
Render
    │
    ▼
Nueva versión de la aplicación

Backup

Protege la información almacenada:

Datos
  │
  ▼
PostgreSQL
  │
  ▼
pg_dump
  │
  ▼
Archivo de respaldo

El Auto-Deploy permite publicar nuevas versiones de la aplicación, pero no reemplaza un respaldo de la base de datos.

Una solución confiable debe considerar ambos procesos.

10. Resultado final

Al finalizar la implementación se obtuvo el siguiente resultado:

Repositorio público: ✅ GitHub.
Aplicación web: ✅ Django.
Base de datos: ✅ PostgreSQL.
Microsoft SQL Server: ❌ No utilizado.
Respaldo lógico: ✅ pg_dump.
Restauración: ✅ pg_restore.
Script de respaldo: ✅ PowerShell.
Cloud público: ✅ Render.
Despliegue automático: ✅ GitHub → Render.
Aplicación pública: ✅ Online.

La solución completa queda representada de la siguiente manera:

                    ┌──────────────────────┐
                    │    Desarrollador     │
                    └──────────┬───────────┘
                               │
                            git push
                               │
                               ▼
                    ┌──────────────────────┐
                    │        GitHub        │
                    └──────────┬───────────┘
                               │
                         Auto-Deploy
                               │
                               ▼
                    ┌──────────────────────┐
                    │        Render        │
                    │       Django         │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │     PostgreSQL       │
                    └──────────┬───────────┘
                               │
                   ┌───────────┴───────────┐
                   │                       │
                   ▼                       ▼
               pg_dump                pg_restore
                   │                       │
                   ▼                       ▼
             Backup .dump             Recuperación

11. Demostración en video

Como parte de la actividad se realizará un video público de una duración máxima de 5 minutos.

En el video se mostrará:

El repositorio público del proyecto.
La estructura de la aplicación Django.
La utilización de PostgreSQL.
El script de respaldo.
El uso de pg_dump.
El proceso de restauración mediante pg_restore.
El Auto-Deploy desde GitHub.
El servicio desplegado en Render.
La aplicación funcionando públicamente.

🎥 Video de demostración:

PENDIENTE - AGREGAR ENLACE DE YOUTUBE

Esta URL se agregará antes de realizar la publicación definitiva del artículo.

12. Lecciones aprendidas y buenas prácticas

Un respaldo debe ser recuperable: generar archivos de respaldo no es suficiente; también debe comprobarse el proceso de restauración.
La automatización reduce errores humanos: utilizar scripts permite ejecutar procedimientos repetibles y disminuye la dependencia de acciones manuales.
Los respaldos necesitan retención: conservar distintas versiones facilita recuperar información de diferentes momentos.
Las credenciales deben permanecer fuera del repositorio: las variables de entorno permiten proteger información sensible cuando el código fuente es público.
Backup y deployment cumplen objetivos diferentes: el despliegue automatizado actualiza el software, mientras que los respaldos protegen los datos.
La trazabilidad es importante: Git y GitHub permiten mantener evidencia de los cambios realizados durante todo el desarrollo.

Conclusiones

La implementación permitió demostrar una estrategia práctica de respaldo utilizando PostgreSQL, evitando Microsoft SQL Server según las condiciones establecidas para la actividad.

El uso de pg_dump permite generar respaldos lógicos de la información, mientras que pg_restore proporciona el mecanismo necesario para recuperar archivos generados en formatos compatibles.

Asimismo, la utilización de marcas de fecha y hora proporciona una base para mantener diferentes versiones de los respaldos y aplicar posteriormente políticas de retención.

La integración entre GitHub y Render permitió automatizar el despliegue de la aplicación, verificando que un cambio enviado mediante git push puede producir automáticamente una nueva versión disponible públicamente.

Finalmente, este proyecto demuestra que una solución completa debe proteger tanto el código fuente como los datos almacenados. El control de versiones, los respaldos, la restauración, las variables de entorno y el despliegue automatizado constituyen prácticas complementarias para mejorar la confiabilidad de una aplicación.

Recursos y enlaces

Código fuente completo: GitHub - anaesteban1/database-backup-strategies
Aplicación en vivo (Producción): https://database-backup-strategies.onrender.com
Documentación oficial de PostgreSQL: https://www.postgresql.org/docs/
Documentación de pg_dump: https://www.postgresql.org/docs/current/app-pgdump.html
Documentación de pg_restore: https://www.postgresql.org/docs/current/app-pgrestore.html
Backup y Restore en PostgreSQL: https://www.postgresql.org/docs/current/backup.html
Documentación oficial de Django: https://docs.djangoproject.com/
Despliegue de Django en Render: https://render.com/docs/deploy-django
Documentación de Deploys en Render: https://render.com/docs/deploys
Video de demostración: PENDIENTE - AGREGAR ENLACE DE YOUTUBE

Autora

Ana Cecilia Esteban Ramos

Universidad Privada de Tacna

Escuela Profesional de Ingeniería de Sistemas

Curso: Base de Datos II

DEV Community: ANA CECILIA ESTEBAN RAMOS

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

Resumen

1. Arquitectura y stack tecnológico

Componentes principales

2. Configuración del pipeline de seguridad

3. ¿Por qué utilizar Bearer?

4. Introducción intencional de una vulnerabilidad

Código vulnerable

5. Detección automática de la vulnerabilidad

Resultado del análisis

6. Impacto del problema detectado

7. Remediación de la vulnerabilidad

Código corregido

8. Verificación de la remediación

Resultado del nuevo análisis

9. Despliegue en la nube

10. Lecciones aprendidas

Seguridad desde etapas tempranas

Automatización

Protección de datos sensibles

Compuertas de seguridad

Seguridad integrada al desarrollo

11. Resultado final

Conclusiones

Recursos y enlaces

Autores

Estrategias de respaldo de bases de datos con PostgreSQL, Django y despliegue automatizado en la nube

Resumen

1. Arquitectura y stack tecnológico

Componentes principales

2. Repositorio público del proyecto

3. Estrategia de respaldo con PostgreSQL

3.1. Respaldo lógico completo con pg_dump

Flujo del respaldo

3.2. Identificación de respaldos mediante fecha y hora

3.3. Automatización del respaldo

4. Estrategia de retención

5. Restauración mediante pg_restore

6. Despliegue automatizado con GitHub y Render

7. Publicación en nube pública

8. Variables de entorno y protección de credenciales

9. Diferencia entre respaldo y Auto-Deploy

Auto-Deploy

Backup

10. Resultado final

11. Demostración en video

12. Lecciones aprendidas y buenas prácticas

Conclusiones

Recursos y enlaces

Autora

3.1. Respaldo lógico completo con `pg_dump`

5. Restauración mediante `pg_restore`