# Commentaires de pull request Recevez un commentaire sur chaque pull request GitHub qui liste chaque dépendance faisant l'objet d'un avis de sécurité connu. Une fonctionnalité Deep, désactivée tant que vous ne l'activez pas. Les commentaires de pull request indiquent à votre équipe, dans la pull request elle-même, quelles versions de dépendances du lockfile font l'objet d'un avis de sécurité connu, en commençant par celles que la modification ajoute. C'est une fonctionnalité Deep, désactivée tant que vous ne l'activez pas. ## Ce qu'elle fait Quand une pull request est ouverte, reçoit de nouveaux commits ou est rouverte, Lockpick lit votre lockfile à deux endroits : la tête de la pull request, et le point où sa branche a quitté la branche de base (la merge base). Il vérifie les versions exactes des deux côtés par rapport aux avis de sécurité connus. La vérification est déterministe. Aucun code n'est exécuté, et aucune IA ne la relit. Lockpick compare les deux listes, ce qui lui permet de distinguer ce que la pull request ajoute ou modifie de ce qui était déjà là. Les problèmes arrivés sur votre branche de base après la création de la branche ne lui sont pas imputés. Il lit chaque lockfile du dépôt, ou ceux que vous avez choisis. Chaque lockfile est vérifié séparément, si bien que les modules Go et les projets JavaScript d'un monorepo sont tous couverts. Un lockfile que la pull request ne modifie pas n'est pas téléchargé à nouveau lorsque Lockpick a déjà lu exactement ce fichier. ## Lockfiles pris en charge Seules les versions exactes qu'un lockfile fixe sont lues. Rien n'est résolu, installé ni exécuté. | Stack | Lockfile | Avis issus de | | ------------------------ | --------------------------------------------------------------------------------------------------------- | ------------- | | JavaScript et TypeScript | `pnpm-lock.yaml`, `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock` (classic et Berry), `bun.lock` | npm | | Python | `poetry.lock`, `uv.lock`, `Pipfile.lock`, `pdm.lock`, `requirements.txt` (uniquement les épinglages `==`) | PyPI | | PHP | `composer.lock`, y compris les paquets de développement | Packagist | | Ruby | `Gemfile.lock`, `gems.locked` | RubyGems | | Go | `go.mod`, ainsi que la toolchain Go avec laquelle il se compile | Go | | Java et Kotlin | `gradle.lockfile`, `buildscript-gradle.lockfile`, `pom.xml` | Maven | | Rust | `Cargo.lock` | crates.io | | .NET | `packages.lock.json` | NuGet | | Dart et Flutter | `pubspec.lock` | Pub | | Elixir | `mix.lock` | Hex | | Swift | `Package.resolved` | Paquets Swift | Deux fichiers ne sont reconnus que pour vous dire comment les rendre vérifiables : * **`bun.lockb`** est le lockfile binaire de Bun. Lancez `bun install --save-text-lockfile`, committez le `bun.lock` qu'il écrit et choisissez-le. * **Un build Gradle sans lockfile** (`build.gradle` ou `build.gradle.kts`) ne peut pas être vérifié. Activez le verrouillage des dépendances (`dependencyLocking { lockAllConfigurations() }`), lancez `./gradlew dependencies --write-locks`, committez `gradle.lockfile` et choisissez-le. Pour ceux-ci, et pour tout lockfile que Lockpick n'a pas pu lire, le commentaire indique qu'il n'a pas pu vérifier, jamais que la pull request est propre. ## L'activer Il vous faut : * un site dont le dépôt GitHub est connecté, dans **Paramètres**, puis **Dépôt** ; * Deep ou Master Key sur l'espace de travail ; * le droit de gérer le site. Lier un dépôt active **Commentaires de pull request**. Il y a un interrupteur par site, dans **Paramètres**, puis **GitHub**. Désactivez-le là et il reste désactivé, même si vous liez à nouveau le même dépôt ; lier un autre dépôt le réactive. Sans Deep ni Master Key, l'interrupteur affiche « Activé, mais en pause » et rien n'est publié. Quand vous liez un dépôt, Lockpick vérifie chaque lockfile qu'il trouve, jusqu'à 20, et les recherche à nouveau à chaque lecture du dépôt, si bien qu'un projet ajouté plus tard est couvert. Les lockfiles des dossiers `testdata` et `fixtures` sont ignorés, et les langages que GitHub compte dans le dépôt décident lesquels passent en premier : pour un dépôt surtout en Go, ses fichiers `go.mod`. Vous pouvez décocher des lockfiles ou saisir un chemin comme `apps/web/pnpm-lock.yaml` à la place ; une liste que vous choisissez est conservée jusqu'à ce que vous choisissiez de nouveau tous les lockfiles. ## Ce que montre le commentaire Lockpick garde un seul commentaire par pull request et le modifie sur place. Il ne publie pas un nouveau commentaire à chaque push. Chaque pull request reçoit le commentaire, qu'elle touche ou non le lockfile. Il liste chaque version de dépendance à la tête de la pull request qui fait l'objet d'un avis connu, directe et transitive. Une ligne en haut les compte par gravité, par exemple « 81 versions vulnérables : 6 critiques · 14 élevées · 30 moyennes ». Les lignes sont triées avec **Exploitée activement** en premier, puis critique, élevée, moyenne, faible et **Non évalué**, puis par nom de paquet : * **Ajouté ou modifié par cette pull request** : chaque ligne montre le paquet, la version (et la version qu'elle a remplacée, quand la pull request l'a modifiée), la gravité, un badge **Exploitée activement** quand des attaquants exploitent déjà le problème, un lien vers l'avis et la version qui le corrige ; * **Toujours dans le dépôt après cette pull request** : les versions vulnérables qui étaient sur la branche de base et sont toujours à la tête de la pull request. Les 25 plus graves, tous lockfiles confondus, sont affichées, regroupées sous chaque lockfile, avec un lien vers le reste dans Lockpick ; * pour un dépôt Go, la version de Go avec laquelle il se compile (la ligne `toolchain` de `go.mod`, sinon la ligne `go`) compte aussi. Ses avis sur la bibliothèque standard forment une seule ligne, **Bibliothèque standard Go**, avec leur nombre et la version qui les corrige tous. Lockpick ne compare que des versions, il précise donc que l'atteignabilité n'a pas été vérifiée ; * une ligne qui indique combien d'avis la pull request corrige, et une courte liste des versions qu'elle a corrigées (paquet, l'ancienne version → la nouvelle, ou supprimé), les plus graves en premier. Les 10 premières sont affichées, avec un lien vers le reste. Quand aucune version ne fait l'objet d'un avis connu, le commentaire le dit en une ligne, en nommant le lockfile et le commit qu'il a lus. Quand un commit ultérieur change la situation, Lockpick modifie le commentaire. Aucun avertissement périmé ne reste en place. Si Lockpick ne peut pas lire le lockfile, il indique qu'il n'a pas pu vérifier. Cela arrive quand le fichier dépasse 25 Mo, est dans un autre format ou est absent. Pour un lockfile absent, il indique où il a cherché (la branche de base et la tête de la pull request), suggère le lockfile vers lequel pointent les langages du dépôt et renvoie vers le réglage. Il ne dit jamais que la pull request est propre s'il n'a pas lu le fichier. Certains avis, comme beaucoup de ceux de la base de vulnérabilités Go, n'ont pas de gravité. Lockpick utilise alors la gravité d'un CVE ou d'un avis GitHub correspondant dont il dispose ; sans aucun des deux, la ligne indique **Non évalué** et apparaît après celles qui sont évaluées. ## Autorisations La GitHub App Lockpick lit **Contents** et **Metadata**. Pour cette fonctionnalité, elle a aussi besoin de **Pull requests** en lecture et en écriture, pour lire la pull request et publier le commentaire. Lockpick utilise des jetons de courte durée limités à ce seul dépôt. Il ne fait pas de merge et ne modifie pas votre code. ### Installations existantes Si vous avez installé la GitHub App Lockpick avant cette fonctionnalité, vous devez accepter la nouvelle autorisation sur GitHub. Le propriétaire de l'installation reçoit un e-mail, et GitHub affiche une bannière sur la page des paramètres de l'installation. Tant qu'elle n'est pas acceptée, **Paramètres**, puis **Dépôt** affiche **Autorisation en attente**, avec un lien vers l'installation. Vous pouvez activer l'interrupteur avant. Il commence à fonctionner dès que vous acceptez. ## Quota et limites Les commentaires de pull request ne consomment pas de quota d'analyses. Ils ne créent pas d'analyse. Pour rester équitable, Lockpick effectue environ 20 vérifications par heure pour chaque pull request, et 600 par heure pour chaque espace de travail. Une vérification refusée par une limite est abandonnée. Le push suivant, une fois l'heure passée, réessaie, et il lit toujours le commit le plus récent. ## Au nom de qui elle agit La GitHub App Lockpick publie le commentaire, mais l'interrupteur fonctionne avec les accès du gestionnaire qui l'a activé. * Si cette personne perd l'accès au site, la fonctionnalité se désactive d'elle-même. Un autre gestionnaire peut la réactiver. * Si l'espace de travail perd Deep, la fonctionnalité se met en pause et les commentaires s'arrêtent. Elle reprend d'elle-même quand vous passez à une offre supérieure. ## La désactiver Désactivez l'interrupteur, déconnectez le dépôt ou choisissez un autre dépôt, et Lockpick s'arrête. Les commentaires déjà présents sur GitHub y restent. Lockpick ne les supprime jamais. Si vous désinstallez la GitHub App Lockpick sur GitHub, Lockpick perd tout accès au dépôt. ## Si deux sites utilisent le même dépôt Si deux sites Lockpick connectent le même dépôt, un seul d'entre eux garde le commentaire. La pull request reçoit toujours un seul commentaire, pas deux. > **Attention** > > Un commentaire liste les avis connus pour les versions exactes de votre > lockfile. Ce n'est pas une revue de sécurité complète. Une pull request sans > commentaire n'a pas été prouvée sûre.