Los gestores de paquetes npm, pnpm y yarn han incorporado periodos de espera de 24 horas a 7 días antes de instalar nuevas versiones, con la intención declarada de dar tiempo a la comunidad a detectar código malicioso. La medida, presentada como protección frente a la oleada de ataques en la cadena de suministro de software, es criticada en este análisis como ineficaz.
El artículo rebate la lógica subyacente de los cooldowns. Si cada usuario espera varios días antes de instalar, nadie actúa como adoptante temprano; el "canario" que debería descubrir el paquete peligroso antes de que se distribuya masivamente no existe. La premisa de que alguien revisará el código de forma altruista y alertará a tiempo carece de fundamento práctico, ya que ni siquiera hay consenso sobre quién debería asumir esa tarea ni cuál es el periodo adecuado.
El autor examina también la alternativa de delegar la detección en pipelines de CI/CD y dependencias automatizadas tipo Dependabot. Cuando el código malicioso entra en una pull request, o pasa desapercibido o explota el propio entorno de integración continua antes de que el cambio se revise. Leer el archivo package-lock.json no equivale a auditar el código, por lo que la amenaza solo se identifica cuando el daño ya es visible.
Frente a este teatro de la seguridad, la propuesta es la investigación activa por parte de cada equipo: tratar las dependencias como ejecutables desconocidos descargados de internet, aplicar análisis estático (SAST), ejecutar sandboxes y aprovechar auditorías asistidas por modelos de lenguaje, todo ello antes de fusionar las actualizaciones automáticas. La conclusión es clara: esperar no protege; solo un examen directo del código aporta garantías reales.