Plantilla de Seguridad de Pipeline CI/CD

Descripción General

Los pipelines CI/CD son un objetivo de alto valor para los atacantes porque tienen acceso al código fuente, secretos de compilación y rutas de despliegue a producción. Un pipeline comprometido puede introducir malware, exfiltrar datos o desplegar cambios no autorizados. Esta plantilla define controles para proteger la integridad del código, la seguridad de los runners, los secretos y las aprobaciones de despliegue. Para el lado estratégico, consulta la guía de seguridad CI/CD; para la mitad del problema que son los secretos, la receta de gestión de secretos en Docker cubre el ángulo de contenedores.

Cuándo Usar

• Al configurar una nueva plataforma CI/CD.
• Al revisar o mejorar un pipeline existente.
• Al prepararse para una auditoría de seguridad de la cadena de suministro.
• Después de un compromiso del sistema de compilación o un despliegue no autorizado.
• Al integrar controles DevSecOps en los flujos de trabajo de ingeniería.

Prerequisitos

• Un sistema de control de versiones con protección de ramas y registro de auditoría.
• Una plataforma CI/CD como GitHub Actions, GitLab CI, Azure DevOps o Jenkins.
• Una solución de gestión de secretos para credenciales de pipeline.
• Un proceso de revisión y aprobación de código antes de integrar cambios.
• Responsables por parte de ingeniería de plataforma, seguridad y gestión de releases.

Solución

Plantilla

1. Seguridad del Control de Código

Control	Requisito	Verificación
Protección de ramas	Revisiones requeridas antes de integrar a main	Configuración del repositorio
Commits firmados	Requerir commits verificados para cuentas privilegiadas	Configuración de Git
Control de acceso	Acceso de mínimo privilegio a repositorios	Revisión de RBAC
Registro de auditoría	Todos los pushes, merges y cambios de permisos registrados	Logs de la plataforma
Dependencias fijadas	Lockfiles y versiones fijas para compilaciones reproducibles	Archivos del repositorio
Escaneo de secretos	Detección automatizada de secretos en commits	Pre-commit hooks + CI

2. Configuración del Pipeline

Control	Requisito	Verificación
Definiciones inmutables de pipeline	Pipelines almacenados como código y revisados	Archivos del repositorio
Sin secretos en código	Secretos cargados desde vault, variables de CI u OIDC	Escaneo de secretos
Validación de entrada	Parámetros del pipeline validados y sanitizados	Revisión de código
Aislamiento de runners self-hosted	Runners de producción aislados de los de desarrollo	Configuración de runners
Runners efímeros	Runner nuevo por build para reducir persistencia	Configuración de runners
Provenance del pipeline	Provenance SLSA generada para los artefactos	Herramienta de atestación

3. Gestión de Secretos

Tipo de Secreto	Almacenamiento	Rotación	Alcance
Credenciales de nube	Vault externo u OIDC	90 días	Por entorno
Tokens de registry de contenedores	Vault o tokens de CI de corta duración	90 días	Por pipeline
Claves de firma	Hardware-backed o KMS	180 días	Cuentas de servicio limitadas
Claves de API	Vault o gestor de secretos	90 días	Permisos mínimos requeridos
Contraseñas de base de datos	Secretos dinámicos de vault	24 horas	Por ejecución de pipeline

4. Seguridad de la Compilación

Control	Requisito	Verificación
Escaneo de dependencias	Todas las dependencias escaneadas por CVEs conocidos	Escáner en CI
Análisis estático	SAST en cada pull request	Job de CI
Escaneo de imágenes de contenedor	Imagen base y capas escaneadas antes del push	Escaneo del registry
Compilaciones reproducibles	El mismo código fuente produce el mismo artefacto	Verificación de build
Firma de artefactos	Todos los artefactos firmados con identidad de build	Verificación de firma
Generación de SBOM	Lista de materiales generada por build	Output de CI

5. Seguridad del Despliegue

