La creciente tendencia de implementar periodos de espera en las dependencias para prevenir ataques a la cadena de suministro presenta un fallo fundamental, ya que se basa en el «sufrimiento» de otros desarrolladores, según informa calpaterson.com.
A medida que los gestores de paquetes adoptan cada vez más retrasos en la adopción de nuevas versiones de software, los críticos argumentan que esta práctica genera un problema de «aprovechamiento». La estrategia se basa en la esperanza de que las actualizaciones maliciosas sean detectadas por usuarios que no utilizan periodos de espera antes de que la versión dañina sea retirada.
«Los periodos de espera de dependencias funcionan aprovechándose del dolor y el sufrimiento de los demás», informó el medio. «Lo fundamental en el plan de periodos de espera es la esperanza de que otras personas —aquellas que no fueron lo suficientemente astutas para configurar un periodo de espera— sirvan como probadores beta involuntarios y sin remuneración para los paquetes recién lanzados».
Más allá de las preocupaciones éticas, la práctica es difícil de implementar en el fragmentado ecosistema de Python, que actualmente utiliza al menos ocho gestores de paquetes diferentes. Cada gestor y proyecto requiere una configuración individual y manual para ser efectivo.
Incluso los proyectos configurados correctamente siguen siendo vulnerables. Un solo comando ejecutado fuera de una configuración de proyecto específica, como un «pip install» manual, puede eludir las protecciones establecidas y exponer a los desarrolladores a ataques.
El argumento a favor de las colas de carga centralizadas
En lugar de depender de periodos de espera descentralizados, los expertos sugieren trasladar el retraso al servidor central de dependencias mediante una «cola de carga». Esto separaría la publicación de un paquete de su distribución.
Una cola de carga permitiría que los índices centrales, como npm o PyPI, ejecuten escáneres de seguridad automatizados, muestren diferencias públicas de los cambios y alberguen periodos de prueba beta intencionados antes de que cualquier código llegue al público.
Este modelo, ya utilizado por el proyecto Debian, elimina la carga de los desarrolladores individuales y los gestores de paquetes. También reduce el poder de las credenciales de lanzamiento robadas, al garantizar que los cambios no autorizados permanezcan en una cola donde puedan ser inspeccionados antes de su distribución masiva.
