> ## 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.

# Testes Dinâmicos (DAST)

> Use testes dinâmicos para descobrir vulnerabilidades em aplicações em execução, confirmar a explorabilidade em tempo de execução e verificar correções após o merge

Testes Dinâmicos é a capacidade de Dynamic Application Security Testing (DAST) do ZeroPath para aplicações em execução. Ela pode ser empregada de três formas: descobrir vulnerabilidades em aplicações ao vivo, confirmar quais descobertas estáticas são exploráveis em tempo de execução e verificar que as correções resolvem o problema após o merge.

<Info>
  O dashboard usa **Runtime Validation** para o fluxo de DAST específico por
  issue: rotas, abas, páginas de execução e seções de evidência das issues ainda usam esse
  nome. Runtime Validation é um dos modos dos Testes Dinâmicos do ZeroPath.
</Info>

<h2 id="what-it-does">
  O Que Ele Faz
</h2>

Os Testes Dinâmicos exercitam um alvo em execução configurado com o contexto da descoberta, os inputs do perfil da aplicação, credenciais de runtime criptografadas e, quando necessário, um artefato compilado da aplicação local. O objetivo é produzir evidências a partir da aplicação ao vivo, em vez de depender apenas da análise estática.

| Modo                      | Caso de uso                                                                                                                                       |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Descoberta ao vivo**    | Execute testes dinâmicos contra APIs de produção ou staging para encontrar vulnerabilidades exclusivas de runtime, como injeção de prompt e IDOR. |
| **Runtime validation**    | Parta de uma descoberta SAST concluída e confirme, refute ou explique a explorabilidade contra a aplicação implantada.                            |
| **Verificação pós-merge** | Reutilize o perfil dinâmico depois que um patch é aplicado para verificar que o comportamento vulnerável não se reproduz mais.                    |

Os resultados de runtime validation usam estes veredictos:

| Resultado        | Significado                                                                                                                                                         |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Queued**       | A issue faz parte da execução, mas ainda não chegou a um veredicto final.                                                                                           |
| **Confirmed**    | O ZeroPath observou evidência em tempo de execução de que a issue é explorável.                                                                                     |
| **Disconfirmed** | O ZeroPath não conseguiu explorar a issue no ambiente de runtime configurado.                                                                                       |
| **Unable**       | A validação não conseguiu chegar a um veredicto confiável, por exemplo quando o estado de runtime necessário estava indisponível ou a aplicação estava inacessível. |

Descobertas com veredicto Disconfirmed podem ser movidas para o fluxo de falso positivo com evidência de runtime explicando por que a issue não se reproduziu.

<h2 id="vulnerability-classes">
  Classes de Vulnerabilidade
</h2>

Os testes dinâmicos podem visar comportamentos de runtime que são difíceis de provar apenas a partir do código-fonte:

* **Injeção de prompt** - testa se funcionalidades com IA executam instruções injetadas, manipulando inputs em prompts voltados ao usuário e de backend. As descobertas mostram o caminho da injeção e a resposta do modelo.
* **IDOR** - exercita identificadores de objetos entre papéis autenticados para provar quando usuários conseguem acessar recursos que não lhes pertencem.
* **Encadeamento de vulnerabilidades** - combina múltiplos comportamentos de runtime para mostrar como fraquezas menores se tornam um caminho de ataque prático.
* **Vulnerabilidades out-of-band (OOB)** - detecta SSRF cego, XXE cego, injeção de SQL cega, exfiltração via DNS e outras vulnerabilidades em que o comportamento explorado não é visível na resposta HTTP. O agente de validação gera URLs de callback únicas em `oob.0path.ai` e monitora requisições de saída da aplicação-alvo, provando que o payload injetado disparou uma requisição real do lado do servidor.

<h3 id="out-of-band-testing-and-network-requirements">
  Testes Out-of-Band e Requisitos de Rede
</h3>

Os testes OOB usam `oob.0path.ai` como servidor de callback padrão. O agente de validação injeta URLs únicas sob esse domínio na aplicação-alvo e monitora lookups de DNS, requisições HTTP e outras interações de protocolo que provam que a vulnerabilidade é explorável.

Se a sua aplicação-alvo roda atrás de um firewall ou de um filtro de saída, pode ser necessário adicionar `*.oob.0path.ai` (DNS e HTTPS) à lista de permissões para que o alvo consiga alcançar o servidor de callback. Sem isso, os testes OOB não retornarão interações mesmo quando a vulnerabilidade for real.

<h2 id="prerequisites">
  Pré-requisitos
</h2>

Os Testes Dinâmicos exigem:

* Uma aplicação implantada alcançável pelo worker de validação, ou um artefato compilado da aplicação local enviado no painel de configuração da Runtime Validation.
* Um perfil de aplicação de Runtime Validation para a aplicação detectada.
* Todos os inputs obrigatórios do perfil salvos, como a URL do alvo e os campos de autenticação gerados.
* Para validação específica por issue, um full scan concluído com descobertas SAST elegíveis.

Os campos de input gerados são representados como campos estruturados no dashboard, e não como um único blob JSON. Os valores são criptografados antes de serem armazenados, e verificações de prontidão impedem que a validação comece até que os inputs obrigatórios estejam presentes.

A validação com artefato local atualmente suporta artefatos compilados para Linux x86\_64/amd64 empacotados como `.zip`, `.tar`, `.tar.gz` ou `.tgz`. O artefato é executado dentro do contêiner gVisor de Runtime Validation do ZeroPath, baseado em Debian; outros sistemas operacionais e arquiteturas de CPU não são suportados.

