Supply chain attacks: cooldowns vs upload queues

El problema que casi ningún founder ve venir: los ataques a tu cadena de dependencias

Más de 1,2 millones de paquetes maliciosos fueron bloqueados en registros de software durante 2025, según el informe State of the Software Supply Chain 2026 de Sonatype. Si tu startup usa npm, PyPI o RubyGems —y casi con certeza lo hace—, este número debería preocuparte más que cualquier vulnerabilidad en tu propia base de código.

El vector de ataque es elegante en su maldad: un actor malicioso publica una versión contaminada de un paquete popular, espera que los pipelines de CI/CD la adopten automáticamente, y listo. En horas, miles de proyectos ejecutan código que no han auditado. El tiempo medio de detección y eliminación de este tipo de paquetes oscila entre 24 y 72 horas —una ventana pequeña, pero suficiente.

La comunidad de seguridad lleva meses debatiendo cuál es la mejor respuesta. Y ese debate llegó a un punto álgido en abril de 2026 con un artículo que está dando que hablar: Cal Paterson argumenta que los dependency cooldowns —la estrategia más popular en este momento— no son la solución correcta. Son, dice, una forma de convertirte en polizón (free-rider) a costa de los demás.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Qué son los dependency cooldowns y por qué se están popularizando?

Un dependency cooldown es una configuración en tu gestor de dependencias (Dependabot, Renovate, Bundler) que introduce un retraso deliberado —típicamente entre 48 horas y 14 días— antes de adoptar automáticamente una nueva versión de un paquete publicada en un registro.

La lógica: si los paquetes maliciosos suelen detectarse y eliminarse en las primeras 72 horas, basta con esperar. Configuras una regla y te olvidas. Simon Willison, creador de Django y una de las voces más respetadas en el ecosistema Python, publicó en noviembre de 2025 que ‘todos deberíamos usar dependency cooldowns’, argumentando que son empíricamente efectivos contra la mayoría de ataques de alto impacto.

Las herramientas ya lo soportan de forma nativa:

Dependabot (GitHub): permite configurar cooldowns por tipo de versión (7 días por defecto, 14/7/3 para major/minor/patch). Las actualizaciones de seguridad críticas pueden omitir el cooldown.
Renovate: soporta cooldowns granulares con overrides inmediatos para CVEs conocidos.
Gem.coop: un servidor comunitario de RubyGems que implementa un retraso de 48 horas a nivel de registro —sin que el desarrollador tenga que cambiar nada en su proyecto, solo apuntando al endpoint correcto.

El impulso es real: desde finales de 2025 hasta principios de 2026, la adopción de cooldowns se aceleró en todos los ecosistemas principales, según datos de Next Link Labs.

El argumento de Cal Paterson: los cooldowns son una trampa de free-riding

Aquí viene el giro. Paterson acepta que los cooldowns funcionan —para quien los configura. El problema es sistémico: la estrategia delega el riesgo de detección en otros.

Si tú esperas 7 días antes de actualizar, alguien más adoptará el paquete el día 1 y será quien detecte el ataque. Tú te beneficias de su desgracia. Multiplicado por miles de equipos que adoptan la misma táctica, el resultado es una carrera para ver quién espera más —y mientras tanto, los proyectos menos sofisticados o los que no pueden permitirse el retraso absorben todo el daño.

Es el dilema del polizón clásico aplicado a la seguridad del software: una solución individualmente racional que es colectivamente ineficiente.

La alternativa: upload queues centralizadas en los registros

La propuesta de Paterson es diferente en su naturaleza: en lugar de que cada equipo configure su propio retraso, que sea el propio registro de paquetes quien introduzca una cola centralizada entre la publicación y la distribución.

El modelo ya existe y funciona: Debian lleva décadas usando upload queues. Cuando un maintainer sube un paquete, este no llega directamente a los usuarios —pasa por un proceso de revisión, escaneo automático y en muchos casos una fase de beta testing antes de considerarse estable para producción general.

Las ventajas de las upload queues frente a los cooldowns individuales son claras:

No hay free-riding: el retraso es universal. Nadie absorbe el riesgo en nombre de los demás.
Escaneos automatizados centralizados: el registro puede correr análisis de seguridad (SAST, detección de comportamiento anómalo, verificación de firmas) con más recursos y consistencia que cada equipo individual.
Revisión humana escalable: permite que revisores de la comunidad o del equipo del registro puedan marcar versiones sospechosas antes de que lleguen a producción.
Menos sorpresa en releases: los autores de paquetes saben que sus cambios no serán inmediatos, lo que incentiva releases más deliberados y mejor documentados.

El riesgo emergente: ataques a la cadena de suministro en sistemas de IA

