Defensas basadas en tiempo en GitHub y PyPI para evitar ataques a la cadena de suministro

Introducción

Los ataques a la cadena de suministro de software se han intensificado en los últimos años, afectando repositorios críticos como npm, PyPI y Maven. Para mitigar este riesgo, GitHub y PyPI implementaron mecanismos basados en tiempo que introducen retrasos controlados en la publicación y actualización de dependencias. Estas medidas buscan limitar el impacto de paquetes maliciosos recién publicados, dando tiempo a los equipos de seguridad para detectar y bloquear amenazas antes de que sean incorporadas a proyectos.

En esta guía, verás cómo configurar estas defensas en Dependabot (GitHub) y en PyPI, junto con las mejores prácticas para integrarlas en pipelines de CI/CD y flujos de trabajo de desarrollo. Al finalizar, podrás reducir la ventana de exposición a paquetes maliciosos sin sacrificar la agilidad en la gestión de dependencias.

Qué es y para qué sirve

GitHub Dependabot: Cooldown de actualizaciones

• Detección temprana: Equipos de seguridad pueden identificar paquetes maliciosos antes de que sean adoptados masivamente.
• Reducción de riesgo: Los paquetes recién publicados, incluso si pasan filtros iniciales, deben esperar para ser incorporados.
• Flexibilidad: El cooldown puede ajustarse según la criticidad del proyecto (ej.: 24h para entornos de producción, 168h para desarrollos internos).

GitHub evaluó que este período equilibra la protección contra paquetes maliciosos rápidos con la necesidad de mantener actualizaciones oportunas. Sin embargo, reconoce que este mecanismo no es suficiente para compromisos a largo plazo (ej.: robo de tokens de publicación), por lo que recomienda combinarlo con:

• Uso de lockfiles para fijar versiones exactas de dependencias.
• Tokens con scopes restringidos (evitar tokens con permisos globales).
• Deshabilitar scripts de instalación innecesarios en pipelines de CI.

PyPI: Bloqueo de releases antiguos

• Poisoning de releases antiguos: Ataques que comprometen tokens de publicación para inyectar código malicioso en versiones ya liberadas y aparentemente seguras.
• Abuso de workflows comprometidos: Si un atacante obtiene acceso a un token de publicación, no podrá modificar releases históricos.

PyPI no reporta casos confirmados de ataques usando esta técnica, pero actúa de forma preventiva. Solo un ~1% de los proyectos en PyPI suben archivos después de 14 días, lo que valida la medida.

Prerequisitos

Antes de implementar estas defensas, asegúrate de:

• Cuenta de GitHub con permisos de administrador en el repositorio.
• Cuenta en PyPI con rol de maintainer o superior.
• Token de GitHub con repo y write scopes (para editar configuraciones de Dependabot).

Guía paso a paso

1. Configurar el cooldown de Dependabot en GitHub

Paso 1.1: Verificar configuración actual de Dependabot

Abre el archivo .github/dependabot.yml en tu repositorio (o créalo si no existe). Ejemplo mínimo:

version: 2
updates:
  - package-ecosystem: "pip"  # o "npm", "docker", etc.
    directory: "/"             # Ruta donde está el archivo de dependencias
    schedule:
      interval: "daily"     # Frecuencia de revisión
    open-pull-requests-limit: 5

Paso 1.2: Añadir el cooldown

Modifica el archivo para incluir la opción vulnerability-alerts y cooldown:

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 5
    # Configuración de cooldown
    vendor:
      enabled: false          # Desactiva actualizaciones automáticas de vendors
    reviewers:
      - "equipo-seguridad"
    # Cooldown en horas (default: 72)
    cooldown: 72             # Opcional: ajusta a 24, 168, etc.
    # Para paquetes con vulnerabilidades conocidas
    allow:
      - dependency-name: "requests"
        dependency-type: "direct"

Dependabot abrirá PRs solo después de que pasen 72 horas desde que detecta una nueva versión disponible. Puedes verificar esto en la pestaña «Insights» > «Dependency graph» de tu repositorio.

Paso 1.3: Validar con la CLI de GitHub

# Verifica que Dependabot esté configurado correctamente
gh api repos/{owner}/{repo}/contents/.github/dependabot.yml --jq '.content' | base64 --decode

# Lista las PRs abiertas por Dependabot (deberían estar en estado "pending" si el cooldown está activo)
gh pr list --label "dependencies" --state "open"

• Cooldown no aplica: Asegúrate de que el archivo dependabot.yml esté en la raíz del repositorio y que la sintaxis sea correcta. Usa el validador de YAML si hay dudas.
• PRs bloqueadas: Si el cooldown es muy largo (ej.: 720h), los desarrolladores pueden requerir actualizaciones urgentes. En esos casos, usa la opción allow para paquetes específicos.

2. Forzar el uso de lockfiles y tokens restringidos

Paso 2.1: Generar lockfiles para Python

# Instala pip-tools (si no lo tienes)
pip install pip-tools

