La Guía Completa de Seguridad de Pipelines CI/CD

por

Introducción

Los pipelines CI/CD son la columna vertebral de la entrega de software moderna. Automatizan el recorrido desde el commit de código hasta el despliegue en producción, permitiendo a los equipos entregar más rápido, de manera más confiable y con mayor confianza. Pero este poder conlleva una contrapartida crítica: los pipelines son cada vez más el objetivo principal de atacantes sofisticados.

Piensa en todo lo que toca un pipeline CI/CD. Descarga código fuente, resuelve dependencias, accede a secretos y credenciales, construye artefactos, los sube a registros y despliega en infraestructura de producción. Un solo pipeline comprometido puede dar a un atacante acceso a todo — código fuente, secretos, cuentas en la nube, datos de clientes y sistemas de producción.

Esta guía proporciona una visión completa de la seguridad de pipelines CI/CD: qué está en juego, dónde están los riesgos y cómo construir pipelines seguros desde el código fuente hasta producción. Ya seas un ingeniero de seguridad que está fortaleciendo pipelines existentes o un equipo DevOps que construye nuevos, esta es tu referencia integral para comprender e implementar la seguridad de CI/CD.

Cubriremos todo el panorama — desde el modelado de amenazas y las superficies de ataque, pasando por la gestión de secretos, la integridad de artefactos, la aplicación de políticas y el hardening específico por plataforma. A lo largo del camino, enlazaremos guías detalladas, laboratorios prácticos y recursos que te permitirán profundizar en cada tema.

Por qué los Pipelines CI/CD Son una Prioridad de Seguridad

Los pipelines CI/CD ocupan una posición única y peligrosa en la infraestructura moderna. Son sistemas de automatización con acceso privilegiado a casi todos los recursos críticos de tu organización. Comprender por qué importan comienza por entender qué pueden alcanzar.

Los Pipelines Son Objetivos de Alto Valor

Un pipeline CI/CD típico tiene acceso a:

  • Repositorios de código fuente — incluyendo repositorios privados, algoritmos propietarios y configuraciones
  • Secretos y credenciales — claves API, credenciales de proveedores cloud, contraseñas de bases de datos, claves de firma
  • Infraestructura cloud — cuentas de AWS, GCP y Azure con permisos de despliegue
  • Entornos de producción — acceso directo de despliegue a sistemas en vivo que sirven a clientes
  • Registros de artefactos — registros de contenedores, repositorios de paquetes, almacenamiento de binarios
  • Redes internas — los runners frecuentemente se encuentran dentro de redes privadas con amplia conectividad

Un pipeline comprometido no solo da a los atacantes un punto de apoyo — les da las llaves del reino. El compromiso de un pipeline es una de las formas más eficientes de lograr movimiento lateral a través de toda una organización.

Ataques Reales a Pipelines

Esto no es teórico. Algunos de los incidentes de seguridad más significativos de los últimos años han sido ataques a pipelines y cadenas de suministro:

  • SolarWinds (2020) — Los atacantes comprometieron el sistema de compilación de SolarWinds Orion, inyectando código malicioso en actualizaciones de software firmadas que se distribuyeron a ~18.000 organizaciones, incluyendo agencias del gobierno de EE.UU. El ataque pasó desapercibido durante meses porque el código malicioso se insertó durante el proceso de compilación, lo que significaba que el repositorio de código fuente parecía limpio.
  • Codecov (2021) — Los atacantes modificaron el script Bash Uploader de Codecov explotando un fallo en la creación de imágenes Docker. Durante más de dos meses, el script comprometido exfiltró variables de entorno — incluyendo secretos de CI/CD, tokens API y credenciales — de miles de entornos CI que usaban Codecov.
  • CircleCI (2023) — El portátil de un ingeniero fue comprometido mediante malware, lo que dio a los atacantes acceso a un token de sesión de producción de CircleCI. Desde allí, los atacantes accedieron a variables de entorno, tokens y claves de clientes almacenadas en la plataforma de CircleCI. Cada secreto almacenado en CircleCI tuvo que considerarse comprometido.
  • GitHub Actions (en curso) — Múltiples incidentes que involucran acciones de terceros comprometidas, credenciales GITHUB_TOKEN robadas y ataques a la cadena de suministro a través de dependencias de acciones continúan demostrando que la seguridad de pipelines es una amenaza persistente y en evolución.

