DevSecOps es la práctica de integrar la seguridad en cada etapa del ciclo DevOps, en lugar de revisarla solo al final del desarrollo.
Cuando la seguridad llega tarde, el daño ya está hecho
Imagina que tu equipo construyó el sistema de pagos de una tienda en línea durante tres meses. El día antes del lanzamiento, alguien revisa la seguridad y encuentra que las contraseñas se guardan en texto plano. Ahora tienes que retrasar el lanzamiento, reescribir código crítico y explicarle al cliente por qué falló la revisión. Ese escenario pasa en México más seguido de lo que crees.
El problema no es que el equipo sea descuidado. El problema es que la seguridad se trató como un paso separado, no como parte del proceso. DevSecOps resuelve exactamente eso.
El sistema SHIFT LEFT: mueve la seguridad hacia el inicio
En DevOps, "shift left" significa mover una actividad hacia etapas más tempranas del ciclo. En seguridad, esto es fundamental. En lugar de revisar vulnerabilidades en producción, las detectas desde que el desarrollador escribe la primera línea de código.
El marco DevSecOps se divide en tres capas que trabajan juntas:
- Seguridad en el código: análisis estático y revisión de dependencias.
- Seguridad en el pipeline: validaciones automáticas antes de cada deploy.
- Seguridad en producción: monitoreo continuo de amenazas activas.
Cada capa agrega una barrera. Si una amenaza pasa la primera, la siguiente la detiene.
Capa 1 — Seguridad en el código
El primer lugar donde pueden entrar vulnerabilidades es el código mismo. Hay dos herramientas básicas que debes usar desde el primer día.
Análisis estático (SAST) revisa tu código sin ejecutarlo. Busca patrones peligrosos como consultas SQL sin parámetros, contraseñas escritas directamente en el código y funciones obsoletas con fallas conocidas.
Una herramienta popular para proyectos Python es bandit. Así se ve un análisis básico:
# Instalar bandit
pip install bandit
# Analizar todo el directorio del proyecto
bandit -r ./src/
Bandit genera un reporte como este:
>> Issue: [B106:hardcoded_password_funcarg] Possible hardcoded password: 'admin123'
Severity: Medium Confidence: Medium
Location: src/database.py:14
Ese reporte te dice exactamente en qué archivo y en qué línea está el problema. Lo corriges antes de hacer el commit, no después del deploy.
Revisión de dependencias (SCA) analiza las librerías que usas. En México, muchos proyectos usan librerías de terceros sin revisar si tienen vulnerabilidades conocidas. La herramienta safety hace esto automáticamente:
# Instalar safety
pip install safety
# Revisar dependencias del proyecto
safety check -r requirements.txt
Si una dependencia tiene una vulnerabilidad publicada, safety te muestra el número CVE y la versión segura a la que debes actualizar. Un CVE es un identificador oficial de vulnerabilidades conocidas a nivel mundial.
Capa 2 — Seguridad en el pipeline
Una vez que el código pasa las revisiones locales, el pipeline de CI/CD es tu segunda línea de defensa. Aquí automatizas las mismas revisiones para que nadie pueda saltárselas.
Así se ve una etapa de seguridad dentro de un pipeline de GitHub Actions:
name: Pipeline Seguro
on: [push]
jobs:
seguridad:
runs-on: ubuntu-latest
steps:
- name: Descargar código
uses: actions/checkout@v3
- name: Instalar dependencias
run: pip install bandit safety
- name: Análisis estático
run: bandit -r ./src/ -ll
- name: Revisión de dependencias
run: safety check -r requirements.txt
- name: Construir imagen Docker
run: docker build -t mi-app:latest .
- name: Escanear imagen Docker
uses: aquasecurity/trivy-action@master
with:
image-ref: 'mi-app:latest'
severity: 'CRITICAL,HIGH'
exit-code: '1'
El paso final usa Trivy, una herramienta gratuita que escanea imágenes Docker en busca de vulnerabilidades. La opción exit-code: '1' es clave: si Trivy encuentra algo crítico, el pipeline falla y el deploy no continúa.
Esto significa que ningún código con vulnerabilidades graves puede llegar a producción de forma automática. El equipo tiene que resolver el problema primero.
Capa 3 — Secretos y variables de entorno
Uno de los errores más comunes en proyectos mexicanos es guardar credenciales directamente en el código. Tokens de API, contraseñas de bases de datos, llaves del SAT o credenciales del IMSS no deben vivir en tu repositorio.
La herramienta detect-secrets escanea tu código buscando patrones que parecen credenciales:
# Instalar detect-secrets
pip install detect-secrets
# Crear una línea base del proyecto
detect-secrets scan > .secrets.baseline
# En el pipeline, verificar que no hay secretos nuevos
detect-secrets audit .secrets.baseline
La alternativa correcta es usar variables de entorno o un gestor de secretos. En proyectos con GitHub Actions, los secretos se guardan en la configuración del repositorio y se acceden así:
- name: Conectar a base de datos
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
API_KEY: ${{ secrets.FEMSA_API_KEY }}
run: python conectar.py
Tu código nunca ve la contraseña real. Solo ve el nombre de la variable. Si alguien roba tu repositorio, no obtiene nada útil.
Errores comunes que destruyen la seguridad en pipelines
Incluso con buenas intenciones, los equipos cometen errores repetidos. Estos son los más frecuentes:
Error 1: Ignorar los reportes de seguridad. Bandit y Trivy generan reportes, pero si el equipo los ve como ruido y los ignora, no sirven de nada. Configura el pipeline para que falle en severidades altas, no solo las muestre.
Error 2: Usar la imagen base más grande. Muchos Dockerfiles empiezan con FROM python:3.11 que incluye cientos de paquetes innecesarios. Cada paquete extra es una posible vulnerabilidad. Usa imágenes slim:
# En lugar de esto:
FROM python:3.11
# Usa esto:
FROM python:3.11-slim
Una imagen slim puede tener 90% menos vulnerabilidades que la imagen completa. Trivy te mostrará la diferencia claramente.
Error 3: No actualizar dependencias. Una librería sin vulnerabilidades hoy puede tenerlas mañana. Configura revisiones automáticas semanales con safety o activa Dependabot en GitHub para que abra pull requests cuando aparezcan versiones seguras.
Error 4: Permisos excesivos. Si tu aplicación solo necesita leer de una base de datos, no le des permisos de escritura y borrado. El principio de mínimo privilegio aplica en base de datos, APIs externas y roles de IAM en la nube.
DevSecOps en contexto mexicano
Empresas como Mercado Libre manejan millones de transacciones en pesos diariamente. Un sistema comprometido no solo pierde dinero: enfrenta sanciones del SAT, demandas por exposición de datos fiscales y pérdida de confianza del cliente.
Liverpool tiene datos de tarjetas de crédito de millones de mexicanos. Una vulnerabilidad en su pipeline podría exponer información protegida por la Ley Federal de Protección de Datos Personales. Esa ley tiene multas que pueden llegar a varios millones de pesos.
No necesitas ser Liverpool para aplicar DevSecOps. Si construyes un sistema que maneja RFC, CURP, datos bancarios o información personal, estas prácticas no son opcionales. Son tu responsabilidad profesional.
Cómo implementar DevSecOps desde hoy
No necesitas implementar todo al mismo tiempo. Sigue este orden:
- Semana 1: Agrega
banditysafetya tu proceso de commit local. - Semana 2: Integra esos mismos análisis como pasos en tu pipeline de CI.
- Semana 3: Mueve todas las credenciales a variables de entorno o secretos del repositorio.
- Semana 4: Agrega Trivy para escanear tus imágenes Docker antes del deploy.
- Mes 2: Configura actualizaciones automáticas de dependencias con Dependabot.
Cada semana agregas una barrera. Al final del mes, tienes un pipeline con cinco capas de protección activa.
La seguridad no es un paso al final del camino; es el pavimento sobre el que camina todo tu pipeline.