Saltar para o conteúdo principal

​
Visão Geral

As configurações do scanner controlam como o ZeroPath escaneia seus repositórios — quais ferramentas são executadas, como os achados são filtrados, como os PRs são tratados e quando os scans agendados são executados. As configurações seguem um modelo de herança em cascata.

​
Herança de Configurações

As configurações são aplicadas em uma cascata de três níveis:
  • Configurações da organização se aplicam a todos os repositórios como linha de base padrão.
  • Configurações de tag substituem os padrões da organização para os repositórios com aquela tag. As tags têm uma ordem de prioridade — tags de prioridade mais alta substituem as de prioridade mais baixa.
  • Configurações de repositório substituem tudo para um repositório específico.
Apenas valores definidos explicitamente substituem — campos não definidos passam para o próximo nível.

​
Alternância de Módulos de Scan

Cada módulo de scan pode ser habilitado ou desabilitado de forma independente para scans completos e scans de PR: As configurações de alternância exibem seu estado efetivo atual, levando em conta a cascata de herança. Se uma alternância não foi definida explicitamente no nível do repositório, ela mostra se o valor é herdado do nível da organização ou da tag e qual é o valor efetivo atual.

​
Configurações Principais

​
Configurações de Scan Completo

​
Configurações de Scan de PR

​
Verificação de Correções

Você pode referenciar issues existentes do ZeroPath diretamente na descrição do seu PR para verificar se as suas alterações as resolvem. Adicione ZP-ID: <issue-id> (um ou mais, separados por vírgula) ou cole a URL de uma issue do dashboard do ZeroPath no corpo do PR. Quando o scan do PR é concluído, o ZeroPath informa se cada issue referenciada ainda foi detectada ou foi corrigida pelo PR. Após o merge, correções verificadas são automaticamente marcadas como resolvidas. Nenhuma configuração adicional é necessária — a verificação de correções é ativada automaticamente quando há referências a issues. Consulte a aba PR Scans na Visão Geral de SAST para detalhes sobre o formato de referência.

​
Modelos de PR

Personalize a aparência dos PRs de correção gerados automaticamente: Os modelos suportam os seguintes placeholders: Os placeholders do Jira são preenchidos automaticamente quando o achado tem um ticket do Jira vinculado. Se nenhum ticket do Jira estiver vinculado, o placeholder é omitido.

​
Agendamento de Scans

Configure scans recorrentes usando expressões cron:
  1. Navegue até as configurações do scanner do seu repositório.
  2. Em Scan Schedule, clique em Add Scan Schedule para criar um novo agendamento.
  3. Selecione uma branch de destino no menu suspenso (o padrão é a branch padrão do repositório).
  4. Insira uma expressão cron (por exemplo, 0 2 * * 1 para toda segunda-feira às 2h) ou use uma predefinição (Weekly, Monthly, Quarterly).
Você pode criar vários agendamentos para um repositório, para escanear branches diferentes em cadências diferentes. Cada agendamento é exibido com sua branch de destino e o tempo estimado até a próxima execução. Ao editar um agendamento existente, apenas a expressão cron pode ser alterada — a branch de destino é fixada no momento da criação. Você também pode excluir agendamentos individuais diretamente na lista de agendamentos. O agendador só cria trabalho novo quando o commit no topo da branch mudou desde o último scan, evitando processamento redundante. Para agendamentos que cobrem vários repositórios (como agendamentos por organização ou baseados em tag), cada repositório é avaliado de forma independente — um scan em andamento em um repositório não atrasa nem bloqueia os scans agendados dos demais repositórios do mesmo agendamento. Se um scan agendado for bloqueado por falta de créditos e sua organização tiver a recarga automática de créditos configurada, o ZeroPath tenta automaticamente comprar créditos adicionais antes de bloquear o scan. Se a recarga for bem-sucedida, o scan prossegue normalmente. Se falhar, o scan é bloqueado e a mensagem de erro inclui detalhes tanto sobre a falta de créditos quanto sobre a falha da recarga.

