Seguridad en canalizaciones DevOps (CI-CD)

Definicion

Una canalizacion DevOps (CI/CD) es el flujo automatizado que lleva el software desde codigo fuente hasta entrega y operacion. La seguridad del pipeline busca proteger ese flujo para que la automatizacion no se convierta en un vector de ataque.

Contexto

• La automatizacion acelera desarrollo e implementacion, pero aumenta la superficie de ataque: un atacante puede comprometer el pipeline en vez del host individual.
• La seguridad debe incorporarse a cada etapa del ciclo: ver DevOps, DevSecOps y Secure SDLC (SSDLC).

Desarrollo (MIT-style)

1) Vista general del pipeline

El pipeline suele incluir codigo fuente, dependencias, pruebas automatizadas, CI/CD y entornos.

2) Fundamentos CI/CD (segun GitLab)

Segun GitLab, un sistema CI/CD maduro suele cumplir con estos principios:

• Repositorio unico de codigo fuente para todo lo necesario para construir la aplicacion.
• Commits frecuentes en la rama principal (cambios pequenos y regulares).
• Compilaciones automatizadas en cada actualizacion.
• Compilaciones con autopruebas (integridad, calidad y seguridad).
• Iteraciones frecuentes para reducir conflictos de integracion.
• Entornos de prueba estables similares a produccion.
• Maxima visibilidad de cambios y builds para todo el equipo.
• Despliegues predecibles en cualquier momento.

Nota: estos fundamentos optimizan velocidad y colaboracion, pero no garantizan seguridad por si solos.

3) Codigo fuente y control de versiones

Preguntas clave al almacenar codigo:

• Control de acceso y autenticacion.
• Trazabilidad de cambios y auditoria.
• Integracion con herramientas de desarrollo.
• Soporte de multiples versiones.
• Hosting interno vs proveedor externo. Ver detalle: Seguridad del codigo fuente y control de versiones (Git).

Modelos comunes:

• Git (distribuido) vs SVN (centralizado).
• Hosting: GitHub / GitLab; en SVN: TortoiseSVN / Apache SVN.

Consideraciones de seguridad:

• El codigo es un activo critico: requiere control de acceso y seguimiento de cambios.
• No usar repositorio como gestor de secretos: credenciales o strings quedan expuestos en el historial.

Caso practico — “Git nunca olvida” Si un secreto se commitea y luego se elimina, sigue existiendo en el historial. Herramientas como GittyLeaks pueden recuperar credenciales antiguas en commits anteriores.

4) Gestion de dependencias

Las dependencias son codigo fuera de nuestro control directo. Ver detalle: Gestion segura de dependencias (Dependency Management).

Internas vs externas (riesgos):

• Internas: pueden volverse legacy; el equipo es responsable de su seguridad; una vulnerabilidad impacta multiples apps.
• Externas: supply-chain risk (CDN/registry comprometido); zero-days pueden impactar a muchas organizaciones.

Herramientas comunes:

• Externas: PyPI, NuGet, Gems.
• Internas: JFrog Artifactory, Azure Artifacts.

Caso practico — Log4Shell Una vulnerabilidad en Log4j (Log4Shell) permitio RCE sin autenticacion. El impacto fue masivo por la amplia reutilizacion de la dependencia (ver XKCD y listas CISA).

5) Pruebas automatizadas

Pruebas funcionales:

• Unitarias: verifican partes pequenas del sistema; se usan como quality gate en CI.
• Integracion / regresion: validan interacciones y que nuevas features no rompan lo existente.

Pruebas de seguridad automatizadas:

• SAST: analiza codigo fuente para detectar patrones vulnerables; se integra en CI/CD como gate de seguridad.
• DAST: prueba la aplicacion en ejecucion; identifica vulnerabilidades dinamicas (p. ej., XSS usando origen/receptor).
  • Ver SAST (Static Application Security Testing) y DAST (Dynamic Application Security Testing).

Pruebas manuales (necesarias):

• Pentest y revisiones manuales siguen siendo clave para fallos de logica y control de acceso.
• Tecnicas modernas (IAST, RASP) ayudan, pero no reemplazan el contexto humano.

Herramientas comunes:

• GitHub Security, GitLab SAST, Snyk, SonarQube.

Caso practico — PoC sin calibracion Integrar SAST/DAST sin plan puede degradar rendimiento del repositorio/pipeline o frenar merges. La PoC debe considerar:

• Costo de rendimiento.
• Puntos de integracion.
• Calibracion de resultados.
• Definicion de quality gates realistas.

6) CI/CD

CI/CD es la automatizacion de build, pruebas, despliegue y entrega.

Elementos tipicos del pipeline:

• Trigger (push/merge).
• Build actions (compilacion/paquetizado).
• Test actions (funcionales y seguridad).
• Deploy actions (staging/prod).
• Delivery actions (monitorizacion post-deploy).

