OWASP Top 10 Riesgos de Seguridad CI/CD

1�E�⃣ CICD-SEC-1 - Mecanismos de Control de Flujo Insuficientes

Descripción General

Los mecanismos de control de flujo insuficientes permiten a los atacantes enviar código malicioso a través de los pipelines CI/CD sin revisión o puertas de aprobación adecuadas. Esto incluye eludir las reglas de protección de ramas, la falta de aprobaciones requeridas y la falta de control sobre quién puede activar despliegues a producción.

Ejemplo de Código Vulnerable

# No branch protection  Eanyone can push directly to main
name: Deploy
on:
  push:
    branches: [main]  # Triggers on any push to main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: |
        # Deploys immediately  Eno approval gate!
        kubectl apply -f deploy.yaml
        kubectl rollout status deployment/myapp

Ejemplo de Código Seguro

name: Deploy
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: npm test
  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production  # Requires manual approval
    steps:
    - uses: actions/checkout@v4
    - run: |
        kubectl apply -f deploy.yaml
        kubectl rollout status deployment/myapp

Lista de Verificación de Mitigación

• Aplique reglas de protección de ramas que requieran revisiones de PR antes de fusionar a main
• Use reglas de protección de entorno con aprobadores requeridos para despliegues a producción
• Implemente verificaciones de estado (pruebas, escaneos de seguridad) que deben pasar antes de la fusión
• Restrinja quién puede enviar código a ramas protegidas y activar despliegues a producción

2�E�⃣ CICD-SEC-2 - Gestión Inadecuada de Identidad y Acceso

Descripción General

Los sistemas CI/CD involucran múltiples identidades: usuarios humanos, cuentas de servicio, tokens de bots e identidades de máquinas. La gestión inadecuada de IAM permite acceso excesivamente permisivo a repositorios, pipelines y objetivos de despliegue. Las credenciales compartidas, las cuentas obsoletas y la falta de MFA agravan el riesgo.

Ejemplo de Código Vulnerable

# Over-permissive workflow with admin token
name: CI
on: push
permissions: write-all  # Full permissions to everything!
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: |
        # Using org-wide PAT with admin access
        curl -H "Authorization: token ${{ secrets.ADMIN_PAT }}" \
          https://api.github.com/repos/org/other-repo/contents/

Ejemplo de Código Seguro

name: CI
on: push
permissions:
  contents: read    # Minimum required permissions
  packages: write   # Only what's needed
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/create-github-app-token@v1  # Scoped app token
      id: app-token
      with:
        app-id: ${{ vars.APP_ID }}
        private-key: ${{ secrets.APP_PRIVATE_KEY }}
        repositories: other-repo  # Scoped to specific repo

Lista de Verificación de Mitigación

• Aplique permisos de mínimo privilegio a todos los tokens de workflow y cuentas de servicio
• Use GitHub Apps o federación OIDC en lugar de PATs de larga duración
• Aplique MFA para todas las cuentas humanas con acceso a CI/CD
• Audite y rote regularmente las credenciales; elimine cuentas y tokens obsoletos

3�E�⃣ CICD-SEC-3 - Abuso de la Cadena de Dependencias

Descripción General

Los pipelines CI/CD obtienen dependencias de registros de paquetes externos (npm, PyPI, Maven, Docker Hub). Los atacantes explotan esto a través de confusión de dependencias, typosquatting, cuentas de mantenedores comprometidas y paquetes maliciosos. Una sola dependencia envenenada puede ejecutar código arbitrario durante la construcción.

Ejemplo de Código Vulnerable

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        // No lockfile verification, no integrity checks
        sh 'npm install'           // Fetches latest  Ecould be compromised!
        sh 'pip install -r requirements.txt'  // No hash verification
      }
    }
  }
}

Ejemplo de Código Seguro

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        // Use lockfile with integrity verification
        sh 'npm ci'                   // Uses package-lock.json
        sh 'npm audit --audit-level=high'
        // Python: verify hashes from lockfile
        sh 'pip install --require-hashes -r requirements.lock'
      }
    }
    stage('SCA Scan') {
      steps {
        // Software Composition Analysis
        sh 'trivy fs --scanners vuln,secret .'
      }
    }
  }
}

Lista de Verificación de Mitigación