​
Agendamento em Massa

Você pode aplicar um agendamento de scan a vários repositórios de uma vez a partir da lista de repositórios. Selecione os repositórios que deseja agendar e configure uma expressão cron compartilhada. Agendamentos em massa sempre são executados na branch padrão de cada repositório.
Se qualquer repositório selecionado tiver vários agendamentos de scan configurados, a edição em massa é desabilitada. Você verá um aviso identificando quais repositórios precisam ser gerenciados individualmente.
Scans de SCA configurados via agendamento são executados de forma independente dos scans completos. Seus resultados aparecem na página Supply Chain, mas não na página Issues. Se você notar mais achados de SCA na página Supply Chain do que em Issues, isso é esperado — scans de SCA agendados podem detectar vulnerabilidades entre scans completos.

​
Corte de Histórico

Você pode configurar uma data de corte de histórico para um repositório, de modo a ignorar todo o histórico de scans e vulnerabilidades anterior a essa data. Isso é útil ao integrar um repositório existente quando você quer uma linha de base limpa, sem herdar achados legados de scans mais antigos. Quando um corte de histórico está ativo, os scans completos consideram apenas resultados de scans anteriores criados após a data de corte. O corte também é aplicado durante a deduplicação e a análise de dependências, para que novos achados não sejam incorretamente associados a issues anteriores ao corte.

​
Filtragem por Branch

Ao visualizar issues ou o histórico de scans de um repositório, você pode filtrar por branch usando o menu suspenso de branches na barra de ferramentas. Isso permite focar nos achados de uma branch específica sem alternar manualmente entre resultados de scans.
  • Na aba Issues, clicar no indicador de branch abre um menu suspenso listando todas as branches que já foram escaneadas. Selecionar uma branch filtra tanto o seletor de scans quanto as issues exibidas para apenas aquelas de scans naquela branch.
  • Na aba Scans, um filtro de branch aparece na barra de ferramentas quando várias branches foram escaneadas. Você pode selecionar uma branch específica ou visualizar todas as branches de uma vez. Um filtro de severidade também está disponível, permitindo restringir a lista de scans apenas àqueles que contêm achados em níveis específicos de severidade (Critical, High, Medium, Low ou Info).
Os seletores de branch em toda a plataforma suportam busca no servidor e paginação, de modo que repositórios com grande número de branches carregam rapidamente e podem ser pesquisados sem precisar carregar toda a lista de branches antecipadamente.

​
Filtragem por Aplicação

Você pode filtrar por aplicação em dois lugares:
  • Página Issues — use o filtro de aplicação na barra de ferramentas de issues para restringir a lista de issues aos achados associados a aplicações específicas. Isso é particularmente útil para monorepos e repositórios em que o ZeroPath descobre várias aplicações distintas (serviços, módulos ou pontos de entrada) durante o scan.
  • Dashboard — o dashboard principal inclui um gráfico Issues by Application e um filtro de aplicação nos controles de filtro. Selecione uma ou mais aplicações para restringir todos os widgets do dashboard (distribuição por severidade, principais issues, issues por repositório etc.) apenas às aplicações selecionadas. Sua seleção de filtro de aplicação é persistida por organização e restaurada quando você retorna ao dashboard.
Os filtros de aplicação são limitados à organização atual. Trocar de organização redefine automaticamente o filtro de aplicação.

​
Lista de Repositórios

A lista de repositórios suporta ordenação por nome, quantidade de scans, data do último scan e quantidade de issues. Clicar na contagem de issues de um repositório navega diretamente para a aba de issues daquele repositório, para acesso rápido.

​
Explorador de Scans

Você pode abrir rapidamente o explorador de scans do scan completo mais recente de um repositório diretamente da lista de repositórios. Cada linha de repositório inclui um link Explore que navega para a visualização do explorador de scans, oferecendo um detalhamento dos resultados do scan mais recente sem precisar navegar pelo histórico de scans.

