Solo las vulnerabilidades que importan, corregidas con una pull request
Scandar lee tus lockfiles, se queda con los problemas que tu código puede alcanzar, los explica con claridad y abre una pull request que puedes revisar.
main ← scandar/fix-web
Pull request de corrección abierta
Actualizaciones de dependencias confirmadas en scandar/fix-web.
Comprobaciones
Las 3 comprobaciones pasaron
Fusionar en main
Lista para fusionar. Scandar la fusiona con squash y borra la rama.
npm, pnpm, Yarn, PyPI, Go, Cargo, Composer, RubyGems
GitHub, GitLab, URL pública, subida de lockfile
GitHub, PyPA, Go, RustSec, RubySec…
Cada corrección es una pull request
Cómo funciona
Del lockfile a la corrección fusionada en tres pasos.
- 01
Conecta tu código
Instala la GitHub App en los repositorios que elijas, vincula GitLab, pega una URL pública o suelta tus lockfiles.
- 02
Mira lo que importa
Cada dependencia se comprueba en OSV.dev y se ordena por gravedad, alcance desde tus imports y existencia de una corrección.
- 03
Fusiona la corrección
Scandar abre una pull request que lleva cada paquete a su versión corregida. Tu CI se ejecuta y tú fusionas.
Una pull request, no una lista de tareas
Pull request de ejemplo. Los paquetes y los identificadores son inventados.
Correcciones de dependencias generadas por Scandar a partir de avisos de OSV.dev.
| Paquete | De | A | Tipo | Corrige |
|---|---|---|---|---|
| minimatch | 3.0.4 | 3.1.2 | directo (package.json) | EXAMPLE-001 |
| brace-expansion | 1.1.11 | 1.1.12 | overrides (transitivo) | EXAMPLE-002 |
package-lock.json se volvió a resolver con npm install. No quedan avisos conocidos tras este cambio. Ejecuta tus pruebas antes de fusionar, sobre todo en cambios marcados como mayor u override.
En lenguaje claro
minimatch 3.0.4 → 3.1.2 · EXAMPLE-001
- Qué permite: Un atacante que controle el texto comparado puede hacer que el proceso tarde tanto que la petición se bloquee. Esta frase es una ilustración, no un aviso.
- Cuándo estás expuesto: Solo si la aplicación pasa entradas no fiables al paquete. El ejemplo no describe un proyecto real.
- Actualización: El ejemplo lleva una dependencia directa a una versión 3.x posterior. Lee las notas de la versión antes de fusionar.
Los rangos directos pasan a la versión corregida, los paquetes transitivos se fijan con overrides y el lockfile se regenera.
La descripción nombra cada paquete y, si ya hay una explicación en caché, dice lo que significa con claridad.
Cómo se construye una correcciónFunciones
Todo lo que te ayuda a decidir qué corregir y a corregirlo.
Alcance
Distingue los paquetes importados de los que tu código nunca alcanza, y baja el ruido.
Corregir ya, planificar, después
Una puntuación de prioridad por vulnerabilidad, no un muro de insignias rojas.
Paquetes maliciosos
Los paquetes marcados como malware en OSV aparecen primero, con la versión que hay que quitar.
Explicaciones claras
Qué significa un aviso para tu proyecto y qué cambia al actualizar, en pocas frases.
Comprobaciones de pull request
Una comprobación en cada pull request que falla si añade un aviso crítico o alto.
Alertas
Reanálisis en segundo plano, con alertas en Slack, Discord y la app cuando llega un aviso nuevo.
Varias PR de corrección
Más de una corrección por proyecto, nunca el mismo paquete dos veces, nunca un push a main.
Exportaciones
SBOM CycloneDX y SPDX, CSV, informe imprimible e insignia para el README.
Comparar
Scandar frente a Dependabot, Snyk, Socket y Aikido, según lo que publica cada uno.
Preguntas
Corrige hoy las vulnerabilidades que importan
Analiza un repositorio público sin cuenta, o inicia sesión para abrir una pull request en tu código.