El hilo común en todos estos incidentes: los atacantes atacan el pipeline en sí, no la aplicación. Las medidas tradicionales de seguridad de aplicaciones — WAFs, protección de endpoints, monitoreo en tiempo de ejecución — no ayudan cuando el vector de ataque es el sistema de compilación y despliegue.

El Problema de la Asimetría

Existe una asimetría fundamental en la seguridad de CI/CD. Los pipelines están diseñados para ser permisivos y rápidos. Necesitan amplio acceso para hacer su trabajo. La seguridad, por otro lado, requiere restricción y verificación. Cerrar esta brecha — mantener la velocidad del pipeline mientras se aplican fronteras de seguridad — es el desafío central de la seguridad de CI/CD.

La Superficie de Ataque de CI/CD

Antes de poder asegurar un pipeline, necesitas entender dónde puede ser atacado. La superficie de ataque de CI/CD es amplia, abarcando múltiples sistemas, fronteras de confianza y dominios organizacionales.

Mapeando la Superficie de Ataque

La superficie de ataque de CI/CD incluye:

  1. Repositorios de Código Fuente — Evasión de protección de ramas, pull requests maliciosas, cuentas de desarrolladores comprometidas, cambios de código no autorizados en definiciones de pipelines
  2. Definiciones de Pipelines — Ejecución de pipeline envenenada (PPE), donde los atacantes modifican archivos de configuración CI (por ejemplo, .github/workflows/, .gitlab-ci.yml, Jenkinsfile) mediante pull requests o pushes a ramas
  3. Entornos de Compilación — Runners compartidos, cachés de compilación persistentes, herramientas de compilación comprometidas, escapes de contenedores de compilación
  4. Dependencias — Confusión de dependencias, typosquatting, paquetes upstream comprometidos, dependencias transitivas maliciosas
  5. Secretos y Credenciales — Acceso a secretos demasiado amplio, credenciales de larga duración, secretos filtrados en logs, secretos accesibles para compilaciones de repositorios bifurcados
  6. Artefactos — Artefactos de compilación manipulados, imágenes sin firmar, registros comprometidos, envenenamiento de artefactos
  7. Objetivos de Despliegue — Despliegue no autorizado, puertas de aprobación faltantes, separación insuficiente de entornos

Los 10 Principales Riesgos de Seguridad CI/CD de OWASP

El proyecto OWASP Top 10 CI/CD Security Risks proporciona un marco estructurado para comprender estas amenazas. Cataloga los riesgos más críticos, incluyendo mecanismos de control de flujo insuficientes, gestión inadecuada de identidad y acceso, abuso de la cadena de dependencias, ejecución de pipeline envenenada e higiene de credenciales insuficiente. Cada riesgo se mapea a patrones de ataque del mundo real y proporciona orientación concreta para la mitigación.

Para un análisis profundo de por qué los pipelines son la superficie de ataque principal y cómo los atacantes los explotan, consulta nuestro análisis detallado: Por Qué los Pipelines CI/CD Son la Superficie de Ataque Principal.

Fronteras de Confianza y Modelos de Ejecución

Uno de los aspectos más fundamentales — y más frecuentemente malinterpretados — de la seguridad de CI/CD son las fronteras de confianza. Cada pipeline opera dentro de un conjunto de suposiciones de confianza, y las violaciones de esas suposiciones son donde la seguridad se quiebra.

Preguntas Clave para Cada Pipeline

Para cada ejecución de pipeline, deberías poder responder:

  • ¿Quién activó este pipeline? — ¿Fue un desarrollador interno, un colaborador externo, un trabajo programado o una actualización automática de dependencias?
  • ¿Qué código se está ejecutando? — ¿Es código de una rama confiable, un pull request de un fork, una acción de terceros o una dependencia resuelta dinámicamente?
  • ¿Qué identidad asume el pipeline? — ¿Qué cuentas de servicio, roles cloud o tokens de plataforma están disponibles durante la ejecución?
  • ¿A qué recursos puede acceder el pipeline? — ¿Qué secretos, infraestructura, registros y entornos son alcanzables?

Modelos de Confianza en CI/CD