​
Otimizações de Scan

O ZeroPath aplica várias otimizações para reduzir o tempo de scan sem sacrificar a cobertura:
  • Reaproveitamento para commits idênticos: quando um scan completo tem como alvo o mesmo commit e as mesmas configurações do scanner que afetam a descoberta do scan bem-sucedido anterior, todos os achados são transportados instantaneamente, sem reexecutar o pipeline de scan. Você verá esses scans serem concluídos em segundos. Alternar configurações de pós-processamento — como Automatic Runtime Validation ou Codex-enhanced differential scanning — não invalida o reaproveitamento, porque essas configurações apenas filtram ou anotam achados que a descoberta já produziu. Apenas mudanças em configurações que afetam quais vulnerabilidades o scan descobre (módulos habilitados, regras personalizadas, filtro de confiança, modelos etc.) exigem um novo scan. O explorador de scans resolve automaticamente scans reaproveitados exibindo os resultados da análise completa mais recente do mesmo commit, então você sempre vê dados de scan completos, mesmo para scans reaproveitados.
  • Invalidação de configurações por categoria: as mudanças de configuração são rastreadas por categoria de scan. Quando apenas configurações seguras para transição mudam (como a configuração da análise de dependências, a camada de modelo/modo de desempenho ou a habilitação de módulos de inventário), o ZeroPath reexecuta do zero a categoria afetada enquanto reaproveita os resultados das outras categorias, como SAST, evitando um re-scan completo. Por exemplo, alterar uma configuração relacionada a SCA ou habilitar um módulo de inventário em um commit inalterado aciona uma nova análise de dependências e de inventário, mas preserva os achados de código anteriores, em vez de reexecutar todo o pipeline de scan. Da mesma forma, alterar a camada de modelo ou alternar o modo de alto desempenho é aplicado de forma preguiçosa — a nova configuração entra em vigor no próximo scan natural de cada repositório (mudança de código ou re-scan agendado), em vez de forçar um re-scan completo imediato em todos os repositórios. Os achados anteriores são reaproveitados nesse meio-tempo, de modo que nenhum achado é perdido durante a transição.
  • Scan diferencial: quando habilitado nas configurações do scanner, pequenas alterações de código desde o último scan são avaliadas com um re-scan diferencial alimentado por IA, em vez de reexecutar o pipeline completo. Se o diff for grande demais ou o scan for o primeiro daquela branch, o pipeline completo é executado normalmente. Manifestos de dependências e lockfiles são avaliados separadamente das alterações de código — quando o re-scan diferencial cuida do lado do código, uma nova análise de dependências ainda é executada se os arquivos de dependências tiverem mudado, de modo que novos CVEs são capturados sem esperar o próximo scan completo agendado.
  • Deduplicação de patches em monorepos: em monorepos, quando várias vulnerabilidades de SCA afetam o mesmo pacote no mesmo arquivo de manifesto, o ZeroPath gera um único patch de correção e o vincula a todos os achados relacionados, evitando PRs de correção duplicados.
  • Deduplicação de scans completos por branch: os achados de scans completos são deduplicados por branch, de modo que cada branch mantém um ciclo de vida de issues independente. Resolver uma issue em uma branch não afeta a mesma issue em outra branch.
  • Cancelamento automático de scans de PR: quando você envia um novo commit para um pull request ou merge request, o ZeroPath cancela automaticamente quaisquer scans de PR em andamento para commits mais antigos do mesmo PR. Isso evita trabalho desperdiçado em código desatualizado e garante que apenas o commit mais recente seja escaneado. Isso se aplica a todas as plataformas de controle de versão suportadas (GitHub, GitHub Enterprise Server, GitLab, Bitbucket e Azure DevOps Services).
  • Cancelamento responsivo de scans completos: quando você cancela um scan completo, o cancelamento entra em vigor durante fases de longa duração, como a construção do modelo do repositório e a construção do grafo de chamadas, e não apenas entre fases. Isso significa que solicitações de cancelamento são atendidas em segundos, em vez de esperar a conclusão de uma fase inteira.
  • Escopo da deduplicação de scans de PR: os achados de scans de PR são deduplicados apenas contra linhas de base de scans completos e re-scans do mesmo PR — nunca contra achados de outros pull requests. Isso evita contaminação entre branches, em que um achado de um PR poderia suprimir incorretamente ou herdar estado de um PR não relacionado.
  • Atualização da atribuição de contribuidores: quando um achado existente é detectado novamente em um scan completo subsequente, o ZeroPath atualiza a atribuição do git blame e os dados de localização de código daquele achado. Isso mantém as informações de contribuidores e os números de linha precisos conforme seu código evolui, sem criar entradas duplicadas.
  • Consistência de avisos de SCA entre tipos de scan: avisos relacionados a SCA — incluindo notificações de lockfile ausente, falhas de resolução de dependências, dependências transitivas não resolvidas e anomalias de resultado zero — são exibidos tanto após scans completos quanto após scans de SCA independentes. Scans completos também detectam anomalias de resultado zero, em que um arquivo de manifesto foi descoberto mas a resolução de dependências não produziu resultados, o que pode indicar um arquivo de dependências mal configurado ou vazio. Quaisquer avisos de SCA detectados durante um scan são reconciliados e ficam visíveis no dashboard imediatamente, e avisos que não se aplicam mais são automaticamente limpos no próximo scan bem-sucedido.
  • Preservação de achados em falhas de resolução: quando a resolução de dependências falha para um arquivo de manifesto durante um scan, o ZeroPath reaproveita os achados de SCA existentes daquele manifesto em vez de marcá-los como resolvidos. Isso evita que vulnerabilidades de dependências confirmadas ou abertas sejam incorretamente resolvidas de forma automática devido a um erro transitório de resolução. A mesma proteção se aplica quando um caminho de scan não executa o pipeline de análise de dependências — achados de SCA só são resolvidos quando o analisador de SCA confirma ativamente que eles não estão mais presentes. Da mesma forma, quando uma investigação profunda de SAST é pulada para um arquivo (por exemplo, durante um scan abreviado ou leve), os achados de SAST existentes naquele arquivo são reaproveitados em vez de resolvidos automaticamente. Arquivos cuja análise não pôde ser concluída em qualquer modo de scan — incluindo scans abreviados e leves — são rastreados e protegidos contra a resolução automática, mesmo quando o pipeline completo de investigação não foi executado. Os achados só são resolvidos quando o pipeline de investigação confirma ativamente que eles não estão mais presentes, de modo que modos de scan que pulam a análise profunda não podem descartar silenciosamente vulnerabilidades reais. Achados confirmados como verdadeiros positivos que são reaproveitados também têm qualquer estado obsoleto de resolução automática limpo, garantindo que apareçam com o status correto no dashboard em vez de serem exibidos incorretamente como resolvidos.
  • Tratamento de arquivos minificados: quando trechos de código de arquivos com linhas muito longas (como JavaScript minificado ou assets empacotados) são enviados para análise por IA, o ZeroPath trunca automaticamente linhas individuais para evitar que elas consumam a janela de contexto da análise. Intervalos de código grandes também são limitados a um total de caracteres, de modo que solicitar um intervalo amplo de linhas de um arquivo denso não estoura o orçamento de análise. O código completo e não modificado é preservado no banco de dados e na interface — apenas a cópia enviada à IA é reduzida.
  • Correção de caminhos de IaC: quando um scanner de IaC relata um achado com um caminho de arquivo que não corresponde ao layout do repositório (por exemplo, um caminho de template de chart do Helm relativo ao nome do chart em vez da raiz do repositório), o ZeroPath busca automaticamente o arquivo correto e ajusta o caminho. Se o caminho não puder ser resolvido de forma única, o achado é descartado em vez de ser exibido com uma localização incorreta.
  • Priorização de scans manuais: scans disparados por usuários são priorizados sobre scans agendados na fila de processamento. Um grande lote de scans agendados não atrasará suas solicitações interativas de scan.