Paterson señala una dimensión del problema que la mayoría ignora todavía: los modelos de lenguaje grandes (LLMs) están creando una nueva superficie de ataque en la cadena de dependencias.

Los archivos de markdown ejecutable —usados por herramientas de agentes como Claude, GPT-4 con plugins o sistemas de automatización basados en LLMs— pueden contener instrucciones que instalen paquetes, modifiquen configuraciones o ejecuten código. Si esos archivos provienen de repositorios no auditados, el vector de ataque es directo.

El informe de Sonatype 2026 añade otro ángulo: el 27% de las sugerencias de dependencias generadas por IA son inválidas o riesgosas, incluyendo alucinaciones de nombres de paquetes que a veces corresponden a paquetes maliciosos reales ya registrados con ese nombre (técnica conocida como package squatting).

Para equipos que usan Copilot, Cursor u otros asistentes de código para gestionar sus package.json o requirements.txt, esto no es un riesgo teórico —es un riesgo activo hoy.

¿Qué dice la data sobre el estado actual de la seguridad en dependencias?

El estudio State of DevSecOps 2026 de Datadog arroja números que deberían hacer reflexionar a cualquier CTO:

El 87% de las organizaciones tiene al menos una vulnerabilidad explotable en su stack de dependencias.
En promedio, las dependencias de un proyecto tienen 278 días de antigüedad —casi 9 meses sin actualizar.
El 40% de los servicios en producción tiene al menos una dependencia con vulnerabilidad conocida.

La paradoja es cruel: actualizar rápido te expone a paquetes maliciosos recién publicados; actualizar tarde te deja con vulnerabilidades conocidas. Los cooldowns resuelven el primer problema pero agravan el segundo si no se combinan con monitoreo activo de CVEs.

¿Qué significa esto para tu startup?

La discusión entre cooldowns y upload queues puede parecer académica, pero tiene implicaciones prácticas inmediatas para cualquier equipo que construya sobre dependencias de código abierto —es decir, prácticamente todos.

Lo que puedes hacer ahora mismo (sin esperar a que los registros cambien):

Configura cooldowns en Dependabot o Renovate hoy: es literalmente gratis y tarda menos de 30 minutos. Usa 7 días como valor por defecto para actualizaciones de patch, con override inmediato para alertas de seguridad. No es la solución perfecta, pero reduce tu exposición de forma significativa.
Activa el monitoreo de CVEs en tiempo real: herramientas como Snyk, Socket.dev o la propia integración de GitHub con Advisory Database te alertan de vulnerabilidades en tus dependencias actuales. Esto compensa el punto ciego que crean los cooldowns frente a vulnerabilidades en paquetes que ya tienes instalados.
Audita las sugerencias de IA en tu stack: si usas Copilot, Cursor o cualquier asistente que toque tus archivos de dependencias, revisa manualmente cada paquete nuevo sugerido antes de instalarlo. Un simple npm info [paquete] o verificar la actividad del repositorio en GitHub puede evitar un package squatting.
Fija versiones exactas en producción: el dependency pinning (usar versiones exactas en lugar de rangos como ^1.2.0) elimina la adopción automática de nuevas versiones y da control total sobre cuándo y cómo actualizas. Combinado con un proceso de revisión interno, es una defensa robusta.
Apoya iniciativas como gem.coop: si tu stack incluye Ruby, explorar registros alternativos con cooldowns a nivel de registro es una opción madura hoy. Para otros ecosistemas, presionar a npm, PyPI o Maven para implementar upload queues o fases de revisión es una contribución valiosa a la comunidad.

En el debate más amplio, Paterson tiene razón en el diagnóstico sistémico: los cooldowns individuales no escalan como solución colectiva. Pero mientras los grandes registros no implementen upload queues, los cooldowns son la herramienta disponible —úsalas con conciencia de sus límites.

Conclusión

La seguridad de la cadena de suministro de software dejó de ser un problema solo de grandes corporaciones. Cualquier startup que use paquetes de código abierto —y eso incluye a prácticamente todas— es un objetivo potencial. Los dependency cooldowns son una respuesta útil pero incompleta: funcionan para quien los configura, pero cargan el coste de detección sobre quienes no los tienen. La solución más robusta —upload queues centralizadas, como las que usa Debian desde hace décadas— requiere cambios en los propios registros de paquetes.

El debate está abierto, y es importante: el informe de Sonatype estima que la regulación de la cadena de suministro de software pasará de ser guía voluntaria a cumplimiento obligatorio en los próximos dos años. Los founders que entiendan esto hoy estarán mejor posicionados cuando llegue esa exigencia regulatoria.