<h2 id="running-runtime-validation">
  Executando a Runtime Validation
</h2>

<Tabs>
  <Tab title="Aplicação Completa">
    Use uma execução de aplicação completa quando quiser validar todas as issues elegíveis de um perfil de aplicação.

    <Steps>
      <Step title="Abra o repositório">
        Acesse o repositório no ZeroPath e selecione a aba **Runtime Validation**.
      </Step>

      <Step title="Selecione um perfil de aplicação">
        Escolha a aplicação e o escaneamento que você deseja validar.
      </Step>

      <Step title="Confirme a prontidão">
        Preencha os inputs do perfil que estiverem faltando até que o perfil esteja pronto. Para aplicações locais, envie o artefato compilado para Linux x86\_64/amd64 na seção **Local artifact**.
      </Step>

      <Step title="Inicie a execução">
        Escolha **Full application** e inicie a validação. A execução aparece na lista de execuções abaixo do painel de configuração.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Issue Selecionada">
    Use uma execução de issue selecionada quando você só precisa de prova para uma descoberta.

    <Steps>
      <Step title="Abra uma issue">
        Abra o modal da issue ou a visão completa da issue a partir da aba **Issues** do repositório.
      </Step>

      <Step title="Verifique a Runtime Validation">
        Se a issue pertence a um perfil de aplicação configurado, o controle de Runtime Validation aparece abaixo da área do passo a passo do exploit.
      </Step>

      <Step title="Inicie a validação">
        Inicie a validação para essa issue. O ZeroPath cria uma execução de issue selecionada e vincula de volta à página de detalhes da execução.
      </Step>
    </Steps>

    Você também pode iniciar uma execução de issue selecionada a partir da aba **Runtime Validation** do repositório, escolhendo **Selected issue** e selecionando uma descoberta elegível.
  </Tab>
</Tabs>

<h2 id="reviewing-results">
  Revisando os Resultados
</h2>

A aba Runtime Validation do repositório mostra as execuções de validação recentes. Selecionar uma execução abre uma página dedicada com abas de resultados:

* **Queued** - issues que ainda aguardam a validação em tempo de execução.
* **Confirmed** - issues comprovadamente exploráveis em tempo de execução.
* **Disconfirmed** - issues que não se reproduziram no ambiente de runtime configurado.
* **Unable** - issues em que a validação não conseguiu produzir um veredicto confiável.

Clicar em uma issue a partir de qualquer aba de resultados abre a visão padrão de issues do ZeroPath, de modo que a descoberta estática, o passo a passo do exploit, a orientação de remediação e a evidência de runtime podem ser revisados em conjunto.

<h2 id="issue-level-evidence">
  Evidência em Nível de Issue
</h2>

Quando uma descoberta tem saída de Runtime Validation, o modal da issue e a visão completa da issue incluem uma seção de Runtime Validation recolhida abaixo do passo a passo do exploit. Ela resume:

* O veredicto mais recente e o status da execução.
* O que o ZeroPath tentou durante os testes em tempo de execução.
* As evidências observadas durante a tentativa.
* Por que a descoberta foi confirmada, refutada ou marcada como unable.
* Um link para a página dedicada da execução, para um contexto mais amplo.

A seção fica recolhida por padrão para que a visão da issue permaneça legível para usuários que só precisam dos detalhes da descoberta original.

<h3 id="structured-validation-data-in-the-api">
  Dados de Validação Estruturados na API
</h3>

As respostas da API de detalhes da issue e de runtime validation incluem dois campos estruturados que fornecem uma visão legível por máquina do que o agente de validação fez:

* **`validationSteps`** — uma lista ordenada de objetos, um por ação executada pelo agente. Cada objeto contém:
  * `target` — o endpoint, workflow, objeto ou caminho de código exercitado (pode ser nulo).
  * `action` — a ação concreta executada.
  * `expectedResult` — o comportamento seguro esperado ou o sinal de exploit para esse passo (pode ser nulo).
  * `observedResult` — o que o agente de fato observou em tempo de execução.
  * `conclusion` — por que essa observação importa para o veredicto.
* **`attackReproductionSteps`** — apenas para descobertas confirmadas, uma lista ordenada de passos em linguagem natural que reproduzem o ataque confirmado. Adequada para inclusão em um relatório de bug ou em um ticket de remediação.

Ambos os campos são retornados como arrays e estão sempre presentes (vazios quando não aplicáveis). O campo `agentGroupKey`, anteriormente disponível, foi removido da resposta da API.

<h2 id="operational-notes">
  Notas Operacionais
</h2>

* Execuções de aplicação completa são bloqueadas enquanto existir outra execução ativa para o mesmo escaneamento e perfil de aplicação.
* Execuções de issue selecionada são bloqueadas apenas quando uma execução de aplicação completa está ativa ou quando outra execução ativa de issue selecionada já visa a mesma descoberta.
* Os Testes Dinâmicos dependem do alvo implantado configurado, portanto uma falha em alcançar a aplicação deve ser tratada como um problema de ambiente ou de perfil antes de considerar a descoberta como refutada.
* Para repositórios com muitos escaneamentos, use a lista de execuções e as abas de resultados em vez de examinar issue por issue na tabela principal de issues.

<h2 id="related-pages">
  Páginas Relacionadas
</h2>

* [Visão Geral do SAST](/pt/scanning/sast-overview)
* [Configurações do Scanner](/pt/platform/scanner-settings)
* [Auto-Fix e Patches](/pt/scanning/auto-fix)