Diferentes activadores de pipeline conllevan niveles de confianza fundamentalmente diferentes:

  • Push a rama protegida — Alta confianza. El código ha pasado revisión y reglas de protección de ramas.
  • Pull request de colaborador — Confianza media. El autor del código es conocido pero los cambios no se han fusionado.
  • Pull request de fork — Baja confianza. El código proviene de un colaborador externo y podría contener cualquier cosa.
  • Trabajos programados/cron — Confianza variable. Depende de qué código y dependencias se resuelven en el momento de la ejecución.
  • Despacho manual — Depende de quién lo despachó y qué parámetros se proporcionaron.

El principio crítico: los permisos del pipeline y el acceso a secretos deben calibrarse al nivel de confianza del activador. Un pull request de un fork nunca debería tener acceso a credenciales de despliegue en producción.

Modelos de Ejecución

Diferentes plataformas CI/CD manejan el aislamiento de ejecución de manera diferente. Comprender el modelo de ejecución — ya sea que las compilaciones se ejecuten en VMs compartidas, contenedores efímeros o servidores persistentes — impacta directamente en tu postura de seguridad. Los entornos de ejecución compartidos crean riesgos de contaminación entre compilaciones, robo de credenciales y envenenamiento de caché.

Para una exploración completa de los modelos de ejecución de CI/CD y sus implicaciones de seguridad, consulta: Modelos de Ejecución de CI/CD, Suposiciones de Confianza y Guía de Seguridad.

Gestión de Secretos

Si hay un área que merece la mayor atención en la seguridad de CI/CD, es la gestión de secretos. El compromiso de credenciales es consistentemente la causa #1 de incidentes de seguridad en CI/CD. La mala higiene de secretos — credenciales codificadas directamente, acceso demasiado amplio, tokens de larga duración, secretos expuestos a código no confiable — está detrás de casi cada brecha importante de pipeline.

El Problema de los Secretos en CI/CD

Los pipelines necesitan secretos para funcionar. Necesitan credenciales para descargar código, resolver dependencias privadas, acceder a APIs cloud, subir artefactos y desplegar en producción. El desafío es proporcionar estas credenciales de manera segura:

  • Minimizar la exposición — Los secretos solo deberían estar disponibles para los pasos específicos que los necesitan
  • Limitar la duración — Las credenciales deberían ser de corta duración y rotarse automáticamente
  • Restringir el alcance — Cada credencial debería tener los permisos mínimos requeridos
  • Prevenir fugas — Los secretos no deben aparecer en logs, artefactos, mensajes de error o variables de entorno accesibles a código no confiable

Enfoques de Gestión de Secretos

Existe un espectro de madurez para la gestión de secretos en CI/CD:

Nivel 1: Secretos Nativos de la Plataforma

Cada plataforma CI/CD proporciona un mecanismo integrado de gestión de secretos — secretos de GitHub Actions, variables de GitLab CI, almacén de credenciales de Jenkins. Estos proporcionan cifrado básico en reposo y enmascaramiento en logs. Son un buen punto de partida pero tienen limitaciones: son específicos de la plataforma, difíciles de auditar y típicamente ofrecen un control de acceso de granularidad gruesa.

Nivel 2: Gestores de Secretos Externos

Integrar con herramientas dedicadas de gestión de secretos — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager — proporciona gestión centralizada, políticas de acceso de granularidad fina, registro de auditoría y rotación automática. Vault, en particular, destaca en la generación de credenciales dinámicas y de corta duración con alcance a ejecuciones específicas de pipeline.

Nivel 3: OIDC y Federación de Identidad de Carga de Trabajo

El estándar de oro para credenciales de CI/CD es eliminar completamente los secretos de larga duración. Usando OIDC (OpenID Connect) y federación de identidad de carga de trabajo, los pipelines pueden autenticarse con proveedores cloud usando su identidad de plataforma — sin necesidad de almacenar secretos. GitHub Actions, GitLab CI y otras plataformas pueden intercambiar sus tokens OIDC por credenciales cloud de corta duración con alcance a repositorios, ramas y entornos específicos.

Este enfoque proporciona:

  • Sin secretos que robar — las credenciales se generan bajo demanda y expiran en minutos
  • Alcance de granularidad fina — el acceso puede restringirse a repositorios, ramas y entornos de despliegue específicos
  • Auditabilidad completa — cada intercambio de credenciales se registra con contexto del pipeline

