> ## Documentation Index > Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Escaneamento de PRs > Detecte vulnerabilidades antes que elas cheguem à sua branch principal com o escaneamento automatizado de pull requests

Como Funciona

O escaneamento de PRs do ZeroPath analisa as mudanças de código nos seus pull requests e merge requests, capturando problemas de segurança antes que sejam mesclados. Os escaneamentos são executados automaticamente quando um PR é aberto ou atualizado, e os resultados aparecem diretamente no seu VCS. Apenas os arquivos alterados e o contexto ao redor são analisados — rápido e direcionado. Diffs grandes são tratados sem problemas: o agente de IA pode inspecionar diffs de arquivos específicos por meio de ferramentas em vez de exigir o diff inteiro inline, de modo que até pull requests muito grandes recebem análise completa baseada em agente. Escaneia tanto a branch de destino quanto a branch do PR, exibindo apenas as descobertas *novas* no PR. SAST, SCA, Secrets e IaC são executados simultaneamente no código alterado. Se a análise de IA atingir o tempo limite ou encontrar um erro, as descobertas das ferramentas concluídas de forma independente (como secrets e SCA) são preservadas. Cada descoberta é validada no contexto do diff para minimizar falsos positivos.

Plataformas Suportadas

| Plataforma | Gatilho | Status de Verificação | Comentários Inline | | -------------------------------------- | ---------------------------------------------- | -------------------------- | ------------------ | | **GitHub** (Cloud e Enterprise Server) | Webhook do GitHub App | GitHub Check Runs | Sim | | **GitLab** (Cloud e Self-hosted) | Webhook de Merge Request / Webhook de Pipeline | Commit Statuses / Pipeline | Sim | | **Bitbucket** (Cloud e Data Center) | Webhook de Pull Request | Build Statuses | Sim | | **Azure DevOps Services** | Service hook | Build Statuses | Sim | Todas as quatro plataformas suportam o conjunto completo de recursos de escaneamento de PRs: acionamento automático, relatório de status e comentários inline de revisão de código. Quer verificar se o seu PR corrige uma vulnerabilidade conhecida? Consulte [Verificação de Correção](/pt/scanning/fix-verification) para aprender como referenciar problemas na descrição do seu PR.

O Que É Analisado

