GitHub y PyPI endurecen la cadena de suministro con barreras temporales en las actualizaciones y las releases

GitHub y PyPI han activado nuevas barreras basadas en el tiempo para frenar ataques a la cadena de suministro. Dependabot espera por defecto 72 horas antes de proponer actualizaciones de versión, y PyPI ya no permite añadir ficheros nuevos a una release con más de 14 días.

Las plataformas GitHub y PyPI han introducido en las últimas semanas dos cambios con una idea común: meter tiempo de por medio para reducir el daño típico de los ataques a la cadena de suministro. En Dependabot, el bot de GitHub para gestionar dependencias, la novedad llega como una espera por defecto de 72 horas antes de abrir una pull request cuando aparece una nueva versión de un paquete. En PyPI, el repositorio central del ecosistema Python, la plataforma rechaza desde julio la subida de ficheros nuevos si la release se publicó hace más de 14 días.

El ajuste de Dependabot no pretende frenar parches urgentes. La espera se aplica a las version updates, es decir, a cambios de versión que no se consideran de seguridad. Las security updates se mantienen inmediatas, para no penalizar correcciones críticas cuando el riesgo ya está identificado. El objetivo es otro: evitar que un proyecto absorba en cuestión de minutos una versión recién publicada que todavía no ha pasado el filtro natural de la comunidad, o que un atacante haya logrado colar tras comprometer una cuenta o un flujo de publicación.

Los equipos que se apoyan en automatización notarán el cambio en su cadencia. La espera se puede ajustar o desactivar con la opción cooldown en el fichero dependabot.yml, algo relevante para repositorios con ventanas de mantenimiento estrictas o con procesos de validación propios. GitHub Enterprise Server también lo incorporará, con despliegue previsto en GHES 3.23.

En PyPI, la restricción de los 14 días apunta a una táctica que ha dado dolores de cabeza: el envenenamiento de versiones antiguas y estables. Si un atacante obtiene acceso a tokens de publicación o a un CI/CD mal protegido, puede intentar subir un nuevo artefacto a una versión pasada, con el mismo número, pero con contenido distinto. Eso complica auditorías y rompe supuestos básicos en muchos entornos de construcción. El cambio se integró el 8 de julio de 2026 y se adoptó después de que el debate volviera a primera línea en marzo, tras compromisos en proyectos como LiteLLM y Telnyx ligados a una referencia mutable al usar la GitHub Action Trivy.

La propia PyPI reconoce que el ecosistema aún carece de una semántica y unas APIs estandarizadas para declarar si una release está ‘abierta’ o ‘cerrada’. La plataforma anticipa avances en esa dirección con iniciativas como Upload 2.0 API y Staged Previews, que deberían facilitar flujos más seguros sin depender solo de reglas rígidas.

Para los equipos de desarrollo, estas medidas obligan a ajustar hábitos. Conviene asumir el retraso de 72 horas en las PR automáticas de Dependabot, mantener como prioridad las actualizaciones de seguridad y fijar una política explícita con cooldown cuando la cadencia del proyecto lo exija. También ayuda reforzar lockfiles y la fijación de dependencias, que reducen cambios inesperados en el grafo de paquetes.

En el caso de PyPI, los mantenedores deben planificar la publicación completa de wheels y artefactos dentro de los 14 días posteriores a la release. Si aparece la necesidad de dar soporte a una nueva versión de Python pasado ese plazo, la vía recomendada pasa por publicar una versión nueva del paquete, no por modificar una release antigua. Y, como siempre, el cinturón de seguridad real está en otro sitio: permisos mínimos en tokens, rotación de credenciales, controles antifraude y una higiene estricta en CI/CD para evitar que un compromiso se convierta en una limpieza interminable.

No hay CVE asociado a estos cambios. No corrigen una vulnerabilidad concreta, reescriben el comportamiento de plataformas críticas para que un fallo de credenciales o un paquete malicioso tenga menos margen de maniobra y sea más difícil de colarse con rapidez.

Más información

• BleepingComputer – GitHub, PyPI add time-absed defenses against supply chain attacks : https://www.bleepingcomputer.com/news/security/github-pypi-add-time-absed-defenses-against-supply-chain-attacks/
• GitHub Changelog – Dependabot version updates introduce default package cooldown : https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/
• The GitHub Blog – The case for a cooldown: Why Dependabot now waits before issuing version updates : https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/
• PyPI Blog – Releases now reject new files after 14 days : https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/

La entrada GitHub y PyPI endurecen la cadena de suministro con barreras temporales en las actualizaciones y las releases se publicó primero en Una Al Día.