Mejores Prácticas de Gestión de Secretos

  • Nunca codifiques secretos directamente en definiciones de pipeline, código fuente o Dockerfiles
  • Usa secretos con alcance por entorno para separar credenciales de staging y producción
  • Implementa escaneo de secretos en hooks pre-commit y en CI para detectar exposiciones accidentales
  • Prefiere OIDC/federación de identidad de carga de trabajo sobre credenciales almacenadas siempre que sea posible
  • Usa secretos dinámicos (por ejemplo, credenciales de base de datos dinámicas de Vault) que se generan por ejecución de pipeline
  • Rota todas las credenciales de larga duración en un calendario regular e inmediatamente después de cualquier sospecha de compromiso
  • Nunca expongas secretos a compilaciones de pull requests de forks

Para orientación detallada de implementación, consulta nuestras guías en profundidad:

Integridad de Artefactos y Seguridad de la Cadena de Suministro

Asegurar lo que entra en tu pipeline (código, dependencias, secretos) es solo la mitad de la batalla. También necesitas asegurar lo que sale — los artefactos que tu pipeline produce y despliega. La integridad de artefactos asegura que lo que despliegas es exactamente lo que compilaste, sin manipulación en el camino.

El Problema de la Cadena de Suministro

El software moderno no consiste solo en tu código. Una aplicación típica incluye cientos o miles de dependencias, imágenes base, herramientas de compilación e integraciones de terceros. Cada una de estas es un eslabón en la cadena de suministro, y cada una puede ser comprometida. Los ataques a la cadena de suministro se dirigen a estos eslabones — inyectando código malicioso en dependencias, manipulando artefactos de compilación o comprometiendo registros.

Firma de Imágenes de Contenedor con Sigstore y Cosign

La firma de imágenes de contenedor proporciona prueba criptográfica de que una imagen fue construida por un pipeline confiable y no ha sido manipulada. Sigstore y su herramienta Cosign han simplificado dramáticamente la firma de imágenes al proporcionar firma sin claves — usando identidades OIDC (como la identidad de un pipeline CI/CD) para firmar artefactos sin gestionar claves de firma de larga duración.

En un pipeline seguro, cada imagen de contenedor debería ser:

  1. Firmada en el momento de compilación usando la identidad verificada del pipeline
  2. Verificada en el momento de despliegue antes de ser admitida en producción
  3. Rechazada si la firma no coincide con una identidad o política confiable

Procedencia y Atestaciones con SLSA e in-toto

SLSA (Supply-chain Levels for Software Artifacts) proporciona un marco para mejorar progresivamente la integridad de la cadena de suministro. En su núcleo, SLSA define la procedencia — un registro verificable de cómo, dónde y por quién fue construido un artefacto.

El framework in-toto complementa a SLSA proporcionando una forma de definir y verificar toda la cadena de suministro de software — desde el código fuente a través de la compilación hasta el despliegue. Cada paso en la cadena produce atestaciones que pueden verificarse contra un diseño predefinido.

Conceptos clave:

  • Procedencia — metadatos legibles por máquina que describen la compilación: qué entradas se usaron, qué sistema de compilación se ejecutó, qué salidas se produjeron
  • Atestaciones — declaraciones firmadas sobre un artefacto (por ejemplo, “esta imagen fue construida a partir de este commit por este pipeline”)
  • Verificación — comprobaciones automatizadas en el momento del despliegue que rechazan artefactos sin procedencia válida

Lista de Materiales de Software (SBOM)

Un SBOM proporciona un inventario completo de todos los componentes en un artefacto de software — cada biblioteca, dependencia y versión de herramienta. Los SBOMs permiten:

  • Seguimiento de vulnerabilidades — cuando se publica un nuevo CVE, puedes identificar inmediatamente qué artefactos están afectados
  • Cumplimiento de licencias — verificación automatizada de que todos los componentes cumplen los requisitos de licencia
  • Respuesta a incidentes — evaluación rápida del radio de impacto cuando se descubre un compromiso en la cadena de suministro

Compilaciones Reproducibles

Las compilaciones reproducibles aseguran que el mismo código fuente e instrucciones de compilación siempre producen el mismo artefacto de salida, bit a bit. Esta propiedad hace posible verificar independientemente que un artefacto liberado coincide con su código fuente declarado, eliminando toda una clase de ataques al sistema de compilación.