• Siempre use lockfiles (package-lock.json, Pipfile.lock) y verifique los hashes de integridad
• Configure registros de paquetes privados/internos con alcance de namespace para prevenir confusión de dependencias
• Ejecute herramientas de Análisis de Composición de Software (SCA) en cada pipeline de construcción
• Fije las dependencias a versiones exactas y revise todas las actualizaciones de dependencias antes de fusionar

4�E�⃣ CICD-SEC-4 - Ejecución Envenenada de Pipeline (PPE)

Descripción General

La Ejecución Envenenada de Pipeline (PPE) ocurre cuando los atacantes pueden modificar las definiciones del pipeline CI/CD o inyectar código malicioso que se ejecuta dentro del contexto del pipeline. Esto puede suceder mediante la manipulación de archivos de configuración del pipeline en ramas, pull requests de forks o la modificación de plantillas de pipeline compartidas.

Ejemplo de Código Vulnerable

# Runs pipeline from fork PRs with access to secrets
name: CI
on:
  pull_request_target:  # Runs in base repo context with secrets!
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }}  # Checks out fork code!
    - run: make build  # Fork's Makefile executes with secrets access
      env:
        DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Ejemplo de Código Seguro

# Separate workflows: untrusted build + trusted deploy
name: CI
on:
  pull_request:  # No secret access for PR builds
    branches: [main]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4  # Checks out merge commit (safe)
    - run: npm ci && npm test   # No secrets needed for build/test
    - uses: actions/upload-artifact@v4
      with:
        name: build-output
        path: dist/

Lista de Verificación de Mitigación

• Nunca use pull_request_target con checkout del código del PR y acceso a secretos combinados
• Separe las etapas de construcción (no confiable) y despliegue (confiable) en workflows diferentes
• Requiera aprobación para workflows de PR de forks y limite la exposición de secretos
• Use definiciones de pipeline inmutables que no puedan ser modificadas por los contribuidores

5�E�⃣ CICD-SEC-5 - Controles de Acceso Basados en Pipeline (PBAC) Insuficientes

Descripción General

Los Controles de Acceso Basados en Pipeline (PBAC) gobiernan a qué recursos puede acceder un pipeline: cuentas de la nube, clústeres de Kubernetes, bases de datos y servicios internos. Un PBAC insuficiente significa que los pipelines tienen un acceso más amplio del necesario, violando el principio de mínimo privilegio.

Ejemplo de Código Vulnerable

# Pipeline with admin-level cloud credentials
deploy:
  stage: deploy
  script:
    - aws configure set aws_access_key_id $AWS_ACCESS_KEY
    - aws configure set aws_secret_access_key $AWS_SECRET_KEY
    # This key has AdministratorAccess policy!
    - aws s3 sync dist/ s3://my-bucket/
    - aws ecs update-service --cluster prod --service myapp
    # Same credentials could access ANY AWS resource

Ejemplo de Código Seguro

name: Deploy
on:
  push:
    branches: [main]
permissions:
  id-token: write  # For OIDC
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456:role/deploy-s3-only
        # Scoped role: only s3:PutObject on specific bucket
        aws-region: us-east-1
    - run: aws s3 sync dist/ s3://my-bucket/

Lista de Verificación de Mitigación

• Use federación OIDC para acceso a la nube en lugar de credenciales estáticas en CI/CD
• Defina roles IAM por pipeline limitados solo a los recursos que ese pipeline necesita
• Separe los roles de despliegue por entorno (staging vs. producción)
• Audite los patrones de acceso del pipeline y alerte sobre acceso a recursos fuera del alcance

6�E�⃣ CICD-SEC-6 - Higiene de Credenciales Insuficiente

Descripción General

Los pipelines CI/CD manejan numerosas credenciales: claves API, tokens de la nube, contraseñas de registros, claves SSH y certificados de firma. La mala higiene de credenciales incluye codificar secretos en archivos de pipeline, imprimir secretos en logs, usar almacenamiento de secretos sin cifrar y nunca rotar credenciales.

Ejemplo de Código Vulnerable

#!/bin/bash
# Secrets hardcoded and leaked in logs
export DOCKER_PASSWORD="MyS3cret!"         # Hardcoded!
echo "Logging in with $DOCKER_PASSWORD"  # Printed to logs!

docker login -u admin -p "$DOCKER_PASSWORD" registry.example.com
docker push registry.example.com/myapp:latest