​
Orientações de Remediação

Quando o ZeroPath determina que uma vulnerabilidade não pode ser corrigida automaticamente com um patch, ele fornece instruções de remediação junto com o motivo pelo qual o patch não pôde ser gerado. Você encontra essas instruções na página de detalhes da vulnerabilidade para orientar a resolução manual. Para achados de imagens de contêiner, o ZeroPath pode gerar patches de correção editando o Dockerfile do repositório. Quando um pacote vulnerável vem da imagem base, o patch atualiza a tag FROM para uma versão estável mais recente da mesma distribuição que inclui o pacote corrigido. Quando o pacote foi instalado por uma etapa de build da aplicação (uma instrução RUN), o patch atualiza ou fixa a versão do pacote naquela etapa. Se nenhum Dockerfile puder ser localizado ou nenhuma edição segura for possível, instruções de remediação são fornecidas no lugar do patch.

​
Indexação Inicial do Repositório

Quando você adiciona um novo repositório e dispara seu primeiro scan, o status do scan é exibido como Indexing em vez do status usual de progresso. Isso indica que o ZeroPath está realizando a análise inicial do repositório, que normalmente demora mais que os scans subsequentes porque todo o código precisa ser processado do zero. Depois que o primeiro scan é concluído com sucesso, os scans futuros exibem os status de progresso padrão.