Para orientación detallada de implementación sobre integridad de artefactos, consulta:

Aplicación de Políticas

Los controles de seguridad solo son efectivos si se aplican de manera consistente y automática. Las revisiones de seguridad manuales no escalan. Las listas de verificación se olvidan. La solución es Política como Código — codificar tus requisitos de seguridad como políticas legibles por máquina que se evalúan automáticamente en cada ejecución de pipeline.

Política como Código con OPA y Rego

El Open Policy Agent (OPA) y su lenguaje de políticas Rego se han convertido en el estándar de facto para la aplicación de políticas en entornos cloud-native. En un contexto de CI/CD, OPA te permite escribir políticas que evalúan las entradas, configuraciones y salidas del pipeline contra tus requisitos de seguridad.

Verificaciones de políticas comunes en CI/CD:

  • Políticas de imágenes de contenedor — sin etiquetas latest, las imágenes deben provenir de registros aprobados, sin ejecución como root
  • Políticas de despliegue en Kubernetes — límites de recursos requeridos, sin contenedores privilegiados, las políticas de red deben existir
  • Políticas de Infraestructura como Código — sin buckets S3 públicos, cifrado habilitado, grupos de seguridad con alcance apropiado
  • Políticas de pipeline — aprobación requerida antes del despliegue en producción, todas las pruebas deben pasar, resultados de escaneo de vulnerabilidades dentro de los umbrales

Conftest para Evaluación de Políticas en CI/CD

Conftest es una utilidad que facilita la ejecución de políticas OPA/Rego contra datos de configuración estructurados en pipelines CI/CD. Soporta YAML, JSON, HCL, Dockerfile y muchos otros formatos, lo que lo hace lo suficientemente versátil para validar manifiestos de Kubernetes, planes de Terraform, Dockerfiles y configuraciones de pipeline.

Una etapa típica de aplicación de políticas en un pipeline:

  1. Descargar políticas de un repositorio de políticas central (versionado y revisado)
  2. Ejecutar Conftest contra los archivos de configuración relevantes
  3. Hacer fallar el pipeline si se viola alguna política obligatoria
  4. Generar un informe de evaluación de políticas como artefacto del pipeline

Puertas de Seguridad

Más allá de las políticas de configuración, la seguridad efectiva de CI/CD requiere puertas de seguridad automatizadas — puntos de control en el pipeline donde se deben cumplir criterios de seguridad antes de proceder. Estas incluyen:

  • Puertas de análisis estático — el código debe pasar el escaneo SAST sin hallazgos críticos
  • Puertas de dependencias — sin CVEs críticos o altos conocidos en dependencias
  • Puertas de escaneo de imágenes — las imágenes de contenedor deben pasar el escaneo de vulnerabilidades
  • Puertas de cumplimiento — las configuraciones de infraestructura deben cumplir los estándares de cumplimiento
  • Puertas de aprobación — los despliegues en producción requieren aprobación humana explícita

Para orientación integral sobre la implementación de la aplicación de políticas en tus pipelines, consulta: Política como Código en CI/CD: OPA, Rego y Puertas de Seguridad.

Mejores Prácticas de Hardening de Pipelines

Más allá de los dominios específicos cubiertos anteriormente, existen prácticas fundamentales de hardening que se aplican en todas las plataformas y arquitecturas CI/CD. Estas prácticas reducen tu superficie de ataque, limitan el radio de impacto y hacen que tus pipelines sean resilientes al compromiso.

Permisos Mínimos (Mínimo Privilegio)

Cada componente en tu pipeline debería operar con los permisos mínimos requeridos para realizar su función:

  • Tokens de plataforma — El GITHUB_TOKEN de GitHub debería tener alcance de solo lectura por defecto, con permisos de escritura otorgados solo a pasos específicos que los necesiten
  • Credenciales cloud — Los roles IAM deberían tener alcance a recursos y acciones específicas, no políticas amplias como AdministratorAccess
  • Acceso a registros — El acceso de push debería restringirse a pipelines de despliegue, no a cada compilación CI
  • Acceso a repositorios — Las cuentas de servicio del pipeline solo deberían tener acceso a los repositorios que necesitan

Entornos de Compilación Efímeros