# AWS credentials in environment  Evisible in process listing
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCY"
aws s3 cp artifact.zip s3://releases/

Ejemplo de Código Seguro

name: Publish
on:
  push:
    tags: ['v*']
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: docker/login-action@v3  # Handles credentials securely
      with:
        registry: registry.example.com
        username: ${{ secrets.DOCKER_USER }}   # Masked in logs
        password: ${{ secrets.DOCKER_TOKEN }}  # Short-lived token
    - run: |
        docker build -t registry.example.com/myapp:${{ github.ref_name }} .
        docker push registry.example.com/myapp:${{ github.ref_name }}

Lista de Verificación de Mitigación

• Nunca codifique secretos en definiciones de pipeline, scripts o código fuente
• Use la gestión de secretos de la plataforma CI/CD con enmascaramiento automático de logs
• Rote todas las credenciales CI/CD regularmente y use tokens de corta duración donde sea posible
• Escanee repositorios y logs de construcción en busca de secretos expuestos accidentalmente

7�E�⃣ CICD-SEC-7 - Configuración Insegura del Sistema

Descripción General

Los sistemas CI/CD (Jenkins, GitLab, runners de GitHub Actions) a menudo se ejecutan con configuraciones predeterminadas inseguras. Esto incluye versiones de software desactualizadas, interfaces de gestión expuestas, funciones de seguridad deshabilitadas, acceso de red excesivamente permisivo y runners autoalojados compartidos entre proyectos.

Ejemplo de Código Vulnerable

// Jenkins with insecure configuration
// - Script console enabled without auth
// - Agent-to-controller access unrestricted
// - Outdated plugins with known CVEs

pipeline {
  agent any  // Runs on any available agent  Eno isolation
  stages {
    stage('Build') {
      steps {
        // Running as root on shared agent
        sh 'whoami'  // root
        sh 'docker build -t myapp .'
      }
    }
  }
}

Ejemplo de Código Seguro

pipeline {
  agent {
    kubernetes {  // Ephemeral, isolated pod per build
      yaml """
        apiVersion: v1
        kind: Pod
        spec:
          securityContext:
            runAsNonRoot: true
            runAsUser: 1000
          containers:
          - name: builder
            image: builder:1.2.3
            securityContext:
              allowPrivilegeEscalation: false
              readOnlyRootFilesystem: true
      """
    }
  }
  stages {
    stage('Build') {
      steps {
        container('builder') {
          sh 'make build'
        }
      }
    }
  }
}

Lista de Verificación de Mitigación

• Use entornos de construcción efímeros y aislados (contenedores/VMs) que se destruyan después de cada construcción
• Mantenga la plataforma CI/CD y todos los plugins actualizados a las últimas versiones
• Restrinja el acceso de red desde los entornos de construcción; bloquee el tráfico saliente innecesario
• Ejecute los agentes de construcción como no-root con capacidades mínimas y sistemas de archivos de solo lectura

8�E�⃣ CICD-SEC-8 - Uso No Gobernado de Servicios de Terceros

Descripción General

Los pipelines CI/CD a menudo se integran con servicios de terceros: herramientas de calidad de código, escáneres de seguridad, sistemas de notificación y plataformas de despliegue. Estas integraciones reciben tokens de acceso y permisos, creando una cadena de confianza. El uso no gobernado significa que no hay visibilidad sobre a qué pueden acceder o hacer los servicios de terceros.

Ejemplo de Código Vulnerable

