# Comentários em pull requests Receba um comentário em cada pull request do GitHub listando cada dependência com um aviso de segurança conhecido. Um recurso do Deep, desativado até você ativá-lo. Os comentários em pull requests mostram à sua equipe, no próprio pull request, quais versões de dependências no lockfile têm um aviso de segurança conhecido, começando pelas que a mudança adiciona. Este é um recurso do Deep, e ele fica desativado até você ativá-lo. ## O que ele faz Quando um pull request é aberto, recebe novos commits ou é reaberto, o Lockpick lê o seu lockfile em dois pontos: o head do pull request e o ponto em que a branch dele saiu da branch base (a merge base). Ele verifica as versões exatas dos dois contra avisos de segurança conhecidos. A verificação é determinística. Nenhum código é executado, e nenhuma IA a revisa. O Lockpick compara as duas listas, então consegue separar o que o pull request adiciona ou altera do que já estava lá. Problemas que chegaram à sua branch base depois que a branch foi criada não contam contra ele. Ele lê todos os lockfiles do repositório, ou os que você escolheu. Cada lockfile é verificado separadamente, então os módulos Go e os projetos JavaScript de um monorepo ficam todos cobertos. Um lockfile que o pull request não altera não é baixado de novo quando o Lockpick já leu exatamente esse arquivo. ## Lockfiles compatíveis Só as versões exatas que um lockfile fixa são lidas. Nada é resolvido, instalado ou executado. | Stack | Lockfile | Avisos de | | ----------------------- | ------------------------------------------------------------------------------------------------------- | ------------- | | JavaScript e TypeScript | `pnpm-lock.yaml`, `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock` (classic e Berry), `bun.lock` | npm | | Python | `poetry.lock`, `uv.lock`, `Pipfile.lock`, `pdm.lock`, `requirements.txt` (só versões fixadas com `==`) | PyPI | | PHP | `composer.lock`, incluindo pacotes de desenvolvimento | Packagist | | Ruby | `Gemfile.lock`, `gems.locked` | RubyGems | | Go | `go.mod`, mais a toolchain Go com que ele compila | Go | | Java e Kotlin | `gradle.lockfile`, `buildscript-gradle.lockfile`, `pom.xml` | Maven | | Rust | `Cargo.lock` | crates.io | | .NET | `packages.lock.json` | NuGet | | Dart e Flutter | `pubspec.lock` | Pub | | Elixir | `mix.lock` | Hex | | Swift | `Package.resolved` | Pacotes Swift | Dois arquivos são reconhecidos só para dizer a você como torná-los verificáveis: * **`bun.lockb`** é o lockfile binário do Bun. Rode `bun install --save-text-lockfile`, faça commit do `bun.lock` que ele gera e escolha esse arquivo. * **Um build do Gradle sem lockfile** (`build.gradle` ou `build.gradle.kts`) não pode ser verificado. Ative o bloqueio de dependências (`dependencyLocking { lockAllConfigurations() }`), rode `./gradlew dependencies --write-locks`, faça commit de `gradle.lockfile` e escolha esse arquivo. Para esses, e para qualquer lockfile que o Lockpick não conseguiu ler, o comentário diz que não conseguiu verificar, nunca que o pull request está limpo. ## Ative Você precisa de: * um site com o repositório do GitHub conectado, em **Configurações** e depois **Repositório**; * Deep ou Master Key no workspace; * o direito de gerenciar o site. Vincular um repositório ativa **Comentários em pull requests**. Há um interruptor por site, em **Configurações** e depois **GitHub**. Desative-o ali e ele continua desativado, mesmo que você vincule o mesmo repositório de novo; vincular outro repositório o ativa novamente. Sem Deep ou Master Key, o interruptor mostra “Ativado, mas pausado” e nada é publicado. Quando você vincula um repositório, o Lockpick verifica cada lockfile que encontra, até 20, e os procura de novo cada vez que lê o repositório, então um projeto adicionado depois fica coberto. Lockfiles em pastas `testdata` e `fixtures` ficam de fora, e as linguagens que o GitHub conta no repositório decidem quais vêm primeiro: num repositório quase todo em Go, os arquivos `go.mod` dele. Você pode desmarcar lockfiles ou digitar um caminho como `apps/web/pnpm-lock.yaml`; uma lista que você escolhe é mantida até você escolher todos os lockfiles de novo. ## O que o comentário mostra O Lockpick mantém um comentário por pull request e o edita no lugar. Ele não publica um comentário novo a cada push. Todo pull request recebe o comentário, mexa ele ou não no lockfile. Ele lista cada versão de dependência no head do pull request que tem um aviso conhecido, direta e transitiva. Uma linha no topo as conta por gravidade, por exemplo “81 versões vulneráveis: 6 críticas · 14 altas · 30 médias”. As linhas são ordenadas com **Explorada ativamente** primeiro, depois crítica, alta, média, baixa e **Sem classificação**, e então pelo nome do pacote: * **Adicionado ou alterado por este pull request**: cada linha mostra o pacote, a versão (e a versão que ela substituiu, quando o pull request a alterou), a gravidade, um selo **Explorada ativamente** quando atacantes já estão explorando o problema, um link para o aviso e a versão que o corrige; * **Ainda no repositório depois deste pull request**: versões vulneráveis que estavam na branch base e continuam no head do pull request. As 25 mais graves entre todos os lockfiles são mostradas, agrupadas sob cada lockfile, com um link para o resto no Lockpick; * num repositório Go, a versão do Go com que ele compila (a linha `toolchain` em `go.mod`, ou então a linha `go`) também conta. Os avisos da biblioteca padrão dela formam uma linha, **Biblioteca padrão do Go**, com quantos são e a versão que corrige todos. O Lockpick só compara versões, então diz que a alcançabilidade não foi verificada; * uma linha dizendo quantos avisos o pull request corrige, e uma lista curta das versões que ele corrigiu (pacote, a versão antiga → a nova, ou removida), as mais graves primeiro. As 10 primeiras são mostradas, com um link para o resto. Quando nenhuma versão tem um aviso conhecido, o comentário diz isso em uma linha, citando o lockfile e o commit que leu. Quando um commit posterior muda o quadro, o Lockpick edita o comentário. Um alerta desatualizado não fica para trás. Se o Lockpick não consegue ler o lockfile, ele diz que não conseguiu verificar. Isso acontece quando o arquivo tem mais de 25 MB, está em outro formato ou não existe. Para um lockfile ausente, ele diz onde procurou (a branch base e o head do pull request), sugere o lockfile que as linguagens do repositório indicam e leva até a configuração. Ele nunca diz que o pull request está limpo quando não leu o arquivo. Alguns avisos, como muitos do banco de dados de vulnerabilidades do Go, não têm gravidade. O Lockpick usa então a gravidade de um CVE ou aviso do GitHub correspondente que ele tenha; sem nenhum, a linha mostra **Sem classificação** e aparece depois das classificadas. ## Permissões O GitHub App do Lockpick lê **Contents** e **Metadata**. Para este recurso, ele também precisa de **Pull requests** com acesso de leitura e escrita, para ler o pull request e publicar o comentário. O Lockpick usa tokens de curta duração limitados a esse único repositório. Ele não faz merge e não altera o seu código. ### Instalações existentes Se você instalou o GitHub App do Lockpick antes deste recurso, precisa aceitar a nova permissão no GitHub. O dono da instalação recebe um e-mail, e o GitHub mostra um banner na página de configurações da instalação. Até ela ser aceita, **Configurações** e depois **Repositório** mostra **Permissão pendente**, com um link para a instalação. Você pode ativar o interruptor antes disso. Ele começa a funcionar quando você aceita. ## Cota e limites Os comentários em pull requests não gastam cota de verificações. Eles não criam uma verificação. Para manter as coisas justas, o Lockpick roda cerca de 20 checagens por hora para cada pull request e 600 por hora para cada workspace. Uma checagem recusada por um limite é descartada. O próximo push depois da hora tenta de novo, e ele sempre lê o commit mais recente. ## Em nome de quem ele age O GitHub App do Lockpick publica o comentário, mas o interruptor funciona com o acesso do gerente que o ativou. * Se essa pessoa perder o acesso ao site, o recurso se desativa sozinho. Outro gerente pode ativá-lo de novo. * Se o workspace perder o Deep, o recurso pausa e os comentários param. Ele volta sozinho quando você faz upgrade. ## Desative Desative o interruptor, desconecte o repositório ou escolha outro repositório, e o Lockpick para. Comentários que já estão no GitHub continuam lá. O Lockpick nunca os apaga. Se você desinstalar o GitHub App do Lockpick no GitHub, o Lockpick perde todo o acesso ao repositório. ## Se dois sites usam o mesmo repositório Se dois sites do Lockpick conectarem o mesmo repositório, só um deles mantém o comentário. O pull request continua recebendo um comentário, não dois. > **Cuidado** > > Um comentário lista os avisos conhecidos para as versões exatas do seu > lockfile. Ele não é uma revisão de segurança completa. Um pull request sem > comentário não foi comprovado como seguro.