Los entornos de compilación deberían ser efímeros — creados frescos para cada ejecución de pipeline y destruidos después. Los servidores de compilación persistentes acumulan estado, credenciales en caché y potenciales compromisos con el tiempo. Los runners efímeros aseguran:

  • Sin contaminación entre compilaciones — cada compilación comienza limpia
  • Sin credenciales persistentes — nada sobrevive más allá de la compilación
  • Superficie de ataque reducida — sin servicios de larga ejecución que atacar
  • Entornos consistentes — sin deriva de configuración

Fijación de Acciones y Plugins

Las acciones, plugins y componentes reutilizables de terceros deberían estar fijados a versiones específicas e inmutables — preferiblemente por SHA de commit, no por etiqueta mutable. Fijar por etiqueta (por ejemplo, v1) es vulnerable al secuestro de etiquetas, donde un atacante sube código malicioso y mueve la etiqueta para apuntar a él.

# Mal: Etiqueta mutable, vulnerable al secuestro
- uses: actions/checkout@v4

# Bien: Fijado a SHA de commit inmutable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Protección de Ramas y Controles de Fusión

Las reglas de protección de ramas son tu primera línea de defensa contra cambios de código no autorizados:

  • Requerir revisiones de pull request antes de fusionar a ramas protegidas
  • Requerir comprobaciones de estado (CI debe pasar) antes de fusionar
  • Requerir commits firmados para autoría verificada
  • Restringir quién puede hacer push a ramas protegidas
  • Prevenir force pushes que podrían reescribir el historial
  • Requerir historial lineal para mantener la auditabilidad

Controles de Despliegue

Los despliegues en producción deberían tener salvaguardas adicionales:

  • Reglas de protección de entorno — requerir aprobación manual para despliegues en producción
  • Congelamiento de despliegues — capacidad de detener despliegues durante incidentes o congelamiento de cambios
  • Despliegues canary y progresivos — limitar el radio de impacto desplegando cambios gradualmente
  • Capacidades de rollback — rollback automatizado cuando fallan las comprobaciones de salud del despliegue

Separación de Responsabilidades

Ninguna persona o sistema individual debería controlar todo el pipeline desde el commit de código hasta el despliegue en producción. Implementa la separación de responsabilidades mediante:

  • Requerir revisión de código de alguien que no sea el autor
  • Separar los permisos de CI (compilación/pruebas) de los permisos de CD (despliegue)
  • Usar credenciales separadas para diferentes etapas del pipeline
  • Requerir aprobación multipartita para cambios sensibles

Para orientación detallada sobre hardening de tus pipelines, consulta:

Guía Específica por Plataforma

Si bien los principios de seguridad de CI/CD son universales, cada plataforma tiene su propio modelo de seguridad, características y trampas. Aquí hay una breve descripción general de las principales plataformas con enlaces a guías detalladas.

GitHub Actions

GitHub Actions es la plataforma CI/CD más ampliamente adoptada para proyectos de código abierto y muchos proyectos comerciales. Las consideraciones de seguridad clave incluyen:

  • Permisos de GITHUB_TOKEN — establece permissions a nivel de workflow con valores predeterminados de solo lectura, otorgando escritura solo donde sea necesario
  • Manejo de forks — pull_request_target es extremadamente peligroso si se usa incorrectamente; prefiere pull_request para código no confiable
  • Fijación de acciones — fija todas las acciones de terceros por SHA de commit
  • Protección de entorno — usa entornos con revisores requeridos y políticas de rama de despliegue
  • OIDC — usa el proveedor OIDC de GitHub para autenticación sin claves con AWS, GCP y Azure
  • Workflows reutilizables — centraliza patrones de seguridad en workflows reutilizables mantenidos por el equipo de seguridad

GitLab CI

GitLab CI proporciona integración profunda con la plataforma DevSecOps más amplia de GitLab. Las consideraciones de seguridad clave incluyen:

  • Variables protegidas — marca las variables sensibles como protegidas y enmascaradas; restringe a ramas/etiquetas protegidas
  • Runners protegidos — usa runners protegidos para despliegues en producción, runners compartidos para compilaciones CI
  • Pipelines de merge request — usa rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" para controlar qué se ejecuta en contribuciones externas
  • OIDC/tokens de ID — GitLab soporta tokens OIDC mediante la palabra clave id_tokens para autenticación cloud sin claves
  • Frameworks de cumplimiento — usa las características de pipeline de cumplimiento de GitLab para aplicar trabajos requeridos

