Verifique cada release ou deploy pelo seu CI

Esta página é para quem constrói e publica o seu site. Se não for você, envie o link para essa pessoa.

Uma verificação de release roda onde o seu site é publicado. Ela inicia uma verificação Pulse (ou Deep) do seu site, espera o resultado, informa e interrompe a publicação quando a verificação encontra algo na gravidade que você escolheu ou acima. O seu site no ar continua funcionando de qualquer forma. Cada verificação de release usa uma verificação da sua cota mensal, com os mesmos limites e as mesmas checagens de propriedade de uma verificação que você inicia no Lockpick, então conte quantas vezes publica.

Configure

1. Abra o seu site no Lockpick, escolha Configurações e depois Configurar varreduras de versão.
2. Crie uma chave de CI. Copie-a imediatamente: o Lockpick a mostra apenas uma vez.
3. Salve-a nos segredos do seu CI como LOCKPICK_CI_KEY.
4. Abra a configuração do local de onde o seu site é publicado, na página Varreduras de versão, e copie-a para o seu repositório. Ela já vem com o seu site preenchido.

Onde roda

GitHub Actions

Copie a action para .github/actions/lockpick-scan/ com os dois comandos da página Varreduras de versão e depois adicione o workflow. Publique uma release, ou rode o workflow pela aba Actions, e a verificação começa. O resumo do job mostra o resultado.

Vercel

Quando o seu projeto da Vercel está conectado a um repositório do GitHub, a Vercel avisa o GitHub sobre cada deploy. O workflow da Vercel escuta esses eventos e verifica depois de cada deploy de produção, nunca de previews. Ele também precisa que a action esteja copiada para o repositório, e a Vercel só envia esses eventos a workflows da sua branch padrão.

Cada deploy de produção usa uma verificação da sua cota, então escolha isso apenas se você publica em produção algumas vezes por mês. Caso contrário, verifique nas releases.

GitLab, Bitbucket, CircleCI e scripts de deploy

Estes rodam o mesmo script de verificação com Node 20 ou mais recente. A configuração baixa o script do Lockpick e define LOCKPICK_SITE_ID, LOCKPICK_SCAN, LOCKPICK_FAIL_ON e LOCKPICK_API_URL; a chave vem de LOCKPICK_CI_KEY. O script imprime o resumo no log do job e termina com código 1 quando a verificação falha, então o seu pipeline para ali. Este é o contrato do script independente; a CLI usa o código de saída 8 para um limite de achados. Veja a tabela de comparação.

O Fly.io não tem notificações de deploy, e deploys do Railway e do Render normalmente rodam a partir de um job de CI ou de um script, então adicione o script depois do seu comando de deploy (por exemplo fly deploy ou railway up).

Se você já usa a CLI do Lockpick, lockpick pulse <site> --fail-on high também funciona com uma chave de CI, com a chave em LOCKPICK_KEY. Ela roda apenas o Pulse.

O que uma chave de CI pode fazer

Uma chave de CI funciona para um único site. Ela pode iniciar um Pulse, iniciar uma verificação Deep se você tiver permitido, e ler essas verificações. Ela não consegue ver os seus outros sites, adicionar sites nem alterar nada no Lockpick.

Uma chave de CI expira na data que você escolhe ao criá-la (30, 90, 180 ou 365 dias), usada ou não. A página Varreduras de versão mostra quando cada chave foi usada pela última vez e quando expira. Revogue uma chave ali e todos os pipelines que a usam param imediatamente. Uma chave também deixa de funcionar se a pessoa que a criou perder o acesso ao site.

Verificações Deep a partir de uma release

Marque Deep também ao criar a chave para usar o Deep no CI, depois marque Eu aprovo verificações Deep do seu site iniciadas com esta chave. Marcar isso é a sua aprovação para verificações Deep daquele site iniciadas com aquela chave, então o CI nunca espera que você aprove cada uma. Cada verificação Deep ainda precisa de:

• Deep no seu plano, e Deep restante na sua cota;
• prova de que você é o dono do site, com o registro ainda publicado quando a verificação começar.

Depois, defina scan: deep no workflow do GitHub (ou escolha deep ao rodá-lo manualmente), ou LOCKPICK_SCAN=deep em qualquer outro lugar.

Quando o job falha

O job falha quando:

• os achados abertos estão no fail-on ou acima (high por padrão; escolha critical, medium, low ou none);
• a verificação falhou, foi cancelada ou ainda estava rodando depois do limite de tempo (a verificação continua rodando no Lockpick);
• o Lockpick não conseguiu iniciar a verificação, por exemplo quando não restam verificações neste mês, o Deep não está permitido, a propriedade não foi comprovada ou a chave expirou. O job informa o motivo e o que fazer.

O resumo mostra a nota, os achados abertos por gravidade e um link para a verificação, onde cada achado traz a sua correção. Ele nunca copia detalhes dos achados para os seus logs. Uma verificação que não conseguiu olhar tudo é avaliada pelo que viu, e o resumo informa que algumas áreas são desconhecidas.

Rodar o mesmo pipeline de novo reutiliza a sua verificação, em vez de iniciar outra. Isso funciona no GitHub Actions, no GitLab CI, no Bitbucket Pipelines e no CircleCI; um deploy da Vercel é verificado uma vez, não importa quantas vezes o seu evento chegue.

Uma verificação de release que passa não é uma certificação de segurança. A cobertura que o Lockpick não conseguiu avaliar é desconhecida, não aprovada.