¿Cada cuánto actualizar las dependencias de su app? A diario

Nuestro Dependabot ahora busca actualizaciones todos los días laborables. Las dependencias son los paquetes escritos por otras personas sobre los que se construye su app. Cuando se publica una corrección de seguridad para uno de ellos, cada día que espera es un día más en que su app sigue con la versión antigua. Dos hábitos acortan esa espera: un calendario de actualizaciones diario y leer usted mismo la página de seguridad de su framework, en lugar de esperar una alerta.

¿Qué le pasó a nuestro propio sitio en noviembre?

El 3 de noviembre de 2026 el equipo de Next.js publicó una versión de seguridad con siete avisos, que son comunicados públicos de un problema de seguridad. Nuestro sitio, cmlteam.com, usaba Next.js 16.4.2, y los avisos indicaban que esa versión estaba afectada. Sin embargo, npm audit, el comando que comprueba sus paquetes frente a problemas conocidos, no mostró nada para Next.js, y Dependabot no generó ninguna alerta.

Nuestra ejecución semanal de Dependabot, el bot de GitHub que abre pull requests con versiones más recientes de los paquetes, había propuesto la 16.4.3 el lunes 2 de noviembre. Esa versión no contiene las correcciones de noviembre. El 5 de noviembre pasamos a la 16.4.5 y cambiamos Dependabot a diario. La corrección estuvo en producción unas 43 horas después de la publicación de los avisos, y no se rompió nada.

Detrás del calendario semanal había un viejo hábito nuestro: no actualizar los paquetes, porque queríamos saber exactamente con qué trabajábamos. Ese hábito ahora conlleva grandes riesgos.

¿Por qué no lo detectaron ni la auditoría ni la ejecución semanal?

Cada una espera algo distinto, según la vía por la que le llega una actualización.

npm audit consulta la GitHub Advisory Database, y solo los avisos que GitHub ha revisado generan alertas. El aviso de octubre llegó a la base de datos 8 días después de que Next.js lo publicara. El 5 de noviembre, uno de los avisos del 3 de noviembre todavía no estaba en ella.

El periodo de espera (cooldown) tiene una buena razón. GitHub revisó 21 incidentes de cadena de suministro muy difundidos y afirma que un cooldown habría podido filtrar la mayoría de las versiones maliciosas de vida corta, que se retiraron en cuestión de horas. Por eso lo mantenemos. Las actualizaciones de seguridad se saltan el cooldown.

Unas palabras sobre el panorama general, que afecta a los sistemas operativos y no a los paquetes de npm. OpenAI escribió el 4 de noviembre que una sola ejecución de su pipeline produjo 948 exploits funcionales de escalada de privilegios local para una distribución de Linux de uso común. Prevé que en los próximos años incluso modelos menos capaces puedan crear exploits una vez que se divulga una vulnerabilidad. Greg Kroah-Hartman dijo en julio que los modelos de IA siguen encontrando más problemas y que la gente debería actualizar durante todo el camino, en lugar de esperar a que uno cause revuelo.

¿Cómo configuro las actualizaciones diarias?

Guarde este archivo como .github/dependabot.yml en su repositorio. Comprueba npm cada día laborable, agrupa las actualizaciones de parche en un pull request y las menores en otro, e ignora las versiones mayores. El cooldown de 3 días se queda en su valor por defecto, por eso el archivo no lo menciona.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    groups:
      patch:
        patterns: ["*"]
        update-types: ["patch"]
      minor:
        patterns: ["*"]
        update-types: ["minor"]
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]

A diario significa de lunes a viernes, a una hora que Dependabot elige por usted, como explica la referencia de opciones. Después active el resto en su repositorio, siguiendo los pasos de configuración de GitHub: abra Settings, luego Advanced Security, y haga clic en Enable junto a Dependabot alerts y junto a Dependabot security updates. Tras la primera ejecución diaria, abra la pestaña Insights, luego Dependency graph y después Dependabot, para ver el estado de las actualizaciones de versión, como describe la página de actualizaciones de versión.