Tekton

Tekton es un framework CI/CD nativo de Kubernetes que proporciona propiedades de seguridad únicas a través de su arquitectura:

  • Aislamiento nativo de Kubernetes — cada TaskRun se ejecuta en su propio Pod, proporcionando aislamiento a nivel de contenedor por defecto
  • Alcance de cuentas de servicio — usa cuentas de servicio de Kubernetes dedicadas para cada pipeline con permisos RBAC mínimos
  • Tekton Chains — firma automática de artefactos y generación de procedencia, proporcionando cumplimiento SLSA de forma nativa
  • Bundles OCI — distribuye definiciones de pipeline como artefactos OCI para versionado y verificación de integridad
  • Control de admisión — integra con controladores de admisión de Kubernetes (por ejemplo, Kyverno, Gatekeeper) para aplicación de políticas

Consulta las hojas de referencia y laboratorios específicos por plataforma en nuestro sitio para orientación detallada y práctica para cada plataforma.

Hoja de Ruta de Implementación

Implementar la seguridad de CI/CD no sucede de la noche a la mañana. Aquí hay un enfoque por fases que te lleva desde la visibilidad básica hasta la aplicación integral.

Fase 1: Visibilidad (Semanas 1-4)

No puedes asegurar lo que no puedes ver. Comienza con un inventario y evaluación completos:

  • Audita todos los pipelines — inventaría cada pipeline CI/CD en tu organización, incluyendo sistemas CI paralelos que los equipos puedan haber configurado independientemente
  • Mapea el uso de secretos — identifica cada secreto, credencial y token usado en los pipelines. Documenta su alcance, duración y calendario de rotación
  • Escanea en busca de exposiciones — ejecuta herramientas de escaneo de secretos contra repositorios, definiciones de pipeline y logs de compilación para encontrar credenciales filtradas
  • Evalúa los permisos — revisa todas las cuentas de servicio, roles IAM y tokens de plataforma en busca de permisos excesivos
  • Documenta las fronteras de confianza — mapea qué pipelines pueden acceder a qué entornos, secretos y recursos

Fase 2: Fundamentos (Semanas 5-12)

Implementa controles de seguridad fundamentales que reducen el mayor riesgo con la menor complejidad:

  • Implementa mínimo privilegio — reduce todas las credenciales a los permisos mínimos requeridos. Establece GITHUB_TOKEN como solo lectura por defecto. Limita las credenciales cloud a recursos específicos
  • Fija todas las dependencias — fija acciones de terceros por SHA de commit, bloquea versiones de dependencias, fija imágenes base por digest
  • Asegura la gestión de secretos — migra a OIDC/federación de identidad de carga de trabajo donde sea posible. Implementa gestores de secretos externos para todo lo demás. Rota todas las credenciales
  • Habilita protección de ramas — requiere revisión de código, comprobaciones de estado y commits firmados en todas las ramas protegidas
  • Despliega runners efímeros — reemplaza servidores de compilación persistentes con runners efímeros y de entorno limpio

Fase 3: Integridad (Semanas 13-20)

Construye confianza en que los artefactos son auténticos y no han sido manipulados:

  • Implementa firma de artefactos — firma todas las imágenes de contenedor y artefactos de compilación usando Cosign con firma sin claves
  • Genera procedencia — produce procedencia SLSA para todos los artefactos de compilación, vinculándolos a su fuente, sistema de compilación y parámetros
  • Crea SBOMs — genera SBOMs para todos los artefactos, permitiendo respuesta rápida a vulnerabilidades
  • Aplica verificación de firmas — configura controladores de admisión (Kyverno, Gatekeeper, Sigstore policy-controller) para rechazar imágenes sin firmar o no verificadas
  • Establece compilaciones reproducibles — trabaja hacia compilaciones reproducibles para artefactos críticos

Fase 4: Aplicación (Semanas 21-30)