​
Relato de Erros de Scan

Quando um scan falha, o ZeroPath exibe a mensagem de erro real descrevendo o que deu errado, em vez de um aviso genérico de falha. Você pode ver essas mensagens no status do scan para entender se o problema é transitório (por exemplo, um timeout ou problema de conectividade) ou exige uma ação sua (por exemplo, configuração inválida do repositório). Mensagens de erro de todas as etapas do scan — incluindo os sub-scans de SAST e SCA — são exibidas diretamente, dando visibilidade completa sobre o que falhou sem precisar contatar o suporte.

​
Resiliência em Novas Tentativas de Scan

Se um scan for interrompido e precisar reiniciar (por exemplo, devido a um problema transitório de infraestrutura), o ZeroPath se recupera automaticamente da tentativa anterior sem criar achados duplicados. A plataforma detecta quais resultados já haviam sido persistidos antes da interrupção e retoma de onde parou, então você não vê achados duplicados nem dados faltando após uma nova tentativa de scan. Quando um lote de resultados encontra um conflito com dados persistidos anteriormente, a plataforma repete cada operação individualmente, para que os resultados não duplicados ainda sejam gravados com sucesso. Erros transitórios de banco de dados durante a persistência de resultados são repetidos automaticamente com backoff exponencial antes de gerar uma falha, reduzindo ainda mais a chance de erros de scan causados por problemas breves de conectividade. Essa recuperação funciona de forma confiável mesmo para repositórios grandes com milhares de achados. Se um worker de scan ficar indisponível (por exemplo, devido a escalonamento ou a uma falha transitória), quaisquer scans atribuídos a ele são automaticamente reatribuídos a um worker saudável. Essa reatribuição é executada continuamente, então os scans não ficam presos esperando um worker que não está mais disponível. Scans ativos que não podem ser reatribuídos com segurança são marcados como com erro para que possam ser repetidos. Scans completos interrompidos por reinicializações de workers podem se recuperar automaticamente até três vezes, reexecutando o pipeline de scan desde o início a cada tentativa. Se um scan completo esgotar seu orçamento de recuperação, ele é marcado como com erro para que você possa dispará-lo novamente de forma manual. Além disso, se o pool de scan for reduzido e um scan completo tiver sido atribuído a um worker que não existe mais, a plataforma detecta automaticamente o scan órfão após um período de carência e o marca como com erro com uma mensagem clara, em vez de deixá-lo preso indefinidamente. Scans completos obsoletos que permanecem inacabados além do limite configurado também são limpos automaticamente, de forma consistente com o comportamento existente para scans de PR.