# Genera un lockfile a partir de requirements.txt
pip-compile --generate-hashes requirements.txt -o requirements-lock.txt

# Usa el lockfile en tu pipeline de CI (ej.: GitHub Actions)
# Ejemplo de .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: "3.11"
      - run: pip install -r requirements-lock.txt

Las dependencias quedarán fijadas a versiones específicas, evitando que cambios inesperados (incluidos paquetes maliciosos) se instalen automáticamente.

Paso 2.2: Restringir scopes de tokens de PyPI

1. Ve a PyPI Tokens y crea un token con scopes limitados:

– Permiso: Upload releases (no Entire account).

1. Configura el token en GitHub Actions o en tu pipeline:

# .github/workflows/publish.yml
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: "3.11"
      - run: pip install twine
      - run: |
          twine upload dist/* \
            --username __token__ \
            --password ${{ secrets.PYPI_API_TOKEN }} \
            --non-interactive

• Tokens con permisos excesivos: Evita usar tokens con Entire account en PyPI. Usa tokens específicos por proyecto.
• Lockfiles desactualizados: Actualiza los lockfiles regularmente (pip-compile --upgrade).

3. Bloquear releases antiguos en PyPI

Paso 3.1: Subir una nueva versión (comprobar la restricción)

# Instala twine si no lo tienes
pip install twine

# Sube una nueva versión (ej.: 1.0.1)
python setup.py sdist bdist_wheel
twine upload dist/*

Si intentas subir archivos a una versión publicada hace más de 14 días, PyPI devolverá un error:

HTTPError: 400 Bad Request
The filename ... is not allowed for a release published more than 14 days ago.

Esta restricción es automática y no requiere configuración adicional. Si necesitas modificar un release antiguo (ej.: corregir un error crítico), contacta a PyPI Support.

4. Integrar con pipelines de CI/CD

Paso 4.1: Escanear vulnerabilidades con dependabot y Snyk

# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: "3.11"
      - name: Scan vulnerabilities with Snyk
        uses: snyk/actions/python@v1
        with:
          args: --severity-threshold=high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      - name: Check Dependabot alerts
        run: |
          gh api repos/{owner}/{repo}/dependabot/alerts > alerts.json
          # Procesa alerts.json para notificar al equipo

• Dependabot generará PRs con actualizaciones después del cooldown.
• Snyk escaneará vulnerabilidades en tiempo real.
• Los alertas de Dependabot se guardarán en alerts.json.

5. Monitorear y ajustar políticas

Paso 5.1: Revisar logs de Dependabot

# Lista todas las PRs generadas por Dependabot (incluidas las cerradas)
gh pr list --label "dependencies"

# Filtra PRs que esperan cooldown
gh pr view {PR_NUMBER} --json labels,createdAt

Verás PRs en estado «pending» si están dentro del cooldown. Ejemplo:

{
  "labels": [{"name": "dependencies"}],
  "createdAt": "2024-06-10T12:00:00Z"
}

Si createdAt es reciente, la PR aún no está lista para ser revisada.

Paso 5.2: Ajustar cooldown según criticidad

# .github/dependabot.yml
updates:
  - package-ecosystem: "pip"
    directory: "/"
    cooldown: 24  # Para producción

Consideraciones y buenas prácticas

Limitaciones conocidas

1. Cooldown no protege contra compromisos a largo plazo:

– Solución: Usa tokens con scopes restringidos y rota tokens periódicamente.

1. PyPI no bloquea releases recientes:

– Solución: Audita releases recientes con herramientas como Bandit o Safety.

1. Dependabot no cubre todos los ecosistemas:

– Solución: Para Java/Rust, usa herramientas como Renovate con retrasos similares.

Alternativas y complementos

• Actualiza lockfiles regularmente: Usa pip-compile --upgrade al menos una vez por sprint.
• Revisa PRs de Dependabot manualmente: Aunque el cooldown da tiempo, siempre valida cambios en dependencias críticas.
• Documenta excepciones: Si un paquete debe actualizarse fuera del cooldown (ej.: parche crítico), documenta el motivo en el PR.

Conclusión

GitHub y PyPI implementaron defensas basadas en tiempo para mitigar ataques a la cadena de suministro, pero estas medidas no son infalibles. Para maximizar la protección:

1. Configura el cooldown de Dependabot (72h por defecto, ajustable).
2. Usa lockfiles y tokens restringidos en PyPI.
3. Integra escaneos automáticos (Snyk, Bandit) en tus pipelines.
4. Monitorea PRs generadas por Dependabot y ajusta políticas según la criticidad del proyecto.

Al combinar estas defensas con buenas prácticas de desarrollo seguro (como revisión de código y rotación de tokens), reducirás significativamente el riesgo de incorporar paquetes maliciosos a tus proyectos. La seguridad no es un estado final, sino un proceso continuo: revisa y actualiza tus políticas periódicamente.

Fuentes

• BleepingComputer: GitHub, PyPI add time-based defenses against supply chain attacks
• ENISA: Supply Chain Security Guidelines
• Cisco Talos: Supply Chain Threat Landscape