Automatiza la aplicación de seguridad para que sea consistente, escalable y no dependa del cumplimiento individual:

  • Implementa Política como Código — define políticas de seguridad en OPA/Rego y aplícalas con Conftest en cada pipeline
  • Despliega controladores de admisión — aplica políticas en tiempo de ejecución en Kubernetes que validen imágenes, configuraciones y despliegues
  • Automatiza comprobaciones de cumplimiento — integra validación de cumplimiento en pipelines con recopilación automatizada de evidencia
  • Implementa puertas de seguridad — agrega puntos de control de seguridad obligatorios que bloquean la progresión a través del pipeline cuando no se cumplen los criterios
  • Monitoreo continuo — configura alertas para violaciones de políticas, comportamiento anómalo del pipeline y cambios no autorizados

Laboratorios Prácticos

La teoría es esencial, pero la práctica es donde se desarrollan las habilidades de seguridad. Proporcionamos laboratorios prácticos que te permiten implementar cada concepto cubierto en esta guía en un entorno CI/CD real:

Herramientas y Recursos

El ecosistema de seguridad de CI/CD incluye un conjunto creciente de herramientas especializadas. Aquí están las categorías esenciales y las herramientas clave:

Escaneo y Gestión de Secretos

  • GitLeaks / TruffleHog — escanea repositorios e historial de commits en busca de secretos expuestos
  • HashiCorp Vault — secretos dinámicos, gestión de credenciales y cifrado como servicio
  • AWS Secrets Manager / GCP Secret Manager / Azure Key Vault — gestión de secretos nativa de la nube

Integridad de Artefactos

  • Sigstore (Cosign, Fulcio, Rekor) — firma sin claves, autoridad de certificación y log de transparencia
  • in-toto — framework de integridad de cadena de suministro
  • SLSA framework — niveles de seguridad de cadena de suministro y procedencia
  • Syft / Trivy — generación de SBOM y escaneo de vulnerabilidades

Aplicación de Políticas

  • OPA / Conftest — motor de políticas de propósito general para validación de configuración
  • Kyverno — motor de políticas nativo de Kubernetes
  • Gatekeeper — integración de OPA para control de admisión de Kubernetes

Escaneo de Seguridad de Pipelines

  • Checkov — escaneo de infraestructura como código (Terraform, CloudFormation, Kubernetes)
  • StepSecurity Harden-Runner — seguridad en tiempo de ejecución para GitHub Actions
  • Snyk — escaneo de seguridad amigable para desarrolladores para código, dependencias y contenedores

Para comparaciones detalladas de herramientas y recomendaciones, visita nuestra página de Recursos.

Conclusión

La seguridad de pipelines CI/CD no es una sola herramienta, una sola práctica ni un esfuerzo único. Es una disciplina integral que abarca todo el ciclo de vida de entrega de software — desde el commit del desarrollador a través de la compilación, pruebas, empaquetado y despliegue en producción.

Las conclusiones clave de esta guía:

  1. Los pipelines son objetivos de alto valor — tienen acceso privilegiado a todo. Trátalos con el mismo rigor de seguridad que los sistemas de producción.
  2. Comprende tus fronteras de confianza — sabe quién activa tus pipelines, qué código se ejecuta y qué recursos son accesibles en cada etapa.
  3. Los secretos son tu mayor riesgo — elimina las credenciales de larga duración siempre que sea posible. Usa OIDC, identidad de carga de trabajo y secretos dinámicos.
  4. Verifica la integridad de los artefactos — firma todo, genera procedencia, crea SBOMs y aplica verificación en el despliegue.
  5. Automatiza la aplicación — codifica los requisitos de seguridad como Política como Código. Los procesos manuales no escalan y no sobreviven la presión de los plazos.
  6. Fortalece progresivamente — usa la hoja de ruta por fases para mejorar sistemáticamente tu postura de seguridad sin interrumpir la velocidad de entrega.

La superficie de ataque es amplia, pero las soluciones están madurando rápidamente. El ecosistema Sigstore, el framework SLSA, OPA/Conftest, la federación OIDC y los controladores de admisión de Kubernetes proporcionan un conjunto de herramientas robusto para construir pipelines genuinamente seguros.

Comienza donde estás. Audita tu estado actual, implementa los fundamentos y agrega progresivamente controles de integridad y aplicación. Cada paso que das cierra una brecha que los atacantes podrían explotar.

Explora las guías detalladas, laboratorios prácticos y recursos enlazados a lo largo de esta publicación para profundizar en cada tema. Los pipelines seguros no se construyen en un día — pero con el conocimiento y las herramientas adecuadas, están absolutamente al alcance.