Control	Requisito	Verificación
Puertas de despliegue	Aprobación manual o automatizada antes de producción	Reglas del pipeline
Separación de entornos	Credenciales de producción no disponibles en desarrollo	Alcance de secretos
Plan de rollback	Trigger de rollback automático ante fallos	Definición del pipeline
Despliegues inmutables	Artefactos desplegados por referencia, no reconstruidos	Logs de despliegue
Detección de drift	Cambios no autorizados en producción detectados	Herramienta de monitoreo
Trazabilidad	Quién desplegó qué, cuándo y por qué	Logs de despliegue

6. Respuesta a Incidentes

Escenario	Respuesta	Responsable
Secreto filtrado	Rotar secreto, revocar tokens, auditar uso	Equipo de seguridad
Commit malicioso	Revertir, investigar, revocar credenciales	Equipo de plataforma
Runner comprometido	Terminar runner, reconstruir, revisar logs	Equipo de plataforma
Despliegue no autorizado	Rollback, congelar pipeline, auditar	Release manager
Artefacto manipulado	Bloquear despliegue, rastrear provenance	Equipo de seguridad

Explicación

La seguridad del pipeline es seguridad de la cadena de suministro aplicada a la máquina que publica tu código. Protege el código fuente, la compilación y la ruta de despliegue y habrás cortado la mayoría de las vías por las que código malicioso llega a producción. La plantilla mapea cada control a cómo verificarlo, así que también sirve como artefacto de auditoría.

Configuración de Seguridad para GitHub Actions

name: Secure CI Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/ci-role
          aws-region: us-east-1
          # No static keys - OIDC only

      - name: Build and sign
        uses: sigstore/cosign-installer@v3
      - run: |
          cosign sign-blob --yes artifact.tar.gz

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Scan dependencies
        uses: github/codeql-action/init@v3
      - run: npm audit --audit-level=high
      - uses: github/codeql-action/analyze@v3

Ejemplo de Provenance SLSA

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "artifact.tar.gz",
      "digest": { "sha256": "abc123..." }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "builder": { "id": "github-actions" },
    "buildType": "https://github.com/actions/runner",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/org/repo",
        "digest": { "sha1": "commit-hash" }
      }
    },
    "materials": [
      { "uri": "git+https://github.com/org/repo", "digest": { "sha1": "commit-hash" } }
    ]
  }
}

Checklist de Auditoría de Seguridad del Pipeline

Control	Verificado	Notas
Sin secretos de larga duración en CI
OIDC para autenticación en la nube
Actions fijadas a SHA
Permisos mínimos por job
Protección de rama en main
Artefactos firmados verificados
SBOM generado por build
Escaneo de dependencias en el pipeline
Runners aislados por entorno
Retención de logs de auditoría > 90 días

Ataques Reales al Pipeline

Estos controles no son higiene hipotética: mapean a incidentes que ya ocurrieron.

SolarWinds (2020). Los atacantes comprometieron el propio sistema de build y publicaron una actualización de Orion con backdoor a miles de organizaciones, firmada y distribuida por el canal oficial. Es el caso canónico de por qué importan la provenance del build y los builds reproducibles: el artefacto malicioso pasó todas las verificaciones del lado del consumidor porque el compromiso ocurrió aguas arriba.

Codecov (2021). Un script bash uploader modificado dentro de las herramientas de CI de Codecov exfiltró variables de entorno, incluyendo secretos, de miles de pipelines de clientes durante dos meses. El control exacto que lo habría detectado: dependencias fijadas con hash y alertas sobre tráfico saliente inesperado desde los runners.

tj-actions/changed-files (2025). Un GitHub Action popular fue comprometido y publicó una release maliciosa que filtró secretos de CI en los logs de workflow. Los equipos que fijaban las actions a SHAs de commit eran inmunes por defecto. Los tags se movieron al commit malicioso; los SHAs no.

Servidor git de PHP (2021). Los atacantes pushearon commits con backdoor directamente al repositorio propio de PHP, suplantando a maintainers del core. La respuesta fue instructiva: PHP abandonó su git self-hosted y se movió a GitHub con 2FA obligatorio — a veces la solución es externalizar la frontera de confianza a una plataforma con mejores controles.