name: CI
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: npm test
    # Unknown third-party action with full repo access
    - uses: random-org/code-analysis@main  # Unpinned, unvetted!
      with:
        token: ${{ secrets.GITHUB_TOKEN }}   # Full token access!
    # Uploading coverage to external service with repo token
    - run: |
        bash <(curl -s https://example.com/uploader.sh)  # Remote script!

Ejemplo de Código Seguro

name: CI
on: push
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: npm test
    # Vetted action pinned to SHA
    - uses: github/codeql-action/analyze@8a470fddafa5cbc14  # Pinned SHA
    # Upload via official CLI tool, not remote scripts
    - uses: codecov/codecov-action@e28ff129e5465c2c0dcc6f003fc735cb6ae0c673
      with:
        token: ${{ secrets.CODECOV_TOKEN }}  # Scoped token
        fail_ci_if_error: true

Lista de Verificación de Mitigación

• Mantenga un inventario de todos los servicios de terceros integrados con CI/CD
• Fije las acciones de terceros a hashes SHA y audite antes de adoptar
• Nunca ejecute scripts remotos (curl | bash) en los pipelines
• Revise y minimice regularmente los permisos otorgados a integraciones de terceros

9�E�⃣ CICD-SEC-9 - Validación Inadecuada de Integridad de Artefactos

Descripción General

Los artefactos de construcción (imágenes de contenedores, binarios, paquetes) fluyen a través de los pipelines CI/CD hacia producción. Sin validación de integridad, los artefactos pueden ser alterados en cualquier punto: durante la construcción, en tránsito, en el registro de artefactos o en el momento del despliegue. Esto rompe la cadena de confianza del código a producción.

Ejemplo de Código Vulnerable

#!/bin/bash
# Build and deploy without any integrity checks
docker build -t myregistry.com/app:latest .
docker push myregistry.com/app:latest

# On deployment side  Eno verification
docker pull myregistry.com/app:latest  # Could be tampered!
docker run myregistry.com/app:latest   # Tag is mutable!

Ejemplo de Código Seguro

name: Build and Sign
on:
  push:
    tags: ['v*']
permissions:
  id-token: write
  packages: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: |
        # Build with immutable tag (SHA)
        docker build -t myregistry.com/app:${{ github.sha }} .
        docker push myregistry.com/app:${{ github.sha }}
    - uses: sigstore/cosign-installer@v3
    - run: |
        # Sign image with keyless signing (Sigstore)
        cosign sign myregistry.com/app:${{ github.sha }}
        # Generate and attach SBOM
        syft myregistry.com/app:${{ github.sha }} -o spdx-json > sbom.json
        cosign attest --predicate sbom.json myregistry.com/app:${{ github.sha }}

Lista de Verificación de Mitigación

• Firme todos los artefactos de construcción (imágenes, binarios) usando Cosign/Sigstore o Notary
• Verifique las firmas en el momento del despliegue con controladores de admisión (Kyverno, OPA Gatekeeper)
• Use etiquetas inmutables (digests SHA) en lugar de etiquetas mutables como :latest
• Implemente procedencia SLSA para establecer una cadena verificable del código fuente al artefacto

🔟 CICD-SEC-10 - Registro y Visibilidad Insuficientes

Descripción General

Los entornos CI/CD generan eventos de seguridad críticos: ejecuciones de pipelines, cambios de configuración, acceso a secretos y actividades de despliegue. Sin registro y monitoreo exhaustivos, las actividades maliciosas en el pipeline pasan desapercibidas y la respuesta a incidentes se ve gravemente obstaculizada.

Ejemplo de Código Vulnerable

#!/bin/bash
# Pipeline with no logging or audit trail
echo "Starting deployment..."
kubectl apply -f deploy.yaml
echo "Done."

# No record of: who triggered this, what changed,
# which image was deployed, what secrets were accessed
# Build logs expire after 30 days with no archival

Ejemplo de Código Seguro

name: Audited Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Log deployment metadata
      run: |
        echo "=== Deployment Audit Log ==="
        echo "Triggered by: ${{ github.actor }}"
        echo "Commit: ${{ github.sha }}"
        echo "Ref: ${{ github.ref }}"
        echo "Workflow: ${{ github.workflow }}"
        echo "Run ID: ${{ github.run_id }}"
    - name: Deploy with audit
      run: |
        kubectl apply -f deploy.yaml 2>&1 | tee deploy.log
        # Send audit event to SIEM
        curl -X POST "${{ secrets.SIEM_WEBHOOK }}" \
          -d '{"event":"deploy","actor":"${{ github.actor }}","sha":"${{ github.sha }}"}'

Lista de Verificación de Mitigación

• Habilite el registro de auditoría para todas las actividades de la plataforma CI/CD (cambios en pipelines, acceso a secretos, acciones de usuarios)
• Reenvíe los registros de auditoría CI/CD a un SIEM centralizado con almacenamiento a prueba de manipulaciones
• Cree alertas para actividades sospechosas: horarios de despliegue inusuales, cambios de configuración, nuevas integraciones de servicios
• Retenga los registros de construcción y despliegue para cumplimiento y análisis forense

📊 Tabla de Resumen