A diario es una elección, no el valor por defecto. Las propias guías de GitHub dicen que las apps de cambios rápidos pueden preferir el calendario semanal y que un montón de pull requests se convierte en ruido que la gente ignora. Aun así elegimos a diario, porque no queremos pasar la semana posterior a la publicación de una corrección con la versión antigua. Dos grupos reducen el ruido: cada ejecución abre como máximo un pull request de parches y uno de actualizaciones menores, en lugar de uno por paquete.

¿Qué debo leer yo mismo?

La página de seguridad de su framework y los avisos de su repositorio, porque hablan antes que cualquier alerta. Para una app de Next.js son la página de noticias de seguridad de Next.js, el feed del blog de Next.js en nextjs.org/feed.xml y los avisos de seguridad del repositorio vercel/next.js en GitHub. Next.js anunció la versión del 3 de noviembre el 27 de octubre y la actualización del 14 de octubre el 8 de octubre. La actualización crítica del 22 de septiembre se anunció y se publicó el mismo día, así que suscríbase al feed en lugar de fiarse del calendario.

El día en que el framework publique una versión de seguridad en su propia página, actualice a mano ese mismo día. La publicación de la versión del propio proveedor indica qué versión instalar: el 3 de noviembre fue la 16.4.5 para la línea 16.4 y la 15.5.29 para la línea 15.5. Así, la corrección del framework no tiene que esperar al cooldown.

No todos los creadores de apps con IA hacen apps de Next.js. El constructor de Vercel usa Next.js, mientras que Lovable usa TanStack Start o React con Vite, y Bolt admite cualquier framework de JavaScript que se ejecute en el frontend. Sea cual sea la herramienta que construyó su app, busque la página equivalente de su framework y los avisos de su repositorio.

¿Cuánto cuesta lo diario y quién lee los pull requests?

Las actualizaciones diarias cuestan pull requests, y alguien tiene que leerlos. Para las actualizaciones menores, ese alguien es una persona: lea el pull request, abra la vista previa y luego fusione. Las versiones mayores no pasan por el archivo de arriba. Cuando quiera una, lea el registro de cambios y pruébela primero en una copia de la app.

La guía de GitHub muestra un ejemplo que fusiona solo las actualizaciones de parche, y solo después de que pasen las comprobaciones de estado que usted exija. Conéctelo únicamente al grupo de parches y pruébelo con un pull request antes de fiarse de él. Necesita una ejecución de pruebas en cada cambio, y nuestro artículo sobre un pipeline mínimo de CI/CD muestra uno para una app pequeña.

¿Cuáles son los límites de las actualizaciones diarias?

Las actualizaciones diarias solo acortan el tiempo que usted ejecuta una versión antigua después de que sale una corrección. Para el resto de la seguridad de su app, los controles de seguridad por niveles enumeran las demás comprobaciones. Si una actualización funciona en su portátil pero falla en el servidor, estas 7 comprobaciones ayudan a encontrar la diferencia.

¿Qué puedo comprobar hoy?

Averigüe qué versión de su framework se ejecuta realmente. En la carpeta de su proyecto, ejecute npm ls seguido del nombre del paquete de su framework, por ejemplo next. Imprime la versión instalada. Después ejecute npm outdated, que lista cada paquete con las columnas Current, Wanted y Latest.

npm ls next
npm outdated

Mire la fila de su framework y compare Current con la versión que indica la publicación de su última versión de seguridad. Cuando lo ejecutamos en un proyecto de prueba fijado en la 16.4.2 el 5 de noviembre, npm outdated mostró Current 16.4.2, Wanted 16.4.2 y Latest 16.4.5. Con una versión exacta en package.json, Wanted se queda en esa versión, así que las que hay que leer son la columna Latest y la publicación de la versión.

Siguiente paso