Scandar y Dependabot
Ambos terminan en una pull request. Dependabot es el que GitHub ya ejecuta. Scandar es el que lee tu lockfile y espera a que elijas los paquetes.
Información verificada el 25 de octubre de 2026; los planes cambian, consulta su sitio. Las celdas de Dependabot se comprobaron con la documentación de GitHub sobre las actualizaciones de seguridad de Dependabot.
| Scandar | Dependabot | |
|---|---|---|
| Dónde se ejecuta | Un proceso de Node que alojas tú. Postgres se queda en esa máquina. | En GitHub. No tienes que ejecutar nada. |
| Qué lee | El lockfile que ya está en el repositorio. | Las alertas cubren el grafo de dependencias. Las actualizaciones de seguridad se aplican a dependencias nombradas en un manifiesto o lockfile. |
| Avisos | OSV.dev. Se fusionan los identificadores duplicados de GHSA y las bases de los ecosistemas. | GitHub puede enviar una alerta por una vulnerabilidad divulgada en un aviso de seguridad de GitHub. |
| La pull request | Se abre desde la app, para los paquetes que marques. Las subidas mayores empiezan desmarcadas. | Con las actualizaciones de seguridad activas, Dependabot abre una pull request hacia la versión corregida mínima. Las actualizaciones de versión son una función aparte. |
| Reescribir el lockfile | npm, pnpm y Yarn classic. Yarn Berry se analiza pero no se regenera. | En npm, Dependabot puede actualizar una dependencia explícita aunque cambie un padre o quite una subdependencia. En otros ecosistemas no actualiza una dependencia indirecta si el padre también debe cambiar. |
| Otros ecosistemas | Python (sin Pipfile.lock), Go, Rust, PHP y Ruby se pueden regenerar si la herramienta está instalada en el servidor. Si no, la corrección sigue indicada y no se abre ninguna pull request. | GitHub documenta los ecosistemas compatibles en otra página. Esta nota no repite una lista que no ha vuelto a leer. |
| Ignorar un aviso | Un motivo, una nota y una caducidad de 30 días a para siempre. Vuelve cuando termina. | Un archivo dependabot.yml puede definir horarios, ajustes de pull request y qué dependencias vigilar. |
| Fusión | Fusión con squash en la app. Se rechaza con conflictos, comprobaciones fallidas o protección de rama. | Fusionas la pull request en GitHub. |
Cuándo Dependabot es la herramienta adecuada
Dependabot ya está en el repositorio. Las alertas aparecen en la pestaña Security, y las pull requests de seguridad no necesitan un servidor, una GitHub App propia ni npm en una máquina que gestiones. Las actualizaciones de versión siguen un calendario aparte, confirmado en dependabot.yml.
Si el objetivo es “GitHub abre la pull request y yo la reviso”, Dependabot lo hace sin otra app de por medio.
Qué añade Scandar a un lockfile
Scandar solo ve los repositorios donde está instalada la GitHub App. Analiza el lockfile del árbol, consulta OSV.dev y muestra un plan de corrección antes de hacer ningún push. Los rangos directos pasan a ^fixed. Los paquetes transitivos se fijan con overrides, pnpm.overrides o las resolutions de Yarn. El lockfile se regenera en un directorio temporal con los scripts de paquetes desactivados.
Python (salvo Pipfile.lock), Go, Rust, PHP y Ruby se pueden regenerar si la herramienta de ese ecosistema está instalada en el servidor. Si no, la versión corregida sigue indicada y no se abre ninguna pull request para ese lockfile.
Lo que sigues haciendo tú
Nada llega a la rama predeterminada hasta que fusionas. La fusión con squash desde la app se rechaza si la pull request tiene conflictos, fallan las comprobaciones o la protección de rama la bloquea. Un aviso ignorado sale de los totales, las correcciones, las notificaciones y la comprobación de Scandar hasta la caducidad que fijes.
El resto del producto es local a ese proceso: un historial de 90 días, la salud de paquetes npm, exportaciones CycloneDX y SPDX, una insignia para el README, webhooks de Slack o Discord y una comprobación llamada Scandar en las pull requests de repositorios seguidos.