# Verifique cada release ou deploy pelo seu CI Rode uma verificação Pulse ou Deep do seu site a cada release ou deploy, pelo GitHub Actions, Vercel, GitLab, Bitbucket, CircleCI ou um script de deploy. 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. > **Careful** > > Guarde a chave no cofre de segredos do seu CI, nunca em um arquivo do seu > repositório. Quem tiver a chave pode iniciar verificações do seu site, que > usam a sua cota. ## Onde roda | De onde você publica | Quando verifica | Onde a chave vai | | ------------------------------ | -------------------------------------------------------- | ----------------------------------------------------------------- | | GitHub Actions | Quando você publica uma release, ou manualmente | Segredo do repositório `LOCKPICK_CI_KEY` | | Vercel | Depois de cada deploy de produção, ou manualmente | Segredo do repositório `LOCKPICK_CI_KEY` | | GitLab CI | Para tags, depois das suas outras etapas, ou manualmente | Variável CI/CD mascarada `LOCKPICK_CI_KEY` | | Bitbucket Pipelines | Para tags de versão, ou manualmente | Variável de repositório protegida `LOCKPICK_CI_KEY` | | CircleCI | Para tags de versão | Variável de ambiente do projeto `LOCKPICK_CI_KEY` | | Fly.io, Railway, Render, outro | No fim do seu script de deploy ou do job de CI | Variável de ambiente `LOCKPICK_CI_KEY` a partir dos seus segredos | ### 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](/pt-BR/docs/cli/ci#cli-and-release-scan-script-exit-codes). 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 --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](/pt-BR/docs/protect/prove-you-own-your-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.