Un análisis y luego una pull request
Scandar no escribe en la rama predeterminada. La corrección se queda en scandar/fix-… hasta que la fusiones.
Qué hace un análisis
- Inicia sesión con la GitHub App. Solo se ven los repositorios elegidos al instalar.
- Busca proyectos: un
package.jsonjunto apackage-lock.json,pnpm-lock.yamloyarn.lock. Los manifiestos anidados sin lockfile propio cuentan como miembros del workspace. - Lee el lockfile y consulta OSV.dev. Los identificadores de aviso duplicados se fusionan.
- Crea un plan de corrección. Las dependencias directas pasan a
^fixed. Las transitivas se fijan con overrides,pnpm.overridesopnpm-workspace.yaml, o lasresolutionsde Yarn. - Regenera el lockfile en un directorio temporal, con los scripts de paquetes desactivados, y abre la rama y la pull request.
Puedes marcar paquetes concretos. Las subidas mayores empiezan desmarcadas. Puede haber varias pull requests abiertas en un proyecto, y el mismo paquete no se corrige dos veces.
Pull requests de corrección más seguras
Una corrección no propone una versión publicada hace menos que tu retraso de versión. El valor predeterminado es de 5 días. Ajústalo en Ajustes → Pull requests, o cámbialo en un proyecto. 0 desactiva el retraso. El máximo es de 90 días.
Scandar lee la fecha de publicación de cada versión de npm y comprueba la versión que realmente llega al lockfile. Un rango que acabaría en una versión más reciente se fija en la versión admisible. Si aún no existe nada lo bastante antiguo, la corrección se pospone y la página indica cuándo será apta. Un aviso crítico, una vulnerabilidad explotada conocida o un paquete malicioso se proponen igualmente, con una advertencia de que la versión es reciente.
Cuando package.json ya acepta la versión corregida, solo cambia el lockfile. npm usa npm update --min-release-age y pnpm usa minimumReleaseAge. Yarn 1 no tiene equivalente, así que la versión resuelta se comprueba después y se fija si es demasiado nueva. Python, Go, Rust, PHP y Ruby aplican el retraso cuando sus registros devuelven fechas de publicación. Si no, la pull request indica que no se aplicó.
La pull request incluye una sección "Why this version": la corrección de OSV, la versión elegida, su fecha de publicación, el retraso, cualquier excepción y las versiones más nuevas descartadas. Una subida mayor muestra un riesgo de rotura bajo, medio, alto o desconocido, a partir de notas de versión públicas, motores de Node y dependencias peer. Las subidas mayores siguen desmarcadas. El auto-merge está desactivado hasta que lo actives. Solo fusiona con squash una corrección patch o minor, nunca un override transitivo, y solo con todas las comprobaciones en verde y si aún puedes hacer push.
Ecosistemas
| Ecosistema | Archivos | Corrección automática |
|---|---|---|
| npm | package-lock.json, pnpm-lock.yaml, yarn.lock | Sí, excepto Yarn Berry |
| Python | poetry.lock, uv.lock, Pipfile.lock, requirements.txt fijado con == | Indicada, no aplicada |
| Go | go.mod | Indicada, no aplicada |
| Rust | Cargo.lock | Indicada, no aplicada |
| PHP | composer.lock | Indicada, no aplicada |
| Ruby | Gemfile.lock | Indicada, no aplicada |
Permisos de la GitHub App
| Permiso | Para qué se usa |
|---|---|
| Contents | Leer archivos, crear la rama y el commit. |
| Pull requests | Abrir, fusionar con squash y cerrar. |
| Metadata | Lectura. Concedido por defecto. |
| Checks | Leer la CI antes de fusionar y escribir la comprobación de Scandar. |
| Commit statuses | Lectura, para la misma decisión de fusión. |
Callback OAuth local: http://localhost:3010/api/auth/callback/github. La app escucha en el puerto 3010. npm, pnpm y yarn deben estar en el PATH para los lockfiles que regeneran.
Límites
- 10 proyectos por repositorio, 60 miembros de workspace. El resto se descarta.
- Un árbol de Git truncado recurre al package.json raíz.
- La gravedad viene de
database_specific.severityy luego de la puntuación CVSS v3. Sin ninguna, el aviso es Desconocido. - La salud de paquetes y las licencias transitivas solo cubren npm.
- La regeneración del lockfile caduca a los 3 minutos.
- Un solo proceso de Node: SQLite y el bus de eventos en memoria no se comparten entre instancias.
Alrededor del análisis
Un aviso ignorado necesita un motivo, una nota y una duración. Sale de los totales, las correcciones, las notificaciones y las comprobaciones de pull request hasta que caduca. El historial guarda las vulnerabilidades abiertas durante 90 días. Las exportaciones son CycloneDX 1.5, SPDX 2.3, CSV y un informe imprimible. Un push a la rama predeterminada puede volver a analizar mediante el webhook de la GitHub App, y Slack o Discord pueden recibir alertas por encima de la gravedad que elijas.
CI, CLI y editores
La misma comprobación se ejecuta desde GitHub Actions, el terminal o un agente de editor. Cada cliente llama a POST /api/v1/check con una clave API. El plan necesita la función api. Nada de esto está aún en npm ni en GitHub Marketplace.
Páginas públicas de paquetes y avisos
/package/<name> (incluido @scope/name) y /cve/<id> (un id CVE o GHSA) son públicas. El nombre se comprueba antes de pedir nada. Un nombre que no coincide, o un paquete o aviso que OSV y el registro de npm no conocen, es un 404.
La página muestra la gravedad, las versiones afectadas y corregidas, y KEV o EPSS solo a partir de datos ya guardados aquí. El texto en lenguaje claro solo aparece si ya está en la caché de explicaciones. Estas páginas no llaman al modelo. El aviso de OSV sigue enlazado, porque una explicación en caché puede ser errónea.
Los informes de repositorios en /scan/… y la página imprimible /report son noindex. /dashboard, /admin y /api están prohibidos en robots.txt.