Pipeline CI/CD

El pipeline de CI/CD – Continuous Integration / Continuous Delivery (Integración continua / Entrega continua) es una cadena automatizada de procesos que permite desarrollar, probar y desplegar software de manera rápida, segura y eficiente.

🔧 ¿Qué significa cada parte?

1. CI – Integración continua (Continuous Integration)
   👉 Es el proceso de integrar y probar automáticamente el código nuevo cada vez que un desarrollador hace un cambio (por ejemplo, un push o commit en Git).

   • El código se compila.

   • Se ejecutan tests automáticos (unitarios, estáticos, etc.).

   • Se verifica que no rompe nada del sistema existente.

2. CD – Entrega continua (Continuous Delivery)
   👉 Es el proceso de automatizar el despliegue del software validado a entornos como testing, staging o producción.

   • Permite que el software siempre esté listo para ser lanzado.

   • En algunos casos, se extiende a CD como Continuous Deployment, donde el despliegue a producción también es automático.

🛠️ ¿Qué contiene un pipeline de CI/CD?

Un pipeline puede tener varios pasos o etapas como:

1. Compilación del código.

2. Análisis estático de seguridad (SAST).

3. Pruebas unitarias automáticas.

4. Pruebas de integración.

5. Escaneo de vulnerabilidades en dependencias.

6. Construcción de contenedores (como Docker).

7. Despliegue automático al entorno deseado.

8. Notificaciones (correo, Slack, SIEM…).

🧠 Alegoría visual: Fábrica de software automatizada

Imagina una línea de ensamblaje automatizada:

• Entras con un plano (el código fuente).

• Cada estación (etapa del pipeline) verifica que todo esté bien: estructura, seguridad, funcionamiento.

• Al final, si todo pasa los controles, el producto sale listo para ser entregado al cliente (producción).

🔐 ¿Por qué es importante en ciberseguridad?

Porque automatiza la detección temprana de errores y vulnerabilidades, reduciendo el riesgo de que:

• Se despliegue código malicioso o inseguro.

• Haya fugas de datos por configuraciones incorrectas.

• Se cometan errores humanos repetitivos.

🧩 Herramientas comunes

• GitLab CI/CD

• Jenkins

• GitHub Actions

• CircleCI

• Azure DevOps

• Bitbucket Pipelines

👁️ Como Arquitecta de Seguridad Purple Team:

• Desde el Blue Team, aseguro que el pipeline tenga escaneos de seguridad (SAST, DAST, secretos expuestos).

• Desde el Red Team, pruebo si es posible inyectar código malicioso o explotar errores de configuración (por ejemplo, credenciales hardcodeadas).

• Desde el Purple Team, alineo todo para que el código se integre, valide y despliegue con seguridad y visibilidad completa.

Escaneos de Seguridad Automatizados en CI/CD

🎯 Objetivo

Incorporar herramientas de análisis y validación automática de seguridad dentro del pipeline de integración continua y despliegue continuo (CI/CD) para detectar vulnerabilidades antes de llegar a producción.

🚦 1 Tipos de escaneo

Tipo Descripción Herramientas recomendadas
SAST (Static Application Security Testing) Analiza el código fuente en reposo Bandit (Python), Semgrep, SonarQube
DAST (Dynamic Application Security Testing) Evalúa la app en ejecución, desde fuera OWASP ZAP, Nikto, Burp Suite (auto)
SCA (Software Composition Analysis) Detecta vulnerabilidades en librerías Trivy, Dependency-Check, Snyk
IaC Security Escaneo de infraestructura como código (Terraform, YAML, etc.) Checkov, tfsec, KICS
Secrets Scanning Detecta secretos expuestos en código GitLeaks, truffleHog

⚙️ 2 Integración en pipelines (GitLab, Jenkins, GitHub Actions)

Flujo DevSecOps básico:

1. Push a repo → Trigger del pipeline

2. Etapa de build

3. Etapa de SAST + SCA + Secrets scanning

4. Etapa de tests funcionales

5. Etapa de DAST + IaC Security

6. Despliegue condicional (si pasa todo)

Ejemplo de secuencia (GitLab CI):

yamlCopiarEditarsecurity_scan: stage: test image: python:3.10 script: - pip install bandit - bandit -r ./app -f json -o bandit_results.json - pip install trivy - trivy fs ./ --format json --output trivy_results.json

🐍 3 Automatización con Python

Puedes usar scripts en Python para:

• Analizar los reportes .json de Bandit, Trivy y OWASP ZAP.