Infraestructura:

• Orquestadores y agentes de build ejecutan los jobs.

GitLab CI/CD (resumen practico)
Los pipelines se definen en .gitlab-ci.yml mediante jobs y stages:

• Un job declara su stage (build/test/deploy) y un script con comandos.
• Los jobs de una misma etapa pueden ejecutarse en paralelo.
• Si un job falla, las etapas posteriores no se ejecutan.
• Si un job no define stage, GitLab lo asigna a test por defecto.
• Con needs puedes forzar dependencias entre jobs y cambiar el orden.

Caso practico — agentes DEV/PROD compartidos Si DEV y PROD comparten agentes, un compromiso en DEV puede persistir hasta un deploy PROD e inyectar codigo malicioso.

Puertas de acceso (quality gates) Las gates controlan el avance entre etapas (calidad, seguridad, aprobaciones):

• Pruebas automatizadas, escaneos de seguridad y validacion de entorno.
• Aprobaciones manuales y verificacion de documentacion/rollback.
• Reglas de dos personas: quien inicia el build no debe poder aprobar el paso siguiente.

7) Seguridad del sistema de compilacion (lecciones SolarWinds)

El caso SolarWinds demostro el impacto de comprometer la cadena de suministro. Controles clave:

• Aislamiento/segmentacion de etapas y componentes de build (contenedores/VMs dedicadas).
• Controles de acceso estrictos y MFA para cuentas privilegiadas.
• Segmentacion de red para limitar movimiento lateral.
• Validar dependencias y proveedores; obtener artefactos solo de fuentes confiables.

8) Entornos (DEV, UAT, PreProd, PROD, DR/HA)

Otros entornos:

• Blue/Green: dos entornos PROD; facilitan rollback rapido.
• Canary: migracion gradual de usuarios para reducir riesgo.

Infraestructura moderna:

• VMs y contenedores (Vagrant, Terraform, Docker, Kubernetes) gestionados como IaC.

Caso practico — bypasses de DEV en PROD Omisiones de DEV (MFA, CAPTCHA, OTP fijo) pueden filtrarse a PROD si no hay segregacion y gates de seguridad.

9) Gestion de secretos en CI/CD

La automatizacion amplifica el impacto de un secreto expuesto. Buenas practicas:

• Usar variables CI/CD protegidas y enmascaradas (no hardcode en .gitlab-ci.yml).
• Alcance por entorno: secretos de PROD no deben estar disponibles en DEV.
• Evitar imprimir secretos en logs y eliminar secretos de artefactos (imagenes, binarios).
• Rotacion periodica y principio de minimo privilegio.

Caso practico — secretos mal acotados Si una variable de PROD esta disponible en un pipeline DEV, un atacante puede extraerla y comprometer produccion.

Ejemplos

• Pipeline seguro: SAST en PR, DAST en UAT/PreProd, y control de secretos antes de merge.
• Separacion de entornos: agentes de build dedicados por entorno y acceso por minimo privilegio.
• Two-person rule: aprobacion obligatoria por un segundo revisor antes de desplegar.

Pitfalls / Errores comunes

• Guardar secretos en el repositorio.
• Depender de un solo entorno/agente para DEV y PROD.
• Tener aprobaciones opcionales en ramas protegidas (auto-merge por el mismo autor).
• Integrar SAST/DAST sin calibracion (ruido, retrasos, rechazo).
• PreProd que no replica PROD (falsos positivos/negativos).
• Dejar bypasses de desarrollo activos en PROD.
• Variables CI/CD sin scope por entorno o sin enmascarar.

Diagrama

flowchart LR
SC[Codigo fuente] --> DEP[Dependencias]
DEP --> TEST[Pruebas automatizadas]
TEST --> CICD[CI/CD]
CICD --> ENV[Entornos]
ENV --> MON[Entrega/Monitoreo]

S1SCA -. gate .-> TEST
S2DAST -. gate .-> ENV
S3PROD -. control .-> CICD

Referencias

1. GitLab — CI/CD fundamentals: https://about.gitlab.com/topics/ci-cd/
2. GitLab CI YAML: https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html
3. GittyLeaks: https://github.com/kootenpv/gittyleaks
4. XKCD 2347 (dependencias): https://xkcd.com/2347/
5. CISA Log4j affected DB: https://github.com/cisagov/log4j-affected-db/tree/develop/software_lists
6. GitHub Security features: https://github.com/features/security/code
7. GitLab SAST: https://docs.gitlab.com/ee/user/application_security/sast/
8. Snyk: https://snyk.io/
9. SonarQube: https://www.sonarqube.org/
10. TryHackMe DevSecOps path: https://tryhackme.com/path/outline/devsecops
11. Intro to pipeline automation (THM): http://tryhackme.com/jr/introtopipelineautomation