El patrón en los cuatro: el pipeline es confiable por defecto, y esa confianza es exactamente lo que explotan los atacantes. Una plantilla como esta existe para hacer la confianza explícita y verificable en lugar de asumida.

Variantes

• Checklist de seguridad para GitHub Actions: enfocado en fijar actions, permisos de workflow y workflows reutilizables.
• Plantilla de seguridad para GitLab CI: incluye scopes de tokens de job CI/CD, runners protegidos y pipelines de compliance.
• Plantilla de endurecimiento de Jenkins: cubre gestión de plugins, aislamiento de agentes y sandboxing de Groovy.
• Pipeline nativo de contenedores: enfatiza firma de imágenes, escaneo del registry y admission de Kubernetes.
• Pipeline de alta compliance: añade SLSA Nivel 3, doble aprobación y SBOMs firmados para entornos regulados.

Lo que funciona

• Almacenar las definiciones del pipeline como código y revisarlas como código de aplicación.
• Usar credenciales de corta duración y OIDC en lugar de secretos de larga duración.
• Escanear dependencias antes de integrar y antes de desplegar.
• Firmar artefactos y verificar firmas antes del despliegue.
• Separar los entornos de build y producción física o lógicamente.
• Requerir aprobación humana para despliegues a producción.
• Generar y retener SBOMs para cada release.
• Monitorear la actividad del pipeline buscando comportamiento inusual.

Errores Comunes

• Almacenar secretos en variables de entorno o archivos del pipeline.
• Usar actions de terceros sin fijarlas ni revisarlas.
• Permitir que cualquier rama despliegue a producción.
• Correr cargas de producción y desarrollo en el mismo runner.
• Saltarse los escaneos de seguridad en despliegues de hotfix.
• No rotar las credenciales del pipeline tras un compromiso.
• Confiar en artefactos sin verificación de firma.

Troubleshooting

• Un secreto aparece en un log de build: rótalo inmediatamente y asume que está comprometido en el momento en que se imprime. Luego encuentra la ruta de código que lo registró (normalmente un echo sin enmascarar o un volcado de error) y añade el valor a la lista de enmascaramiento de logs.
• Un escaneo de dependencias falla por un CVE transitivo que no puedes arreglar: comprueba si la ruta de código vulnerable es realmente alcanzable. Si no lo es, documenta el riesgo aceptado con fecha de revisión y fija una excepción; si lo es, sube la dependencia padre o aplica un parche vendorizado.
• La verificación de provenance falla al desplegar: no despliegues. Una atestación que no coincide significa que el artefacto no es lo que CI construyó. Compara el digest con el almacén de artefactos de CI y averigua dónde ocurrió la sustitución antes de publicar nada.
• Una puerta de aprobación es ignorada: revisa quién tiene derechos de administrador sobre las reglas de protección del entorno. Las puertas fallan abiertas más a menudo por permisos mal configurados que por atacantes.
• Un action de terceros publica una release maliciosa: si fijas a SHAs de commit esto no puede alcanzarte — los tags se mueven, los SHAs no. Si estás en un tag, fija el SHA bueno conocido inmediatamente y audita lo que corrió en la ventana.

Ver También

• Framework SLSA — slsa.dev: los niveles de seguridad de cadena de suministro de los que salen los controles de provenance de esta plantilla
• Documentación de Sigstore cosign: firma de artefactos sin claves usada en el workflow de arriba
• Endurecimiento de seguridad para GitHub Actions: la guía propia de GitHub sobre permisos de workflow, OIDC y actions de terceros
• OWASP CI/CD Security Top 10: la lista de amenazas a la que mapean estos controles
• Framework de atestación in-toto: el estándar bajo las declaraciones de provenance SLSA
• Guía de seguridad CI/CD: la compañera estratégica de esta plantilla
• Receta de gestión de secretos en Docker: el lado del runtime de contenedores en el manejo de secretos

Código complementario: recursos de seguridad de pipeline CI/CD: la plantilla de controles, el workflow endurecido, el ejemplo de provenance SLSA y el checklist de auditoría de esta página.