​
Preservação do Status das Issues

Quando um scan atualiza os status das issues, o ZeroPath preserva os estados manuais de fluxo de trabalho que você definiu. Se você mover uma issue para Reviewing ou Backlog, os scans subsequentes não a redefinirão para Pending Review. Status controlados por ações automatizadas — como arquivada, silenciada, falso positivo ou em correção — continuam sendo atualizados normalmente com base nos resultados do scan mais recente. Achados com patches gerados automaticamente pendentes refletem corretamente o status Patching, em vez de serem rebaixados para Informational, e scans com reaproveitamento recalculam os status das issues a partir do estado final do achado, para evitar que valores de status obsoletos persistam entre scans. Quando você resolve uma issue, qualquer estado de silenciamento naquela issue é automaticamente limpo. Se precisar reverter uma decisão de risco aceito (arquivamento), você deve desarquivar a issue antes de resolvê-la — apenas resolver não desfaz um arquivamento.

​
Exigência de Contexto para Falsos Positivos

As organizações podem exigir que os usuários forneçam um motivo ao marcar issues como falsos positivos. Quando essa exigência está habilitada, o diálogo de falso positivo verifica a política da sua equipe antecipadamente e indica claramente que o contexto é obrigatório antes de você poder enviar. Se você tentar marcar uma issue como falso positivo sem fornecer um motivo não vazio, o envio é bloqueado. Isso garante que as decisões de triagem sejam documentadas e auditáveis, facilitando que outros membros da equipe entendam por que um achado foi descartado.

​
Aba de Feedback de Triagem

Cada repositório inclui uma aba Feedback que exibe cada justificativa humana de triagem registrada para os achados do repositório. Isso oferece uma visão centralizada de todas as decisões de triagem — não apenas falsos positivos, mas todas as disposições, incluindo não explorável, verdadeiro positivo, risco aceito, mudanças de severidade e outras. Você pode filtrar a lista de feedback por tipo de disposição usando os chips de filtro no topo da aba. Por padrão, todos os tipos de disposição são exibidos, e você pode restringir a visualização alternando filtros individuais. Cada entrada de feedback exibe a disposição, a justificativa fornecida por quem fez a triagem, o achado associado e quando ela foi registrada. Você pode clicar para acessar o achado vinculado e ver todos os detalhes. Você também pode editar qualquer entrada de feedback inline para reformular a justificativa ou mudar a disposição. Salvar uma edição registra uma nova entrada de triagem à prova de auditoria, preservando o histórico completo das decisões de triagem. Uma justificativa é obrigatória ao salvar edições.

​
Controles de Escopo de Scan

​
Partições de Diretório (Suporte a Monorepos)

Para monorepos, configure partições de diretório para escanear subdiretórios específicos como aplicações independentes:
  • Cada partição é analisada separadamente, com sua própria descoberta de aplicações.
  • Scans de PR são roteados para a partição correta com base nos arquivos alterados.
  • Achados fora do escopo de diretório de uma partição são filtrados antes da validação por IA, para que achados fora de escopo não consumam o orçamento de validação. Fluxos de dados entre partições são preservados quando o ponto de entrada do fluxo se origina dentro do escopo da partição.
Ao excluir uma configuração de monorepo, você pode escolher manter uma partição como repositório normal ou excluir todas as partições de uma vez. Se restar apenas uma partição, a plataforma se oferece para convertê-la de volta em um repositório normal automaticamente. A exclusão de monorepo é realizada como uma única operação atômica, de modo que falhas parciais (como uma interrupção de rede no meio da exclusão) não podem deixar seu repositório em estado inconsistente.

​
Sources e Sinks Personalizados

