Comentarios en pull requests

Los comentarios en pull requests le dicen a tu equipo, en el propio pull request, qué versiones de dependencias del lockfile tienen un aviso de seguridad conocido, empezando por las que añade el cambio. Es una función de Deep y está desactivada hasta que la actives.

Qué hace

Cuando se abre un pull request, recibe commits nuevos o se vuelve a abrir, Lockpick lee tu lockfile en dos puntos: el head del pull request y el punto en el que su rama salió de la rama base (la merge base). Comprueba las versiones exactas de ambos contra los avisos de seguridad conocidos.

La comprobación es determinista. No se ejecuta código y ninguna IA la revisa.

Lockpick compara las dos listas, así que distingue lo que el pull request añade o cambia de lo que ya estaba. Los problemas que llegaron a tu rama base después de crear la rama no se le atribuyen.

Lee todos los lockfiles del repositorio, o los que hayas elegido. Cada lockfile se comprueba por separado, así que los módulos de Go y los proyectos de JavaScript de un monorepo quedan cubiertos. Un lockfile que el pull request no cambia no se vuelve a descargar cuando Lockpick ya leyó ese mismo archivo.

Lockfiles compatibles

Solo se leen las versiones exactas que fija un lockfile. No se resuelve, instala ni ejecuta nada.

Dos archivos se reconocen solo para decirte cómo hacerlos comprobables:

• bun.lockb es el lockfile binario de Bun. Ejecuta bun install --save-text-lockfile, haz commit del bun.lock que genera y elígelo.
• Un build de Gradle sin lockfile (build.gradle o build.gradle.kts) no se puede comprobar. Activa el bloqueo de dependencias (dependencyLocking { lockAllConfigurations() }), ejecuta ./gradlew dependencies --write-locks, haz commit de gradle.lockfile y elígelo.

Para estos, y para cualquier lockfile que Lockpick no haya podido leer, el comentario dice que no pudo comprobarlo, nunca que el pull request está limpio.

Activarlo

Necesitas:

• un sitio con su repositorio de GitHub conectado, en Ajustes y después Repositorio;
• Deep o Master Key en el espacio de trabajo;
• el permiso de gestión del sitio.

Al vincular un repositorio se activa Comentarios en pull requests. Hay un interruptor por sitio, en Ajustes y después GitHub. Si lo desactivas ahí, se queda desactivado aunque vuelvas a vincular el mismo repositorio; vincular otro repositorio lo vuelve a activar. Sin Deep ni Master Key, el interruptor muestra «Activado, pero en pausa» y no se publica nada.

Cuando vinculas un repositorio, Lockpick comprueba cada lockfile que encuentra, hasta 20, y los vuelve a buscar cada vez que lee el repositorio, así que un proyecto añadido más tarde queda cubierto. Los lockfiles de las carpetas testdata y fixtures se omiten, y los lenguajes que GitHub cuenta en el repositorio deciden cuáles van primero: en un repositorio mayormente de Go, sus archivos go.mod. Puedes desmarcar lockfiles o escribir una ruta como apps/web/pnpm-lock.yaml; una lista que eliges se mantiene hasta que vuelvas a elegir todos los lockfiles.

Qué muestra el comentario

Lockpick mantiene un comentario por pull request y lo edita en su lugar. No publica un comentario nuevo con cada push.

Todos los pull requests reciben el comentario, toquen o no el lockfile. Enumera cada versión de dependencia en el head del pull request que tiene un aviso conocido, directa y transitiva. Una línea al principio las cuenta por gravedad, por ejemplo «81 versiones vulnerables: 6 críticas · 14 altas · 30 medias». Las filas se ordenan con Explotada activamente primero, después crítica, alta, media, baja y Sin calificar, y luego por nombre de paquete:

• Añadido o cambiado por este pull request: cada fila muestra el paquete, la versión (y la versión a la que sustituyó, cuando el pull request la cambió), la gravedad, una insignia Explotada activamente cuando los atacantes ya aprovechan el problema, un enlace al aviso y la versión que lo corrige;
• Aún en el repositorio después de este pull request: versiones vulnerables que estaban en la rama base y siguen en el head del pull request. Se muestran las 25 más graves de todos los lockfiles, agrupadas bajo cada lockfile, con un enlace al resto en Lockpick;
• en un repositorio de Go, también cuenta la versión de Go con la que se compila (la línea toolchain de go.mod, o si no la línea go). Sus avisos de la biblioteca estándar forman una fila, Biblioteca estándar de Go, con cuántos hay y la versión que los corrige todos. Lockpick solo compara versiones, así que indica que no se comprobó la alcanzabilidad;
• una línea que dice cuántos avisos corrige el pull request y una lista corta de las versiones que corrigió (paquete, la versión antigua → la nueva, o eliminada), las más graves primero. Se muestran las 10 primeras, con un enlace al resto.

Cuando ninguna versión tiene un aviso conocido, el comentario lo dice en una línea, nombrando el lockfile y el commit que leyó.

Cuando un commit posterior cambia la situación, Lockpick edita el comentario. No queda ninguna advertencia obsoleta.

Si Lockpick no puede leer el lockfile, dice que no pudo comprobarlo. Esto pasa cuando el archivo pesa más de 25 MB, tiene otro formato o falta. Para un lockfile que falta, dice dónde buscó (la rama base y el head del pull request), sugiere el lockfile al que apuntan los lenguajes del repositorio y enlaza al ajuste. Nunca dice que el pull request está limpio si no leyó el archivo.

Algunos avisos, como muchos de la base de datos de vulnerabilidades de Go, no tienen gravedad. Lockpick usa entonces la gravedad de un CVE o un aviso de GitHub coincidente que tenga; si no hay ninguno, la fila dice Sin calificar y aparece después de las calificadas.

Permisos

La GitHub App de Lockpick lee Contents y Metadata. Para esta función también necesita Pull requests con acceso de lectura y escritura, para poder leer el pull request y publicar el comentario.

Lockpick usa tokens de corta duración limitados a ese único repositorio. No hace merge y no cambia tu código.

Instalaciones existentes

Si instalaste la GitHub App de Lockpick antes de esta función, tienes que aceptar el nuevo permiso en GitHub. El propietario de la instalación recibe un correo, y GitHub muestra un aviso en la página de ajustes de la instalación.

Hasta que se acepte, Ajustes y después Repositorio muestra Permiso pendiente, con un enlace a la instalación. Puedes activar el interruptor antes. Empieza a funcionar cuando aceptas.

Cupo y límites

Los comentarios en pull requests no gastan cupo de escaneos. No crean un escaneo.

Para que sea justo, Lockpick ejecuta unas 20 comprobaciones por hora por cada pull request y 600 por hora por cada espacio de trabajo. Una comprobación rechazada por un límite se descarta. El siguiente push pasada la hora lo vuelve a intentar, y siempre lee el commit más reciente.

En nombre de quién actúa

La GitHub App de Lockpick publica el comentario, pero el interruptor funciona con el acceso del gestor que lo activó.

• Si esa persona pierde el acceso al sitio, la función se desactiva sola. Otro gestor puede volver a activarla.
• Si el espacio de trabajo pierde Deep, la función se pone en pausa y los comentarios se detienen. Se reanuda sola cuando mejoras tu plan.

Desactivarlo

Desactiva el interruptor, desconecta el repositorio o elige otro repositorio, y Lockpick se detiene. Los comentarios que ya están en GitHub se quedan ahí. Lockpick nunca los borra.

Si desinstalas la GitHub App de Lockpick en GitHub, Lockpick pierde todo el acceso al repositorio.

Si dos sitios usan el mismo repositorio

Si dos sitios de Lockpick conectan el mismo repositorio, solo uno de ellos mantiene el comentario. El pull request sigue recibiendo un comentario, no dos.