O escaneamento de PRs é estritamente focado no diff. Ele não escaneia novamente toda a sua base de código a cada PR. Obtém o diff unificado da API do seu VCS (recorre a `git diff` se necessário). Quando a branch do PR não compartilha nenhum ancestral comum com a branch de destino (por exemplo, branches órfãs ou históricos com force push), o ZeroPath recorre automaticamente a uma comparação direta de árvores para que o escaneamento ainda possa prosseguir. Mapeia cada hunk alterado para seu arquivo e números de linha. Apenas nos arquivos alterados: * **SAST** — análise estática em ambas as branches, de destino e do PR, exibindo apenas descobertas novas. Se a sua organização configurou [regras SAST personalizadas em linguagem natural](/pt/platform/scanner-settings#custom-sources--sinks), essas regras também são aplicadas ao código alterado — as mesmas regras que rodam durante escaneamentos completos são aplicadas aos arquivos tocados pelo PR, de modo que violações são capturadas antes do merge. * **SCA** — análise de dependências quando manifests/lockfiles foram alterados (uma pré-triagem por IA pula a etapa se não for relevante) * **Secrets** — escaneia o diff em busca de credenciais hardcoded * **IaC** — verifica arquivos de infraestrutura alterados Apenas descobertas que se sobrepõem diretamente às linhas efetivamente alteradas no diff são reportadas — não há margem de proximidade, então descobertas próximas mas não relacionadas são excluídas. Arquivos novos são incluídos integralmente; arquivos excluídos são descartados. A validação por IA remove falsos positivos. Quando um problema reportado anteriormente é reavaliado e determinado como falso positivo, ele pode ser resolvido automaticamente. Os resultados são publicados no seu VCS como status de verificação e comentários inline. Quando um PR é atualizado depois que um escaneamento anterior foi pulado (por exemplo, porque o diff anterior não era relevante para segurança), o ZeroPath exclui o escaneamento pulado da linha de base da atualização. Isso garante que a comparação incremental cubra o conjunto completo de mudanças do PR em vez de apenas a atualização mais recente. Descobertas que você confirmou como verdadeiros positivos por meio de investigação nunca são resolvidas automaticamente por escaneamentos de PR. Se uma descoberta confirmada estiver ausente em uma atualização de escaneamento de PR, ela é mantida em vez de marcada como resolvida, garantindo que vulnerabilidades confirmadas permaneçam visíveis até serem explicitamente tratadas.

Status de Verificação e Feedback

Os resultados são reportados por meio de vários canais: Um status de verificação de aprovação/reprovação é publicado no seu PR. Isso se integra às regras de proteção de branch para que você possa **exigir que as verificações do ZeroPath passem** antes do merge. | Status | Significado | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Success** | Nenhum problema relevante de segurança encontrado (ou apenas abaixo do limite) | | **Failure** | Vulnerabilidades confirmadas encontradas acima do limite configurado | | **Neutral** | O escaneamento atingiu o tempo limite ou é uma entrada de merge queue (não bloqueia merges por padrão). Status de timeout são publicados de forma consistente em todas as plataformas VCS suportadas, inclusive para escaneamentos que atingem o tempo limite enquanto estão na fila. Se ocorrer um erro transitório de rede ao publicar o status final da verificação, o ZeroPath tenta novamente de forma automática para que a verificação não fique presa em estado pendente. Quando um pull request entra em uma merge queue do GitHub, o ZeroPath publica uma verificação `neutral` no commit do merge-group para que a fila possa prosseguir — o PR já foi escaneado quando foi aberto ou atualizado, então um escaneamento separado do commit de merge não é necessário. | | **Skipped** | Erro de infraestrutura (deliberadamente não é uma falha, para evitar bloquear merges). As mensagens de erro são específicas para o tipo de falha — por exemplo, distinguindo problemas de acesso ao repositório de erros transitórios de serviço — para facilitar a solução de problemas. | Para organizações que usam faturamento baseado em créditos, um escaneamento de PR pode ser pulado se a organização não tiver créditos suficientes. Quando isso ocorre, a verificação é marcada como falha com uma mensagem indicando o motivo e (se habilitado) um comentário é publicado no PR explicando por que o escaneamento não foi executado. Entre em contato com o administrador da sua organização para adicionar mais créditos. Quando você faz a triagem de um problema (por exemplo, marcando-o como falso positivo ou resolvido) em um PR que foi atualizado e reescaneado, o ZeroPath atualiza o status de verificação no commit head atual do PR, e não no escaneamento em que o problema foi originalmente detectado. Isso garante que as ações de triagem se reflitam imediatamente na verificação de proteção de branch que a sua equipe vê, mesmo depois que commits subsequentes foram enviados ao PR. ### Bloqueando Pull Requests O nome padrão da verificação do ZeroPath é `ZeroPath Security Scan`. Se a sua organização usa uma integração personalizada ou white-label, exija o nome exato da verificação que aparece em um PR de teste. #### GitHub Use as regras de proteção de branch do GitHub para exigir a verificação do ZeroPath antes do merge. Habilite o escaneamento de PRs e **Check status posting** no ZeroPath, depois abra ou atualize um pull request de teste para que o GitHub tenha visto a verificação `ZeroPath Security Scan` pelo menos uma vez. No GitHub, acesse **Settings > Branches** do seu repositório, depois adicione ou edite a regra de proteção de branch para a branch que você deseja proteger, como `main`. Selecione **Require status checks to pass before merging**, procure por `ZeroPath Security Scan` e selecione-o. Se o GitHub pedir a origem esperada, escolha o GitHub App do ZeroPath em vez de "any source". Salve a regra, envie um commit ao PR de teste e confirme que o GitHub bloqueia o merge até que a verificação do ZeroPath reporte sucesso. Veja os passos oficiais do GitHub para exigir status checks em uma regra de proteção de branch. #### GitLab Use as merge checks do GitLab para exigir que o pipeline que contém o status do ZeroPath seja bem-sucedido antes do merge. Habilite o escaneamento de PRs e **Check status posting** no ZeroPath, depois abra ou atualize um merge request de teste para que o GitLab mostre `ZeroPath Security Scan` no pipeline ou na área de status do merge request. No GitLab, acesse o projeto e selecione **Settings > Merge requests**. Em **Merge checks**, selecione **Pipelines must succeed** e salve suas alterações. O GitLab vai bloquear o merge até que o pipeline relevante, incluindo o status do ZeroPath, seja bem-sucedido. Envie um commit ao merge request de teste e confirme que o status `ZeroPath Security Scan` aparece no pipeline que o GitLab avalia para o merge request. Se você executa pipelines tanto de branch quanto de merge request, certifique-se de que o status do ZeroPath está anexado ao pipeline de merge request que o GitLab usa para o gate de merge. Veja os passos oficiais do GitLab para exigir um pipeline bem-sucedido antes do merge. Veja como o GitLab representa status de sistemas externos dentro de pipelines. #### Bitbucket Use as merge checks do Bitbucket para exigir build statuses bem-sucedidos antes do merge. Habilite o escaneamento de PRs e **Check status posting** no ZeroPath, depois abra ou atualize um pull request de teste para que o Bitbucket mostre o build status `ZeroPath Security Scan` no commit mais recente. No Bitbucket Cloud, abra as configurações do repositório e acesse **Branch restrictions** em **Workflow**. No Bitbucket Data Center, abra **Repository settings > Merge checks** ou **Repository settings > Required builds**. No Bitbucket Cloud, adicione uma restrição de branch para a branch protegida e habilite **Minimum number of successful builds for the last commit with no failed builds**. Defina o mínimo como pelo menos `1`. No Bitbucket Cloud Premium, habilite **Prevent a merge with unresolved merge checks** para que o requisito de build bem-sucedido bloqueie o merge. Sem essa configuração, o Bitbucket avisa os usuários sobre merge checks não resolvidas, mas ainda pode permitir o merge. No Bitbucket Data Center, habilite **Minimum successful builds** ou adicione uma regra de **Required builds** para a chave de build do ZeroPath se a sua instância suportar required builds. Envie um commit ao PR de teste e confirme que o Bitbucket bloqueia o merge até que o commit mais recente tenha um build status bem-sucedido do ZeroPath. Veja os passos oficiais do Bitbucket Cloud para exigir builds bem-sucedidos antes do merge. Veja a documentação oficial de merge checks e required builds do Bitbucket Data Center. #### Azure DevOps Services Use as branch policies do Azure Repos para exigir o status do ZeroPath antes de concluir um pull request. Habilite o escaneamento de PRs e **Check status posting** no ZeroPath, depois abra ou atualize um pull request de teste para que o Azure DevOps Services receba o status `ZeroPath Security Scan`. No Azure DevOps Services, abra a página **Repos > Branches** do repositório, selecione a branch de destino e abra **Branch policies**. Adicione uma status policy para o contexto de status do ZeroPath usado no seu ambiente. Configure-a como obrigatória se a branch deve bloquear merges até que o escaneamento passe. Envie um commit ao pull request de teste e confirme que o Azure DevOps bloqueia a conclusão até que o status do ZeroPath reporte sucesso. Escaneamentos de PR no Azure DevOps exigem uma conexão do Azure DevOps Services no ZeroPath. Consulte o [guia de integração do Azure DevOps](/pt/integrations/azure-devops) para a configuração de OAuth e PAT. O ZeroPath publica **comentários inline diretamente nas linhas afetadas do diff** mostrando: * O tipo e a severidade da vulnerabilidade * Uma descrição do problema e do seu impacto * Se a correção automática estiver habilitada, uma sugestão de correção que pode ser aplicada com um clique Quando uma descoberta reportada anteriormente não é mais detectada em um escaneamento subsequente do mesmo PR, o ZeroPath resolve automaticamente o comentário inline correspondente, mantendo o fio de revisão limpo e atualizado. O texto original do comentário é riscado e substituído por um banner **"Resolved"** indicando que o problema não foi detectado no escaneamento mais recente. Em plataformas que suportam esse recurso, o fio de revisão também é recolhido ou marcado como resolvido. Fios de comentários também são resolvidos automaticamente quando você marca o problema subjacente como **false positive**, **resolved** ou qualquer outro estado fechado a partir do dashboard do ZeroPath, da API ou via comando do bot. Isso funciona no GitHub, GitHub Enterprise Server, GitLab, Bitbucket e Azure DevOps Services, para que a revisão do seu PR permaneça sincronizada com as suas decisões de triagem. Cada comentário inline de descoberta inclui um rodapé de dicas rápidas mostrando como fazer a triagem da descoberta diretamente do fio de comentários — por exemplo, respondendo com `@zeropath-ai false-positive because ...` ou `@zeropath-ai accepted-risk because ...`. O rodapé também traz um link para a referência completa de [Comandos do Bot](/pt/scanning/bot-commands). Esse rodapé aparece apenas no GitHub e no GitLab. Os comentários inline são habilitados por padrão e podem ser desabilitados por repositório. Um comentário opcional de resumo listando todas as descobertas, agrupadas por severidade. Você pode controlar comentários de resumo separadamente para escaneamentos que encontram problemas e escaneamentos que voltam limpos, para que a sua equipe só receba as notificações que importam. Quando mais de 10 problemas são encontrados, o resumo mostra os 10 principais e inclui um link para visualizar todos os resultados no dashboard do ZeroPath. O cabeçalho do resumo agora exibe o número exato de problemas detectados (por exemplo, "3 possible security issues detected") para uma triagem rápida à primeira vista. Se uma descoberta tiver um ticket associado no Jira, o resumo inclui o ID do issue no Jira (com link direto para o Jira quando uma URL está disponível) e o título do ticket ao lado da descoberta. Isso dá à sua equipe visibilidade imediata do rastreamento existente sem sair do PR. Se o corpo do comentário do PR exceder os limites de tamanho do VCS, ele é automaticamente truncado em um ponto limpo e um link para os resultados completos do escaneamento no dashboard do ZeroPath é anexado, para que você sempre possa acessar as descobertas completas. Quando um PR é mesclado com vulnerabilidades abertas, o ZeroPath dispara notificações pelos seus canais configurados (Slack, webhooks etc.) alertando a equipe. A notificação inclui todas as descobertas confirmadas e não resolvidas do PR, incluindo descobertas que foram mantidas de escaneamentos anteriores do mesmo PR por meio do sistema de deduplicação. Você também recebe notificações em tempo real quando novos problemas de SCA são criados durante um escaneamento de PR. Essas notificações incluem o título da vulnerabilidade, o nome do pacote afetado e o identificador CVE para que a sua equipe possa avaliar o impacto imediatamente. Quando a correção automática está habilitada, o ZeroPath rastreia o status de cada PR de patch. Quando um PR de patch é mesclado, cada vulnerabilidade vinculada é automaticamente marcada como **patched**. Se o PR for fechado sem merge, as vulnerabilidades são marcadas como **denied**. Isso funciona corretamente mesmo em configurações de monorepo, onde um único PR de patch pode tratar várias vulnerabilidades de uma vez. Ambos os desfechos disparam notificações pelos seus canais configurados. Quando um PR de patch é mesclado, você recebe uma notificação de **vulnerability patched** incluindo o título da vulnerabilidade e o nome da branch. Quando um PR de patch é fechado sem merge, você recebe uma notificação de **patch PR denied** para que a sua equipe possa acompanhar as descobertas não resolvidas.

Comandos do Bot

Você pode controlar o ZeroPath diretamente do seu PR ou merge request mencionando o bot em um comentário — fazer triagem de descobertas, atribuir tickets, gerar patches, reescanear, fazer bypass de verificações ou fazer perguntas em linguagem natural. O bot confirma o recebimento imediatamente e atualiza o mesmo comentário no lugar quando a ação é concluída. Quando o trabalho termina, o ZeroPath também publica uma resposta de acompanhamento no mesmo fio com um resumo do resultado (ou uma mensagem de erro se o trabalho falhou), de modo que o desfecho fica visível inline sem precisar navegar até o dashboard. Alguns exemplos comuns: ```text PR comment theme={null} @ZeroPath fp issue 2 because input is sanitized upstream @ZeroPath assign issue 3 to alice@example.com @ZeroPath generate patch issue 2 @ZeroPath rescan force @ZeroPath retriage because we added input validation @ZeroPath bypass ``` O comando `rescan force` ignora o cache e executa um **escaneamento completo** em vez de uma atualização incremental, mesmo que um escaneamento para o commit atual já exista. Isso é útil quando você quer reanalisar o PR inteiro do zero em vez de construir sobre resultados anteriores. O comando `bypass` sobrepõe uma verificação de PR do ZeroPath que está falhando para que ela não bloqueie mais o merge. No GitHub, o bot orienta você a usar o botão **Bypass Check** no check run, na aba de checks do PR. No Azure DevOps, o bot executa o bypass diretamente, marcando os escaneamentos do PR como bypassed e publicando um status succeeded, liberando o gate de merge da branch policy. O comando `bypass` exige a permissão **Bypass PR Check**. Quando um comando inclui um alvo explícito (como `issue 2`), esse alvo sempre tem prioridade — mesmo que o comando seja publicado como resposta sob o fio de comentários de outra descoberta. O contexto do fio é usado como fallback apenas quando nenhum alvo está escrito no texto do comando. Por exemplo, `@ZeroPath fp issue 2` publicado como resposta sob o fio do issue 5 vai agir sobre o issue 2, não sobre o issue 5. Para a referência completa de comandos — cada palavra-chave, alias, forma de alvo, o modificador `because`, requisitos de RBAC e suporte de plataformas — consulte [Comandos do Bot](/pt/scanning/bot-commands). Quando você altera o status de um problema por meio de um comando do bot, uma notificação de **vulnerability status changed** é enviada pelos seus canais de notificação configurados. A notificação inclui o status anterior, o novo status e quem fez a mudança, para que a sua equipe tenha visibilidade total das decisões de triagem feitas a partir de comentários de PR. Os comandos do bot são suportados no **GitHub**, **GitLab** e **Azure DevOps**. O **Bitbucket** suporta escaneamento de PRs, mas ainda não comandos do bot. No Azure DevOps, você pode usar comandos como `@zeropath rescan`, `@zeropath bypass` e outros comandos de triagem diretamente dos comentários do PR. Use `@ZeroPath` como alias universal, ou substitua-o pelo nome de usuário do bot configurado no seu ambiente. Comentários que parecem conter conteúdo de prompt injection são bloqueados automaticamente. Se você receber uma mensagem de rejeição, reformule a sua pergunta como uma consulta direta sobre o problema reportado. Os comandos do bot devem vir de uma conta humana. Comentários de contas de bot (incluindo outros GitHub Apps) são ignorados automaticamente para evitar loops de feedback e garantir que cada comando seja atribuível a um usuário real. Quando o bot responde perguntas sobre descobertas de secrets, o valor bruto do secret é automaticamente mascarado na resposta. O assistente recebe e publica apenas a forma redigida, de modo que credenciais em texto claro nunca são ecoadas de volta nos comentários do seu pull request. Quando a sua organização tem o **controle de acesso habilitado**, os comandos do bot exigem que a sua conta no VCS esteja vinculada a um usuário do ZeroPath. No **GitHub**, você pode vincular a sua conta definindo o seu e-mail público do GitHub (Settings → Public profile) para corresponder ao e-mail da sua conta do ZeroPath e, em seguida, comentando em um PR. O vínculo é salvo permanentemente, então você pode voltar o e-mail para privado depois. No **GitLab**, entre em contato com o admin da sua organização para vincular a sua conta. Quando o controle de acesso está **desabilitado**, qualquer pessoa com acesso a comentários no PR pode usar os comandos do bot e o assistente de IA sem vincular uma conta. Se o PR referenciar vulnerabilidades específicas usando tags `ZP-ID` ou URLs de issues do dashboard (consulte [Verificação de Correção](/pt/scanning/fix-verification)), `retriage` executa novamente a verificação de correção contra o código mais recente do PR em vez do fluxo padrão de investigação. Isso verifica se as mudanças atuais do PR realmente resolvem os problemas referenciados. Se uma verificação de correção já estiver em andamento para o PR, o bot avisará você em vez de criar uma duplicata.

Configuração

Todas as configurações de escaneamento de PRs seguem uma cascata de herança **Organização → Tag → Repositório**. Sobrescritas no nível do repositório têm precedência. | Configuração | Padrão | O Que Controla | | ------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **PR scanning enabled** | Desativado | Interruptor geral liga/desliga do escaneamento de PRs em um repositório. O status atual é visível na visão de detalhes do repositório e na resposta da API. | | **Inline review comments** | Ativado | Publica comentários inline nas linhas afetadas do diff | | **PR summary (issues found)** | Ativado | Publica um comentário de resumo quando o escaneamento encontra problemas | | **PR summary (clean scan)** | Ativado | Publica um comentário de resumo quando o escaneamento não encontra problemas | | **Detailed vulnerability info** | Não definido | Inclui descrições de vulnerabilidades, pontuações de severidade e detalhes de remediação nos comentários de resumo do PR. Quando não definido explicitamente, aplicam-se as configurações downstream. | | **Check status posting** | Ativado | Publica status de verificação de aprovação/reprovação no VCS | | **Result inclusion threshold** | 0 | Pontuação mínima para uma descoberta aparecer no feedback do PR | | **Check failure threshold** | 75 | Pontuação de prioridade a partir da qual a verificação é marcada como falha. Deve ser maior ou igual ao result inclusion threshold. | | **Scan timeout** | 10 min | Tempo máximo antes de o escaneamento ser marcado como expirado. Quando o escaneamento fica sem tempo antes de o agente de IA conseguir concluir, o ZeroPath preserva quaisquer descobertas já produzidas por outras ferramentas (como secrets e SCA) em vez de descartar o escaneamento inteiro. | | **Auto-patching on PR scans** | Ativado | Gera sugestões de correção para descobertas no PR | | **Scan draft MRs** | Desativado | Se pull requests e merge requests em rascunho devem ser escaneados. Por padrão, rascunhos são pulados e escaneados automaticamente quando marcados como prontos para revisão. Habilite para escaneá-los imediatamente quando abertos ou atualizados. | | **Scan bot PRs** | Desativado | Se PRs abertos por automação/bots devem ser escaneados | | **Allow PR check bypass** | Ativado | Quando habilitado, um botão **Bypass Check** aparece em verificações de segurança de PR que falharam, permitindo que desenvolvedores autorizados sobreponham um resultado bloqueante. Desabilite para remover o botão inteiramente e impedir qualquer bypass. Em configurações de monorepo ou multirrepositório, onde um único PR dispara escaneamentos para mais de um repositório, o botão é mostrado apenas quando **todos** os repositórios envolvidos no PR permitem bypass — se qualquer repositório tiver o bypass desabilitado, o botão é suprimido em todas as partições daquela verificação de PR. | | **Tool toggles** | Todas ativadas | Habilita/desabilita SAST, SCA, Secrets e IaC individualmente para escaneamentos de PR |

Compatibilidade com Merge Queue do GitHub

Se você usa [merge queues do GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue), o ZeroPath trata eventos de merge-group automaticamente. Quando um pull request entra na merge queue, o GitHub cria um commit de merge temporário e solicita status checks nele. Como o PR já foi escaneado quando foi aberto ou atualizado, o ZeroPath não escaneia novamente o commit de merge. Em vez disso, ele publica uma verificação `neutral` no head SHA do merge-group, que a merge queue trata como aprovada. Isso garante que a sua merge queue não fique travada esperando por uma verificação do ZeroPath que nunca chegaria. Nenhuma configuração adicional é necessária — se o seu GitHub App tem a permissão de leitura de **Merge queues** e a assinatura do evento `merge_group`, a compatibilidade com merge queue funciona sem ajustes. GitHub Apps recém-criados pelo fluxo de configuração do ZeroPath incluem essas permissões automaticamente. Se você estiver usando um GitHub App existente que foi criado antes de o suporte a merge queue ser adicionado, pode ser necessário aceitar as permissões atualizadas nas configurações do seu GitHub App para habilitar a assinatura do evento `merge_group`.

Sincronização Automática de Repositórios (GitHub)

O ZeroPath mantém automaticamente os metadados do seu repositório sincronizados quando mudanças acontecem no GitHub. Os seguintes eventos são detectados e tratados em tempo real via webhooks: | Evento | O Que Acontece | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Repositório renomeado** | O nome do repositório é atualizado em todo o ZeroPath, incluindo todas as configurações de escaneamento vinculadas | | **Repositório transferido** | A propriedade e a URL são atualizadas para refletir a nova organização ou usuário | | **Repositório arquivado** | O repositório é marcado como arquivado no ZeroPath — nenhum novo escaneamento será disparado | | **Repositório desarquivado** | O repositório é restaurado ao status ativo e os escaneamentos são retomados normalmente | | **Repositório excluído** | O repositório e seus dados associados são removidos do ZeroPath | Nenhuma ação manual é necessária — essas mudanças se propagam automaticamente desde que o GitHub App do ZeroPath esteja instalado.

Azure DevOps

O ZeroPath também detecta eventos de renomeação e exclusão de repositórios no Azure DevOps via service hooks: | Evento | O Que Acontece | | ------------------------- | --------------------------------------------------------------- | | **Repositório renomeado** | O nome do repositório é atualizado em todo o ZeroPath | | **Repositório excluído** | O repositório e seus dados associados são removidos do ZeroPath |

Como o Escaneamento de PRs Difere de Escaneamentos Completos

| Aspecto | Escaneamento de PR | Escaneamento Completo | | --------------- | --------------------------------------------------------- | --------------------------- | | **Escopo** | Apenas arquivos alterados (focado no diff) | Repositório inteiro | | **Gatilho** | Automático na abertura/atualização do PR | Manual, agendado ou no push | | **Velocidade** | Rápido (minutos) | Minucioso (mais demorado) | | **Diferencial** | Sim — subtrai descobertas existentes da branch de destino | Não | | **Resultados** | Verificação no VCS + comentários inline + dashboard | Apenas dashboard | | **Gate de SCA** | A IA decide se arquivos de dependências mudaram | Sempre executa | | **Timeout** | 10 minutos (configurável) | Timeouts mais longos |

Guia de Adoção

Ative-o nas configurações de scanner do seu repositório. Garanta que o seu GitHub App, app do GitHub Enterprise Server, instalação do GitLab, integração do Bitbucket ou conexão do Azure DevOps esteja configurado. O ZeroPath vai escaneá-lo automaticamente e publicar os resultados. Adicione a verificação do ZeroPath como status check obrigatório nas regras de proteção de branch do seu VCS. Ajuste o check failure threshold e o result inclusion threshold para corresponder à tolerância da sua equipe. Trate as descobertas diretamente no seu fluxo de revisão de código.