Você pode definir declarações personalizadas de sources e sinks para ensinar ao ZeroPath os pontos de entrada relevantes para segurança e as operações sensíveis específicas do seu código. Gerencie-as na página dedicada Custom Sources & Sinks, organizada em três abas:
  • Custom Sources — declarações de pontos de entrada de dados relevantes para segurança no seu código.
  • Custom Sinks — declarações de operações sensíveis que dados contaminados não devem alcançar.
  • Library — navegue e habilite Source Packs e Sink Packs pré-construídos publicados pelo ZeroPath, cobrindo frameworks e bibliotecas comuns.
Cada declaração inclui um nome, uma descrição em linguagem natural que o mecanismo de scan usa para identificar instâncias no código, um padrão glob opcional para o escopo de arquivos e um escopo de repositórios (todos os repositórios ou repositórios específicos). Você também pode atribuir tags para organização. Quando você cria ou atualiza uma declaração personalizada de source ou sink, o ZeroPath valida automaticamente a descrição usando IA, para garantir que ela descreva um ponto de entrada de dados legitimamente relevante para segurança (para sources) ou uma operação sensível (para sinks). Se a descrição for ambígua, sem sentido ou não corresponder ao tipo declarado, a plataforma rejeita a declaração com um motivo específico. Essa validação é executada tanto na criação quanto na atualização, sempre que o campo de descrição muda. Excluir um source ou sink personalizado exige confirmação. Os achados existentes da declaração excluída mantêm seus dados, mas perdem o vínculo com a declaração.

​
Whitelist / Blacklist de Caminhos

Use conjuntos de localização de scan para controlar quais arquivos são incluídos ou excluídos durante os scans completos. Cada conjunto de localização inclui um nome, uma descrição opcional e duas listas de padrões:
  • Padrões de whitelist — escaneia apenas arquivos que correspondem a esses padrões.
  • Padrões de blacklist — exclui arquivos que correspondem a esses padrões.
Você pode escolher se um conjunto de localização se aplica a todos os repositórios ou a repositórios específicos. Os padrões podem ser inseridos um por vez ou em massa usando a alternância Bulk Edit. Excluir um conjunto de localização exige confirmação.

​
Definindo as Configurações

​
Resolução de Conflitos em PRs de Correção de SCA

Quando o ZeroPath cria um pull request para corrigir uma dependência vulnerável, a branch base pode receber novos commits que conflitam com a branch de correção. O ZeroPath detecta e resolve esses conflitos automaticamente:
  • Conflitos em lockfiles são resolvidos regenerando o lockfile por meio da execução do gerenciador de pacotes em sandbox.
  • Conflitos em manifestos são resolvidos reaplicando o aumento de versão sobre a branch base mais recente e regenerando os lockfiles.
  • Conflitos de código (arquivos que não são de dependências) exigem resolução manual.
Isso mantém os PRs de correção gerados automaticamente aptos a merge, sem intervenção manual na maioria dos casos.

​
Pelo Dashboard

  1. Navegue até Scanner no dashboard do ZeroPath.
  2. Selecione o nível Organization, Tag ou Repository.
  3. Modifique as configurações conforme necessário.
  4. As alterações entram em vigor no próximo scan.

​
Opções de Exportação de Issues

Ao exportar issues via API, você pode personalizar a saída com opções adicionais:
  • Sobrescritas de filtro de exportação — restrinja a exportação a níveis de severidade, status ou tipos de detecção específicos, sem alterar sua configuração de filtros salva. Se qualquer array de sobrescrita estiver vazio, a exportação não retorna resultados para aquela dimensão.
  • Opções de SARIF — controle se a exportação inclui preconditions (fatores de explorabilidade que o scanner não pôde verificar completamente) e attackSteps (passo a passo de exploração) para cada achado. Ambos são omitidos por padrão para manter os payloads de exportação compactos.

​
Pela API

As configurações do scanner podem ser lidas e atualizadas via API v2: