Por qué todos deberían usar cooldowns de dependencias

• El cooldown de dependencias (dependency cooldown) es una técnica de seguridad simple y efectiva que puede mitigar la mayoría de los ataques a la cadena de suministro de software de código abierto
• Los atacantes normalmente secuestran proyectos populares de código abierto para distribuir código malicioso, pero en la mayoría de los casos la ventana de exposición dura menos de una semana
• Si se configura un cooldown que espere cierto tiempo después de publicar una nueva versión (por ejemplo, 7 días), se puede reducir significativamente el riesgo de infección por actualizaciones automáticas
• Dependabot, Renovate y pnpm ya admiten funciones de cooldown de forma nativa, son fáciles de configurar y no tienen costo adicional
• Si el cooldown se ofrece por defecto a nivel del gestor de paquetes, puede fortalecer la seguridad de la cadena de suministro y reducir alertas innecesarias

---

Estructura y problema de los ataques a la cadena de suministro

• La mayoría de los ataques a la cadena de suministro (supply chain attack) siguen el mismo patrón
  • El atacante obtiene acceso aprovechando el robo de credenciales o una vulnerabilidad en CI/CD de un proyecto popular de código abierto
  • Sube cambios maliciosos al canal de distribución (PyPI, npm, etc.)
  • Los usuarios instalan la versión infectada debido a actualizaciones automáticas o a una falta de fijación de versiones
  • Un proveedor de seguridad lo detecta y emite una alerta, y luego el repositorio de paquetes elimina esa versión
• El intervalo entre las etapas (1) y (2) suele ser largo, pero de la (2) a la (5) todo ocurre en cuestión de horas o pocos días, por lo que el periodo de actividad del atacante es corto
• Ventana de oportunidad en casos importantes de los últimos 18 meses
  • xz-utils: unas 5 semanas
  • Ultralytics: 12 horas (etapa 1), 1 hora (etapa 2)
  • tj-actions: 3 días
  • chalk: menos de 12 horas
  • Nx: 4 horas
  • rspack: 1 hora
  • num2words: menos de 12 horas
  • Kong Ingress Controller: unos 10 días
  • web3.js: 5 horas
• De estos casos, 8 tuvieron una duración del ataque de menos de una semana, y la mayoría podrían bloquearse con un cooldown

Concepto y efecto del cooldown

• Un cooldown retrasa el uso de una nueva dependencia durante un periodo determinado después de su publicación
  • Durante ese tiempo, los proveedores de seguridad pueden detectar si es maliciosa
• Ventajas
  • Es eficaz de forma empírica y bloquea la mayoría de los ataques a gran escala
  • Es muy fácil de implementar y en la mayoría de las herramientas puede configurarse gratis
  • Ejemplo en Dependabot

    version: 2
    - package-ecosystem: github-actions
      directory: /
      schedule:
        interval: weekly
      cooldown:
        default-days: 7
    

  • Incentiva conductas positivas en los proveedores de seguridad: los empuja a enfocarse en la detección rápida en vez de en alertas excesivas o promoción

Conclusión y recomendaciones

• En 8 de 10 casos, los ataques duraron una semana o menos, y un cooldown de 7 días podría bloquear la mayoría
• Si se aplica un cooldown de 14 días, se podrían defender todos los casos salvo xz-utils
• El cooldown no es una solución perfecta, pero es una forma simple de reducir el riesgo de exposición entre 80% y 90%
• Además de Dependabot y Renovate, hace falta mejorar el soporte para que los propios gestores de paquetes ofrezcan cooldown por defecto
• La seguridad de la cadena de suministro no es solo un problema técnico, sino también de estructura de confianza social, pero el cooldown sigue siendo una mitigación realista y útil