> ## 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. # Visão Geral do SAST > Encontre vulnerabilidades de lógica de negócio como autenticação quebrada, IDOR e mais, com menos falsos positivos.

Como Funciona

O SAST (Static Application Security Testing) da ZeroPath usa um pipeline de análise multiestágio baseado em IA para descobrir vulnerabilidades que scanners tradicionais de correspondência de padrões não detectam: Executa em push, PR ou agendamento. Constrói um modelo de arquitetura, analisa o código e valida cada descoberta com IA. Identifica serviços e módulos no seu repositório (por exemplo, `/apps/payments`) para que as descobertas sejam associadas ao time correto. Revisa cada candidata quanto à explorabilidade e ao contexto, reduzindo falsos positivos em até 75%.

Fluxo de Ponta a Ponta

A ZeroPath clona seu repositório e fixa o commit exato, garantindo resultados reproduzíveis. Um analisador com IA mapeia os serviços, módulos e pontos de entrada da sua base de código para que cada descoberta possa ser atribuída à aplicação e ao time corretos. Se você tiver definido [declarações personalizadas de source ou sink](/pt/platform/scanner-settings#custom-sources--sinks), a ZeroPath prepara resumos otimizados para cada declaração no início do scan, para que possam ser avaliadas de forma eficiente junto com as detecções integradas ao longo do scan. Regras amplas de análise estática são executadas em todas as linguagens suportadas, produzindo um conjunto inicial de descobertas candidatas. A análise source-to-sink identifica pontos de entrada de dados externos (sources) e operações sensíveis (sinks) no seu código — incluindo quaisquer [sources e sinks personalizados](/pt/platform/scanner-settings#custom-sources--sinks) que você tenha declarado. As declarações personalizadas são avaliadas nas mesmas passagens de pré-triagem e inspeção profunda que as detecções integradas, de modo que os padrões declarados de forma personalizada recebem a mesma profundidade de análise que as classes de vulnerabilidade padrão. Cada candidata é revisada em contexto. A IA avalia a explorabilidade, o fluxo de código e a lógica ao redor para filtrar falsos positivos, reduzindo o ruído em até 75%. Os caminhos de arquivo referenciados nas descobertas são validados contra o conteúdo real do repositório, evitando que caminhos alucinados ou incorretos cheguem aos seus resultados. Antes da validação por IA, filtros determinísticos de falsos positivos removem descobertas reconhecidamente ruidosas — por exemplo, marcadores Unicode bidirecionais em arquivos que não são código-fonte (como locales JSON ou documentos markdown) são automaticamente excluídos, já que são arquivos de dados em que tais marcadores não representam um risco de segurança. Além disso, regras amplas de baixa confiança que produzem um grande número de ocorrências são automaticamente limitadas por regra antes da validação por IA, evitando que regras ruidosas consumam o orçamento de validação e reduzindo o tempo total de scan. Antes da validação completa, toda candidata que não seja de SCA passa por uma pré-triagem leve de severidade. As candidatas abaixo do limiar de severidade são filtradas cedo, reduzindo o tempo de scan e concentrando a passagem de validação mais profunda nas descobertas com maior probabilidade de importar. Quando o número de candidatas que chegam à etapa de validação excede o orçamento interno de validação, a ZeroPath prioriza primeiro as candidatas mais severas. Descobertas de maior severidade são validadas antes das de menor severidade, para que as vulnerabilidades potenciais de maior impacto sempre recebam análise completa. As candidatas que excedem o orçamento são preservadas com sua pontuação de severidade da pré-triagem quando disponível, garantindo que ainda apareçam nos seus resultados no nível de confiança da pré-triagem em vez de serem descartadas silenciosamente. Descobertas de Secrets, IaC e CI/CD usam pipelines de validação dedicados, adaptados ao seu tipo, em vez do validador genérico de alcançabilidade do SAST. Segredos são validados por um processo específico para segredos que inclui verificação ativa de credenciais quando possível, descobertas de IaC são validadas contra o contexto de implantação (se o recurso está de fato implantado), e descobertas de CI/CD são validadas contra o contexto de gatilho do workflow (se o gatilho do workflow expõe a fraqueza). Isso garante que cada tipo de descoberta seja avaliado com a pergunta certa — por exemplo, "esta credencial está ativa?" em vez de "isto é explorável a partir de entrada externa?" — melhorando a precisão em todos os módulos de verificação. Uma segunda passagem de validação então revisa todas as descobertas verdadeiro-positivas restantes antes de serem registradas. Essa passagem pode remover descobertas duplicadas que compartilham a mesma causa raiz em localizações sobrepostas, marcar descobertas não exploráveis (código morto, fixtures de teste, entradas sanitizadas) e corrigir detalhes imprecisos como título, descrição ou severidade — melhorando ainda mais a qualidade do sinal e reduzindo o ruído. Um agente de IA sensível ao contexto realiza uma análise mais profunda, examinando fluxos de autenticação, lógica de autorização, regras de negócio e políticas de segurança personalizadas. O agente pode seguir cadeias de chamadas estendidas e fluxos de dados entre arquivos, oferecendo cobertura completa de padrões complexos de vulnerabilidade. Se o agente de análise profunda ou a etapa de validação encontrar erros internos repetidos durante um scan, a ZeroPath para automaticamente de iniciar novas análises para os arquivos afetados, a fim de preservar a estabilidade do scan. Os resultados de pré-triagem das etapas anteriores são mantidos para quaisquer investigações puladas, de modo que você ainda recebe descobertas no nível de confiança da pré-triagem em vez de perder a cobertura por completo. Descobertas em arquivos cuja análise foi pulada — seja durante a investigação profunda ou a validação — são transportadas de scans anteriores em vez de serem resolvidas automaticamente, evitando que vulnerabilidades confirmadas sejam falsamente marcadas como corrigidas quando o scanner simplesmente não pôde reexaminá-las. Quando a investigação de um agente atinge seu limite de profundidade de análise sem convergir para um veredito, a ZeroPath agora resgata um resultado final estruturado a partir das evidências já coletadas, em vez de descartar a investigação inteira. A passagem de resgate faz uma única chamada não recursiva para produzir um veredito a partir da transcrição acumulada, de modo que você recebe um resultado para a grande maioria das investigações que antes seriam descartadas. Arquivos em que uma investigação ficou incompleta são sinalizados com um aviso de **Investigation incomplete**, para que você veja exatamente quais arquivos foram afetados; as descobertas existentes nesses arquivos são mantidas e serão verificadas novamente no próximo scan bem-sucedido. Quaisquer regras em linguagem natural que você tenha definido são avaliadas por aplicação, capturando políticas de segurança específicas da organização. Se você excluir uma regra personalizada enquanto um scan está em andamento, quaisquer descobertas vinculadas a essa regra são descartadas de forma controlada antes de os resultados serem persistidos — o scan é concluído normalmente em vez de falhar. As descobertas são deduplicadas entre ferramentas e scans históricos. Quando um único arquivo contém um grande número de descobertas candidatas — por exemplo, provenientes de conjuntos extensos de regras personalizadas — a etapa de consolidação as divide automaticamente em lotes gerenciáveis e executa uma passagem final entre lotes para capturar duplicatas entre eles, garantindo deduplicação confiável independentemente do volume de descobertas. Quando vários modelos de descoberta são executados em paralelo, descobertas que referenciam o mesmo arquivo, categoria de vulnerabilidade e intervalo de linhas sobreposto, com títulos semelhantes, são automaticamente colapsadas em uma única descoberta canônica. A descrição mais detalhada é preservada, e descrições complementares de outros modelos são anexadas para referência. Descobertas de Secrets, IaC, CI/CD e EOL ignoram completamente a consolidação do SAST porque cada uma representa um problema distinto — por exemplo, duas configurações incorretas de IaC no mesmo arquivo (como um bucket de armazenamento público e falta de criptografia) são problemas independentes, não duplicatas. A deduplicação entre fontes (quando a mesma vulnerabilidade é sinalizada por vários mecanismos de verificação) agora processa as descobertas em blocos delimitados por arquivo. Cada bloco é avaliado de forma independente, de modo que uma falha transitória em um bloco não descarta os resultados de deduplicação do restante do scan — as descobertas do bloco afetado são mantidas como estão, enquanto os blocos deduplicados com sucesso prosseguem normalmente. Cada descoberta confirmada recebe uma pontuação de severidade CVSS 4.0 com justificativa gerada por IA, etapas de exploração do ataque passo a passo, um conjunto de **pré-condições** de explorabilidade descrevendo fatores do contexto de implantação que o scanner não pôde verificar por completo, e um rótulo de **impacto de segurança** resumindo o resultado real para o atacante (por exemplo, "Account Takeover" ou "Remote Code Execution"). O rótulo de impacto é exibido em destaque no cabeçalho de detalhes da issue ao lado da classe de vulnerabilidade, para que você possa avaliar o risco real de relance. Para scans completos, a deduplicação tem escopo por branch, de modo que cada branch mantém descobertas independentes — resolver uma issue em uma branch não afeta a mesma issue em outra branch. Para scans de PR, a deduplicação tem escopo definido para evitar contaminação entre branches — descobertas de um pull request só são deduplicadas contra as linhas de base de scans completos e rescans do mesmo PR, não contra descobertas de outros pull requests. Isso garante que os resultados de cada PR reflitam com precisão as alterações de código daquela branch. Quando uma descoberta existente é redetectada em um scan subsequente, a ZeroPath atualiza automaticamente a atribuição de contribuidor e os dados de localização do código para refletir o estado atual do código, mantendo as informações de blame precisas conforme sua base de código evolui. Quando uma descoberta recém-detectada corresponde a várias issues históricas (por exemplo, descobertas quase idênticas em localizações semelhantes no mesmo arquivo), a ZeroPath agora vincula a detecção a todas as issues correspondentes, não apenas à correspondência principal. Isso evita que issues não vinculadas sejam falsamente resolvidas automaticamente como "não mais detectadas" quando a vulnerabilidade subjacente ainda está presente. A correlação histórica — o processo que compara descobertas recém-detectadas com issues conhecidas anteriormente — é resiliente a erros transitórios: se um lote de correlação falhar, os lotes restantes ainda são concluídos e o scan prossegue normalmente. Descobertas de SCA agora são correlacionadas entre scans com base no nome do pacote, no identificador do advisory e na localização, sem depender de identificadores internos de caminho de exploração que podem mudar entre scans. Isso significa que uma descoberta de SCA existente é confiavelmente associada ao seu registro anterior no rescan, em vez de aparecer como uma nova issue. Descobertas com estado de validação desconhecido (quando a explorabilidade não pode ser determinada) são categorizadas como **Informational** em vez de não exploráveis, dando a você um sinal mais claro sobre quais descobertas precisam de investigação adicional. Quando a validação não pôde ser executada de forma alguma (por exemplo, porque o limite de profundidade de análise foi atingido durante a tentativa de validação), a descoberta é exibida como **Pending Review**, para que você possa distinguir entre descobertas que foram inconclusivas e descobertas que nunca foram totalmente avaliadas. Descobertas que chegam ao estado **Pending Review** ainda carregam a pontuação de severidade da pré-triagem inicial, de modo que aparecem em listas classificadas e podem ser triadas com base em sua severidade conhecida, mesmo sem um veredito de alcançabilidade. As descobertas validadas são gravadas de forma atômica e exibidas no seu dashboard, na API e nas integrações. Uma passagem final de deduplicação é executada logo antes de as descobertas serem persistidas, capturando quaisquer duplicatas restantes acumuladas ao longo das etapas de processamento. Isso garante que apenas descobertas únicas sejam registradas, mesmo quando vários caminhos de detecção produzem resultados sobrepostos.

Executando Scans

Análise abrangente de toda a sua base de código. Disparada manualmente, por agendamento ou quando código é enviado para branches monitoradas. Você pode escanear todos os repositórios de uma vez usando a opção **Select All** no modal Start Scan ou via API. Ao escanear todos os repositórios, apenas os repositórios vinculados a um VCS são incluídos — repositórios enviados por upload sem um remoto são excluídos. Você também pode excluir repositórios específicos de uma solicitação de "scan all", se necessário. Você também pode iniciar scans em massa a partir da página **Repositories**, selecionando vários repositórios e escolhendo **Start Scan** no menu de ações em massa. Para organizações com cobrança baseada em créditos, um diálogo de confirmação mostra o custo em créditos cotado para cada repositório antes do início dos scans, para que você possa revisar o custo total e confirmar antes que quaisquer créditos sejam debitados. Se sua conta tiver créditos insuficientes, você será solicitado a comprar mais antes de prosseguir. Em scans subsequentes da mesma branch, a ZeroPath reutiliza de forma inteligente os resultados de arquivos inalterados e concentra a análise profunda apenas nos arquivos alterados, reduzindo significativamente o tempo de scan. Arquivos grandes de terceiros (vendored), gerados e de dados de teste/fixture são automaticamente identificados e excluídos da análise profunda — por exemplo, arquivos em diretórios `vendor/`, `node_modules/` ou `generated/`, arquivos com sufixos de código gerado (como `.pb.go` ou `_pb2.py`) e arquivos cujos cabeçalhos contêm marcadores `@generated` ou `auto-generated`. Isso mantém o tempo de scan focado no seu próprio código, em vez de fontes de terceiros ou produzidas por máquina. Quando as alterações desde o último scan são pequenas ou moderadas, a ZeroPath pode usar um modo de rescan inteligente que avalia apenas o diff. Um agente de IA revisa se as issues existentes ainda estão presentes e se o novo código introduz alguma vulnerabilidade, entregando resultados significativamente mais rápido do que uma execução completa do pipeline. O agente de rescan inspeciona as issues por arquivo e as resolve por intervalo exato de linhas e comportamento, de modo que, se uma vulnerabilidade em um arquivo for corrigida enquanto outra permanece, apenas a issue corrigida é marcada como resolvida. Para diffs maiores que excedem o limiar de passagem única mas ainda estão dentro do intervalo do rescan diferencial, a ZeroPath divide automaticamente os arquivos alterados em blocos e os revisa em paralelo. Cada bloco é analisado de forma independente por sua própria passagem de agente de IA, e os resultados são reconciliados em um único conjunto de descobertas após a conclusão de todos os blocos. Isso significa que mais rescans permanecem no caminho diferencial rápido em vez de recorrer a um pipeline completo, reduzindo significativamente o tempo de scan para conjuntos de alterações de médio a grande porte. Se você tiver configurado [regras personalizadas](/pt/platform/custom-rules), [sources personalizados](/pt/platform/scanner-settings#custom-sources--sinks) ou [sinks personalizados](/pt/platform/scanner-settings#custom-sources--sinks), o agente de rescan diferencial agora os aplica junto com sua análise de segurança geral. Regras em linguagem natural são comparadas com seus globs de arquivo configurados, e sources e sinks de taint personalizados são usados durante o rastreamento de fluxo de dados pelo código alterado — de modo que scans incrementais aplicam as mesmas políticas específicas da organização que os scans completos. O mecanismo de scan diferencial classifica automaticamente os arquivos alterados para determinar a estratégia de scan mais eficiente. Quando apenas arquivos de código mudam, a ZeroPath executa apenas o caminho rápido de rescan. Quando apenas manifestos de dependência ou lockfiles mudam, uma passagem leve de SCA é executada enquanto as descobertas de SAST são transportadas. Quando tanto arquivos de código quanto de dependência mudam, a ZeroPath executa o rescan e o SCA juntos — sem acionar um pipeline completo. Arquivos que não são de código, como lockfiles, source maps, imagens e assets gerados, são excluídos do cálculo do tamanho do diff, de modo que grandes atualizações de dependências não forçam mais scans completos desnecessários. Quando as configurações do seu scanner mudam entre scans mas o código em si permanece inalterado, a ZeroPath avalia quais categorias de configuração foram afetadas. Se apenas configurações seguras para rollover mudaram — como configuração de análise de dependências ou tier de modelo/modo de desempenho — a ZeroPath atualiza a categoria afetada enquanto transporta as descobertas existentes das outras categorias, evitando uma execução completa e desnecessária do pipeline. Mudanças de tier de modelo e de modo de alto desempenho são aplicadas de forma preguiçosa: a nova configuração entra em vigor no próximo scan natural de cada repositório, em vez de forçar um re-scan completo imediato, e as descobertas anteriores são preservadas nesse meio-tempo. Quando a única mudança de configuração é habilitar ou desabilitar módulos de verificação que não afetam as descobertas transportadas — como AI Inventory ou SCA — a ZeroPath também usa o caminho rápido de rollover em vez de um pipeline completo. As descobertas de SCA são recalculadas do zero em cada scan, e o AI Inventory produz dados de componentes em vez de descobertas de segurança, de modo que adicionar ou remover esses módulos não altera o conjunto de descobertas de SAST, segredos, IaC ou EOL que são transportadas. Isso significa que implantações de módulos em toda a frota (por exemplo, habilitar o AI Inventory em todos os repositórios) não forçam mais um re-scan completo de todos os repositórios inalterados. Habilitar ou desabilitar módulos que produzem descobertas (como Secrets, IaC, EOL ou verificação de Containers) ainda aciona um rescan completo para garantir cobertura total, assim como qualquer mudança em regras personalizadas, sources/sinks ou configuração do SAST. Em configurações de monorepo, o agente de rescan tem escopo limitado à partição atual do repositório. Apenas arquivos e descobertas dentro do escopo de scan configurado são avaliados, evitando interferência entre partições quando várias equipes compartilham um único repositório. A ZeroPath usa um pipeline de detecção de regressão em três níveis para determinar de forma eficiente se issues relatadas anteriormente ainda estão presentes após alterações de código: 1. **Caminho rápido determinístico** — se nenhum dos arquivos relevantes para uma descoberta mudou entre os commits, a descoberta é transportada instantaneamente, sem nenhuma chamada de IA. 2. **Revisão estruturada de diff** — quando arquivos relevantes mudaram, uma única revisão de IA examina o diff delimitado e as evidências de código para decidir se a issue persiste ou foi corrigida. 3. **Escalação para agente profundo** — somente quando a evidência delimitada é insuficiente a ZeroPath escala para uma investigação agêntica completa, mantendo custos e latência baixos no caso comum. Scans incrementais, focados no diff, que analisam apenas o código alterado em pull requests. Os resultados aparecem como comentários inline e status de check diretamente no seu VCS. Quando um scan de PR determina que uma issue relatada anteriormente foi remediada no pull request atual, a ZeroPath marca automaticamente a descoberta original como resolvida e registra o motivo, mantendo sua lista de issues atualizada sem triagem manual. Descobertas que você confirmou como verdadeiro-positivas por meio de investigação nunca são resolvidas automaticamente por scans de PR. Se uma descoberta confirmada como verdadeiro-positiva não for redetectada durante uma atualização de scan de PR, ela é transportada do scan anterior em vez de ser marcada como resolvida. Qualquer estado obsoleto de "não mais detectada" de um scan anterior também é limpo, garantindo que a descoberta permaneça ativa até que seja explicitamente tratada ou reavaliada em um scan completo. Quando um PR é atualizado após um scan anterior ter sido pulado (por exemplo, porque as alterações anteriores não eram relevantes para a segurança), a ZeroPath exclui corretamente o scan pulado da linha de base da atualização, garantindo que a comparação incremental cubra o conjunto completo de alterações do PR. **Verificação de Correção:** Você pode referenciar issues existentes da ZeroPath na descrição do seu PR para verificar se o PR as resolve. Adicione referências usando um destes formatos: * `ZP-ID: ` — referencia uma única issue * `ZP-ID: , , ` — referencia várias issues em uma linha * Cole uma URL do dashboard da ZeroPath que contenha a issue (por exemplo, da página de detalhes da issue) Várias linhas `ZP-ID:` são suportadas, e você pode misturar formatos na mesma descrição de PR. Quando o scan de PR é concluído, a ZeroPath verifica se cada issue referenciada ainda foi detectada. Se uma issue referenciada não for mais detectada, confirma-se que o PR a corrige. Os resultados aparecem em uma tabela **Referenced Vulnerabilities** no comentário do PR, mostrando o status de cada issue referenciada. Após o merge do PR, as correções verificadas são automaticamente marcadas como resolvidas. Nenhuma configuração adicional é necessária — a verificação de correção é executada automaticamente sempre que referências a issues são detectadas em uma descrição de PR. Consulte [Scans de PR](/pt/scanning/pr-scanning) para mais detalhes.

Categorias de Vulnerabilidade

| Categoria | Exemplos | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Injeção** | Injeção de SQL, injeção de comando, injeção de LDAP | | **Cross-Site Scripting (XSS)** | XSS refletido, XSS armazenado, XSS baseado em DOM | | **Server-Side Request Forgery (SSRF)** | Acesso a serviços internos, exfiltração de metadados de nuvem | | **Operações de Arquivo** | Path traversal, inclusão local de arquivo, leitura/gravação arbitrária de arquivos | | **Desserialização Insegura** | Injeção de objetos, execução remota de código via desserialização | | **XML External Entity (XXE)** | Expansão de entidades externas, SSRF via XML | | **Injeção de Template** | Injeção de template do lado do servidor (SSTI) | | **Criptografia** | Algoritmos fracos, chaves embutidas no código, comprimento de chave insuficiente | | **Redirecionamento Aberto** | Destinos de redirecionamento não validados | | **Configuração Incorreta de CORS** | Políticas de origem cruzada excessivamente permissivas | | **CSRF** | Proteções contra cross-site request forgery ausentes ou contornáveis | | **Segurança de LLM** | Injeção de prompt, tratamento inseguro de saída, vazamento de prompt de sistema, agência excessiva (OWASP LLM Top 10) | | **Negação de Serviço** | ReDoS, esgotamento de recursos, complexidade algorítmica | | **Divulgação de Informações** | Dados sensíveis em respostas, vazamento em mensagens de erro | | **Reflexão** | Falhas de entrada refletida, reflexão insegura | | **Segurança de Memória** | Buffer overflows, use-after-free, acesso fora dos limites | | **Validação de Entrada** | Validação de entrada ausente ou inadequada | | **Configuração** | Padrões inseguros, modo de depuração em produção | | Categoria | Exemplos | | ----------------------------- | ------------------------------------------------------------------------ | | **Autenticação** | Verificações de autenticação ausentes, fluxos de autenticação quebrados | | **Autorização** | Controle de acesso quebrado, escalação de privilégios, IDOR | | **Gerenciamento de Sessão** | Fixação de sessão, tokens de sessão fracos, sequestro de sessão | | **Falhas de Lógica** | Condições de corrida, bypass de fluxo de trabalho, manipulação de estado | | **Adulteração de Parâmetros** | Manipulação de preço no lado do cliente, modificação de campos ocultos | | **Validação de Dados** | Falhas de validação semântica, confusão de tipos | | **Divulgação de Informações** | Vazamento de dados na camada de lógica, exposição excessiva de dados |

Pontuação de Severidade

A ZeroPath usa o **CVSS 4.0** como seu padrão principal de pontuação, e também fornece pontuações **CVSS 3.1** para compatibilidade com ferramentas e fluxos de trabalho que exigem o padrão mais antigo. Cada descoberta confirmada recebe uma pontuação estruturada com justificativa gerada por IA vinculada diretamente ao código. As descobertas também recebem um ou mais **identificadores CWE** para classificação precisa da fraqueza. Avaliações CVSS são geradas para quase todas as descobertas de segurança — apenas issues que não são de segurança, como problemas de qualidade ou estilo de código, são excluídas. **Descobertas de Segurança de LLM** (OWASP LLM Top 10) são pontuadas de forma conservadora: a maioria recebe severidade de 2.0–5.0, a menos que a saída do LLM flua diretamente para um sink perigoso (como `eval`, SQL ou um comando de shell) sem nenhuma validação, caso em que o impacto do sink downstream é pontuado. Descobertas de vazamento de prompt de sistema e agência excessiva são tipicamente pontuadas em 1.0–3.0. | Métrica | Valores | O Que Captura | | ---------------------------- | ------------------------- | ----------------------------------------------------------------- | | Vetor de Ataque | Rede / Local | Se é explorável remotamente ou requer acesso local | | Complexidade do Ataque | Baixa / Alta | Confiabilidade do exploit; se condições especiais são necessárias | | Requisitos do Ataque | Nenhum / Presente | Se pré-requisitos (configuração/estado específicos) são exigidos | | Privilégios Necessários | Nenhum / Baixo / Alto | Nível de privilégio de que o atacante precisa | | Interação do Usuário | Nenhuma / Passiva / Ativa | Se um usuário precisa agir para a exploração | | Impacto na Confidencialidade | Nenhum / Baixo / Alto | Impacto no sigilo dos dados | | Impacto na Integridade | Nenhum / Baixo / Alto | Impacto na integridade dos dados ou do sistema | | Impacto na Disponibilidade | Nenhum / Baixo / Alto | Impacto na disponibilidade do sistema | Cada métrica inclui uma justificativa escrita vinculada ao trecho de código específico e ao contexto da vulnerabilidade. Além do CVSS 4.0, cada descoberta também recebe uma pontuação **CVSS 3.1** derivada da mesma análise. O vetor 3.1 inclui a métrica **Scope** (Unchanged ou Changed), que indica se um exploit pode afetar recursos além do componente vulnerável. Essa abordagem de pontuação dupla permite usar o CVSS 4.0 para avaliação de risco moderna, mantendo a compatibilidade com o CVSS 3.1 para dashboards, frameworks de conformidade e integrações existentes que ainda não adotaram o 4.0. Descobertas mais antigas que foram originalmente pontuadas apenas com CVSS 4.0 são automaticamente preenchidas retroativamente com vetores e pontuações de severidade CVSS 3.1 derivados, de modo que você pode filtrar e ordenar todas as descobertas por CVSS 3.1 sem lacunas de cobertura. A **pontuação de prioridade da descoberta** geral combina severidade com confiança: `severity (0–10) × confidence (0–10)` = uma **escala de 0–100** para classificação e filtragem. Isso significa que uma descoberta de alta severidade com baixa confiança fica abaixo de uma descoberta de severidade média com alta confiança — ajudando você a focar em issues que são ao mesmo tempo impactantes e identificadas com confiabilidade. Para descobertas em que a validação não pôde ser executada (exibidas como **Pending Review**), a confiança não é definida porque nenhuma avaliação de verdadeiro-positivo foi produzida. Essas descobertas ainda recebem uma pontuação de prioridade derivada apenas da severidade, de modo que aparecem em listas classificadas e exportações em vez de ficarem ocultas. Você pode sobrescrever manualmente a severidade de uma descoberta de duas maneiras: * **Por pontuação bruta** — defina diretamente a severidade de 0–10. A pontuação de prioridade da ZeroPath é recalculada automaticamente. * **Por classificação** — defina o rótulo de classificação desejado (Critical, High, Medium, Low ou Informational) e a plataforma deriva a severidade de 0–10 que coloca a descoberta nessa faixa, levando em conta sua confiança. Isso é útil quando você quer rebaixar uma descoberta para uma classificação específica sem calcular a pontuação numérica você mesmo. Ambos os métodos atualizam em conjunto a severidade armazenada da descoberta, a pontuação de prioridade da ZeroPath e a pontuação base CVSS, e registram a alteração no log de auditoria. Descobertas de baixa confiança podem ter a classificação reduzida, mas não aumentada: se a confiança de uma descoberta for baixa demais para atingir o limiar de pontuação da faixa desejada, a plataforma rejeita a solicitação em vez de ajustar silenciosamente para uma classificação diferente.

Cobertura de Linguagens

Cada descoberta é marcada com a linguagem detectada do arquivo afetado, permitindo filtragem e orientações de remediação sensíveis à linguagem. A detecção de linguagem cobre extensões de arquivo comuns, bem como as menos óbvias — por exemplo, a verificação de C inclui arquivos de cabeçalho `.inc` e a verificação de Ruby inclui templates `.erb` — de modo que descobertas nesses arquivos são corretamente atribuídas e analisadas.

Principais Capacidades

A validação por IA revisa cada descoberta em contexto, filtrando issues que não são de fato exploráveis. A análise profunda por IA descobre vulnerabilidades que a correspondência de padrões sozinha não consegue encontrar, incluindo falhas de lógica de negócio. Cada descoberta é vinculada ao serviço ou módulo específico que ela afeta, com contexto de stack tecnológica e arquitetura. Você pode filtrar a lista de issues por aplicação usando um filtro **Application** dedicado na barra de ferramentas, com escopo nos repositórios que você selecionou. Isso facilita focar em descobertas de um serviço ou módulo específico em um monorepo. Rastreamentos source-to-sink mostram exatamente como dados contaminados alcançam operações vulneráveis. Toda descoberta explorável inclui um caminho de fluxo de dados obrigatório. Quando uma descoberta envolve uma declaração de [source personalizado](/pt/platform/scanner-settings#custom-sources--sinks) ou [sink personalizado](/pt/platform/scanner-settings#custom-sources--sinks), os detalhes do fluxo de dados incluem o nome e a descrição da declaração personalizada, para que você veja exatamente qual ponto de entrada ou operação sensível definido de forma personalizada foi correspondido. As prévias de source e sink exibem um selo **Custom Source** ou **Custom Sink** quando a descoberta se originou de uma declaração personalizada, e você pode clicar para visualizar ou editar a declaração diretamente do painel de detalhes da issue. Para vulnerabilidades de SCA, a árvore de fluxo de dados inclui o arquivo de manifesto em que a dependência afetada é declarada, dando visibilidade direta sobre qual arquivo de dependência introduz o risco. O explorador de scans inclui dropdowns de navegação de repositório e de scan para que você possa alternar rapidamente entre repositórios e comparar resultados entre scans recentes sem sair da página. Descobertas vinculadas a uma aplicação mas não a um handler de source específico aparecem sob um nó **Standalone Findings** na árvore do explorador de scans, de modo que estão sempre visíveis e nunca se perdem. Cada descoberta inclui uma descrição passo a passo de como um atacante exploraria a vulnerabilidade, dos pré-requisitos ao impacto — ajudando engenheiros de AppSec a avaliar riscos rapidamente. Um Exploit Walkthrough expansível mostra a sequência ordenada de ações que um atacante executaria. Essas etapas de ataque também estão disponíveis como dados estruturados na resposta da API de detalhes da issue, tornando-as fáceis de consumir em fluxos de trabalho automatizados e integrações. Ao exportar issues via API, você pode incluir as etapas de ataque na exportação definindo a opção SARIF `includeExploitWalkthrough`. Toda descoberta inclui uma lista de **pré-condições** — fatores que afetam se a vulnerabilidade é de fato explorável, mas que o scanner não pode verificar por completo apenas pelo código. Exemplos incluem se o endpoint está exposto à internet, se um WAF ou API gateway filtra entradas maliciosas e se a autenticação é aplicada por middleware não visível no código escaneado. Você pode expandir cada pré-condição para ver as evidências de apoio do scanner na sua base de código, ajudando a avaliar rapidamente o risco real sem reinvestigar a descoberta você mesmo. As pré-condições também estão disponíveis como dados estruturados na resposta da API de detalhes da issue, tornando-as fáceis de consumir em fluxos de trabalho automatizados e integrações. Ao exportar issues via API, você pode incluir as pré-condições na exportação definindo a opção SARIF `includePreconditions`. A mesma base de código no mesmo commit produz as mesmas descobertas, permitindo auditorias confiáveis e acompanhamento de conformidade. Descobertas qualificadas podem ser corrigidas automaticamente com correções de código geradas por IA. Quando um patch está sendo gerado, um rastreador de progresso passo a passo mostra a etapa atual — Assigned, Preparing repository, Generating fix e Finalizing — junto com um cronômetro ao vivo do tempo decorrido, para que você possa acompanhar o progresso em tempo real. A verificação de segredos executa vários mecanismos de detecção em paralelo, cruzando os resultados para maximizar a cobertura enquanto deduplica descobertas sobrepostas de diferentes mecanismos. Cada descoberta de segredo inclui um estado de validação — **Confirmed** (verificado como ativo), **Disconfirmed** (verificado como inativo ou falso positivo) ou **Unknown** (a validação não pôde ser executada) — junto com um motivo quando a validação é inconclusiva. Segredos confirmados e desconhecidos incluem etapas de ataque e pré-condições de explorabilidade, assim como as descobertas de SAST, para que você possa avaliar o impacto real de uma credencial vazada de relance. Trechos de código de descobertas de segredos são sempre retornados de forma redigida via API e exportações — o valor bruto do segredo nunca é incluído nos campos de trecho, sendo substituído por um placeholder mascarado. Solicite uma reinvestigação mais profunda de qualquer descoberta usando modelos de IA maiores para resultados de validação com maior confiança. Você pode disparar investigações a partir da visão de detalhes da issue — inclusive pela ação **Reinvestigate** no menu de ações da issue — e acompanhar o progresso em tempo real. Faça perguntas sobre qualquer descoberta diretamente da visão de detalhes da issue. Um painel de chat dedicado, com escopo na issue específica, pode explicar como a vulnerabilidade pode ser explorada, sugerir correções e avaliar a alcançabilidade — tudo sem sair do dashboard. Você também pode excluir threads de chat de que não precisa mais. Adicione notas de texto livre a qualquer descoberta diretamente da visão de detalhes da issue. As notas são compartilhadas com todos na sua organização e persistem junto à issue, facilitando o registro de decisões de triagem, detalhes de workarounds ou contexto para o seu time. As notas podem ter até 5.000 caracteres e podem ser atualizadas ou descartadas a qualquer momento. A lista global de issues exibe a branch alvo do scan para cada descoberta, facilitando ver em qual branch uma vulnerabilidade foi detectada. Combinado com a deduplicação por branch, você pode rastrear e filtrar descobertas entre branches sem confusão.

Investigação

Você pode solicitar a investigação sob demanda de qualquer descoberta para obter uma avaliação mais profunda e com maior confiança. Quando você dispara uma investigação, a ZeroPath reavalia a descoberta usando modelos de IA mais poderosos: * **Descobertas de SAST** são revalidadas com um modelo maior que examina a explorabilidade com mais contexto e nuance. * **Descobertas de SCA em dependências diretas** passam por análise de alcançabilidade para determinar se o caminho de código vulnerável é de fato alcançável no seu projeto. Os resultados são rotulados como "Likely Reachable" ou "Likely Not Reachable" para refletir a natureza probabilística da análise, e incluem um resumo detalhado de alcançabilidade explicando o raciocínio. Quando uma avaliação de SCA encontra erros de análise repetidos, as falhas são contadas por pacote em vez de por tentativa, de modo que um único pacote com muitos advisories que esgota o limite de profundidade de análise não impede que outros pacotes sejam investigados. * **Descobertas de SCA em dependências transitivas** passam por um processo em duas fases: primeiro, uma etapa de triagem determina se a explorabilidade pode sequer ser avaliada e, em caso afirmativo, uma análise completa de alcançabilidade rastreia a cadeia de dependências para verificar se a vulnerabilidade é alcançável através dos pacotes pais. A resolução de dependências transitivas é suportada para Java (Maven, Gradle), Scala (sbt), Python (pip), .NET e Rust (Cargo). Descobertas de SCA também exibem **inteligência de exploits** quando disponível: um selo **CISA KEV** (Known Exploited Vulnerabilities) indica que a vulnerabilidade está sendo ativamente explorada no mundo real, incluindo a data em que foi adicionada ao catálogo KEV e se está associada a campanhas de ransomware. Uma pontuação **EPSS** (Exploit Prediction Scoring System) mostra a probabilidade de a vulnerabilidade ser explorada, exibida como uma porcentagem junto ao seu percentil. Esses indicadores aparecem no painel de detalhes da vulnerabilidade e ajudam você a priorizar descobertas com base no risco real de exploração. Descobertas de SCA também exibem o caminho do arquivo de manifesto com um link direto para visualizar o arquivo no seu repositório. Quando uma dependência é detectada a partir de um binário compilado em vez de um arquivo de manifesto, isso é indicado nos detalhes do pacote. O cabeçalho de detalhes da issue para descobertas de SCA inclui links diretos para o advisory de segurança relevante e o CVE associado (advisories GHSA levam ao deps.dev, advisories CVE levam ao NVD), para que você possa acessar rapidamente as informações da vulnerabilidade upstream sem sair da plataforma. **Descobertas de containers** são produzidas executando dois mecanismos de verificação independentes contra cada imagem de container e cruzando os resultados. Vulnerabilidades relatadas por ambos os mecanismos recebem maior confiança, enquanto descobertas exclusivas de um mecanismo ampliam a cobertura — dando a você os benefícios da detecção multi-engine sem ruído de duplicatas. Descobertas de containers exibem a referência da imagem de container escaneada e o pacote vulnerável (nome e versão instalada) em vez de um nome de repositório. Cada descoberta de container agrega os CVEs que afetam aquele pacote, exibidos como uma lista expansível em que cada linha de CVE mostra seu selo de severidade, identificador de CVE, pontuação CVSS e disponibilidade de correção de relance. Você pode expandir qualquer CVE para ver seus detalhes completos, incluindo o link do advisory, o vetor CVSS, a data de publicação e um resumo. Quando uma versão corrigida está disponível, um banner de recomendação de upgrade mostra para qual versão atualizar e quantas vulnerabilidades o upgrade resolve. Quando nenhuma versão corrigida foi publicada, a plataforma indica claramente que ainda não há correção disponível e recomenda acompanhar o advisory upstream. Descobertas de containers podem ser corrigidas diretamente, sem exigir uma etapa prévia de verificação, já que se baseiam em dados determinísticos de vulnerabilidade, e não em explorabilidade inferida por IA. Ao exportar descobertas de containers para o Jira ou Linear, a referência da imagem escaneada é usada como rótulo de origem em vez de um nome interno de repositório. Os resultados da investigação atualizam o estado de validação da descoberta (confirmada, desconfirmada ou desconhecida) e incluem uma avaliação de segurança detalhada explicando o raciocínio. Você pode solicitar investigações via API, ferramentas MCP ou diretamente da visão de detalhes da issue no dashboard usando a opção **Reinvestigate** no menu de ações. Enquanto uma investigação está em andamento, a visão de detalhes da issue mostra um indicador de status ao vivo, e os resultados aparecem automaticamente quando a análise é concluída. Quando uma investigação é concluída, a visão de detalhes da issue exibe um banner em destaque com um **veredito** com código de cores — **Confirmed** (explorável), **Not Exploitable** ou **Unknown** — junto com a avaliação de segurança completa, facilitando a identificação de issues de alta prioridade de relance. Descobertas com estado de validação desconhecido são rotuladas como **Informational**, indicando que correspondem a um advisory conhecido mas ainda não foram investigadas quanto à explorabilidade. Se a validação não pôde ser executada de forma alguma durante a tentativa de investigação, a descoberta é rotulada como **Pending Review**. Para descobertas que foram testadas dinamicamente por meio da Validação em Runtime, a visão de detalhes da issue mostra um painel dedicado de Runtime Validation com descrições de resultado sensíveis ao contexto. O título do resultado se adapta ao veredito: descobertas **Confirmed** mostram "What Was Confirmed", descobertas **Disconfirmed** mostram "Why It Was Not Exploitable" e resultados inconclusivos mostram "Why It Could Not Be Validated". Quando um caminho de ataque validado está disponível, ele é mostrado como uma sequência numerada de etapas; o conjunto completo de ações e observações do agente pode ser expandido separadamente. A narrativa de evidências, os alvos testados e os papéis testados são agrupados em uma seção recolhível "Evidence and scope". Quando a Validação em Runtime já exercitou uma descoberta, a geração separada de PoC não fica disponível para aquele resultado — em vez disso, o PoC da validação em runtime e quaisquer instruções de execução são exibidos diretamente na visão de detalhes da issue. Você também pode solicitar investigações em massa em várias issues de uma vez, o que é útil para triar um lote de descobertas. Quando uma descoberta não pode ser corrigida automaticamente, a plataforma exibe etapas de remediação com orientações específicas sobre como tratar a vulnerabilidade manualmente. Se uma descoberta foi anteriormente determinada como não corrigível, você pode usar o botão **Force Generate Patch** no painel de patches para solicitar outra tentativa. Um diálogo de confirmação explica o motivo pelo qual a issue foi marcada como não corrigível antes de prosseguir, para que você tenha o contexto completo antes de tentar novamente.

Checklist de Adoção

Adicione seu repositório via GitHub App, GitHub Enterprise Server, GitLab, Bitbucket, Azure DevOps Services ou URL direta. Consulte [Início Rápido](/pt/quickstart). O SAST vem habilitado por padrão nas configurações do scanner para todos os repositórios. Dispare um scan completo pelo dashboard ou aguarde o próximo scan agendado. Navegue pelas descobertas no dashboard, agrupadas por severidade, aplicação e categoria. Você pode filtrar as descobertas por tipo — incluindo SAST, SCA, Secrets, IaC, CI/CD, EoL e Container — para focar no que mais importa para o seu time. O dropdown de fonte de scan permite escolher entre **All** (todas as fontes combinadas), **Full Scans**, **PR Scans**, **SCA Scans** e **Container Scans**, para que você possa alternar rapidamente entre fontes de scan sem ajustar filtros individuais de tipo de detecção. As contagens das facetas de tipo de detecção incluem selos individuais de SCA e Container, para que você veja de relance quantas descobertas de supply chain e de container existem. O selo da categoria **All** conta apenas descobertas relacionadas a código (SAST, Secrets, IaC, CI/CD, EoL), já que a aba All leva à lista padrão somente de código — os totais de SCA e Container são mostrados em seus próprios selos. Você também pode filtrar por **veredito de validação em runtime** (Confirmed, Disconfirmed, Untestable ou Agent Error) para exibir rapidamente descobertas com base no resultado do teste dinâmico. Em configurações de monorepo, você também pode filtrar por aplicação para restringir a lista de issues a um serviço ou módulo específico dentro de um repositório. Cada issue tem uma URL compartilhável, de modo que você pode vincular diretamente a uma descoberta específica ao colaborar com seu time. Ao filtrar por repositório na página de Issues, você pode usar o seletor **Select All** para selecionar todos os repositórios de uma vez, sem enumerar cada um individualmente. Após selecionar todos, você pode excluir repositórios específicos dos resultados desativando-os — o filtro registra suas exclusões de forma compacta para que a página permaneça rápida mesmo em organizações com muitos repositórios. Você também pode excluir repositórios dos resultados via API usando o parâmetro `excludedRepositoryBranches`, o que é útil para omitir repositórios ruidosos ou irrelevantes de uma consulta ampla. Ajuste a filtragem por confiança e os limiares de falha de check em PRs para corresponder à tolerância do seu time. Ative a verificação de PRs para capturar vulnerabilidades antes que cheguem à sua branch principal. Encaminhe descobertas para o [Jira](/pt/integrations/jira), [Linear](/pt/integrations/linear), [Slack](/pt/integrations/slack) ou [webhooks](/pt/webhook/introduction). Você pode exportar descobertas individuais ou exportar várias descobertas em massa para o Jira ou Linear diretamente da lista de issues. O diálogo de exportação permite escolher entre os formatos **Regular CSV**, **CASA Relevant CSV** e **SARIF**. Antes de exportar, você pode usar controles granulares para sobrescrever os filtros de severidade, categoria e status de forma independente da sua visão atual — por exemplo, exportando apenas issues de severidade Critical e High em todos os status, sem alterar os filtros do seu dashboard. Uma prévia ao vivo mostra o número exato de issues que serão incluídas na sua exportação. Para exportações SARIF, você pode opcionalmente incluir pré-condições e o contexto do exploit walkthrough na saída. Adicione regras em linguagem natural para políticas de segurança específicas da organização. Consulte [Regras Personalizadas](/pt/platform/custom-rules).