Comentários em pull requests

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.

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.