• Crear alertas si se detectan vulnerabilidades críticas (por Slack, correo, etc.).

• Validar que las imágenes de contenedores no tengan vulnerabilidades antes del build.

• Correlacionar vulnerabilidades con ramas/commits para priorizar.

🧠 4 Buenas prácticas y errores comunes

• Fallar el pipeline si hay vulnerabilidades críticas Solo escanear pero no actuar
• Escanear dependencias cada push o PR Usar solo escaneo manual antes del despliegue
• Validar IaC antes de aplicar terraform apply Ignorar cambios en configuración sensible
• Centralizar reportes en el SIEM Dejar reportes sin revisar

🛡️ 5 Alineación con MITRE ATT&CK

Táctica Técnica Riesgo mitigado por escaneo
Initial Access T1190 – Exploit Public-Facing App SAST, DAST
Persistence T1053 – Scheduled Task/Job IaC scanning, secrets scanning
Credential Access T1552 – Unsecured Credentials Secrets detection en commits/repos
Privilege Escalation T1068 – Exploitation for Privilege Escalation CVE detection con Trivy/Snyk

📏 6 Alineación con ENS, ISO y NIST

Marco Requisito relacionado
ENS (Nivel Alto) MP.SI.5 – Validación de código y despliegue controlado
ISO 27001 A.14.2.8 – Pruebas de seguridad en apps
NIST SP 800-53 RA-5 – Evaluación de vulnerabilidades automatizada

📌 Resumen

✅ Usa herramientas automatizadas y de código abierto siempre que puedas.
✅ Escanea tanto el código como las imágenes de contenedor e IaC.
✅ Automatiza alertas y bloqueos de despliegue según criticidad.
✅ Documenta las políticas de CI/CD seguro y actualízalas.

🟣 Ejercicios Purple Team – CI/CD

1. Evalúa la visibilidad y trazabilidad del pipeline

📌 ¿Todas las etapas del pipeline generan logs y alertas?

✅ Tarea:

• Verifica si cada fase del pipeline (build, test, deploy) envía logs a un sistema central (SIEM, ELK, CloudWatch, etc.).

• Asegúrate de que los errores, fallos de autenticación o comportamientos sospechosos (como despliegues fuera de horario) generen alertas.

🔐 Resultado esperado:

Tengo visibilidad completa del pipeline y sus eventos. Puedo trazar quién hizo qué, cuándo y cómo.

2. Simula una inyección de código malicioso en el pipeline

📌 ¿Detectamos si alguien sube código peligroso a través del repositorio?

⚔️ Tarea:

• Desde la perspectiva Red Team, intenta insertar un script malicioso o comando inesperado dentro de una función legítima del código fuente.

• Luego, evalúa si:

  • El análisis SAST lo detecta.

  • El pipeline se detiene automáticamente.

  • Se genera una alerta.

🛡️ Resultado esperado:

El sistema detecta y bloquea el código malicioso antes de llegar a producción.

3. Testea la integridad de las dependencias externas

📌 ¿Qué pasa si una librería de terceros cambia o se compromete?

✅ Tarea:

• Elige una dependencia común (ej. lodash, requests, log4j) y simula un cambio en la versión (conocido como "dependency confusion" o "supply chain attack").

• Observa si:

  • El pipeline valida la integridad (hash, firma, checksum).

  • Se restringen versiones exactas o hashes seguros (verifica si hay control de lockfiles).

🔐 Resultado esperado:

Tengo controles para asegurar que solo se usen dependencias confiables y verificadas.

4. Valida los secretos y credenciales en el pipeline

📌 ¿Están expuestos tokens, claves API o contraseñas en el repositorio o pipeline?

🔍 Tarea:

• Realiza una búsqueda de secretos expuestos en el código (grep, herramientas como TruffleHog o GitLeaks).

• Comprueba:

  • Si hay detección automática.

  • Si el pipeline se detiene.

  • Si se usan gestores seguros de secretos (Vault, AWS Secrets Manager, GitHub Secrets).

🛡️ Resultado esperado:

El sistema bloquea el uso de secretos inseguros y exige el uso de vaults seguros.

💎 BONUS – Resultado Purple Team

Tengo un pipeline CI/CD seguro, automatizado y resiliente, que detecta ataques, responde con alertas y bloquea errores humanos antes de que lleguen a producción.
Alineo el desarrollo ágil con las mejores prácticas de seguridad, sin frenar la velocidad del equipo técnico.