codaprobe: teste da app viva

O codaprobe testa uma aplicação viva pela rede, só nos alvos que um arquivo de escopo autoriza; ambiguidade no escopo vira recusa.

Antes de qualquer pacote sair, o alvo precisa estar na allowlist do escopo. Por isso este guia começa pela autorização.

Licença. No binário público, o codaprobe exige licença Pro, Verified ou Platform (o Vibe não inclui runtime). Sem ela, sai com código 40 (o 3 é recusa de escopo). check-scope, schema e verify-audit seguem livres. Antes do lançamento nenhuma licença é aceita: o binário público sai com 40 mesmo com token. Ver planos.

1. Autorização e escopo (leia antes de rodar)

O escopo é um JSON que declara quem autorizou e o que está autorizado:

{
  "authorization": {
    "attestation": "pentest autorizado — ticket SEC-4210, aprovado por Maria Silva (CISO) em 2026-07-20",
    "granted": true
  },
  "entries": [
    { "host": "app.cliente.test", "port": 443, "path_prefix": "/api", "mutating_opt_in": false }
  ]
}

Campo desconhecido reprova o carregamento: um erro de digitação não vira permissão. Confira sem tocar a rede:

codaprobe check-scope --scope escopo.json --url https://app.cliente.test/api/

2. Escanear

# passivo — só o tráfego legítimo, nenhum payload (headers, cookies, CORS, vazamentos)
codaprobe scan --scope escopo.json --url https://app.cliente.test/api > laudo.json

# ativo, dirigido pelo contrato (OpenAPI 3 JSON/YAML, coleção Postman ou HAR)
codaprobe scan --scope escopo.json --url https://app.cliente.test/api \
  --contract openapi.yaml --active --auth-file auth.txt --audit-out audit.json > laudo.json

# sem contrato: descobre a superfície por crawl (sem browser)
codaprobe scan --scope escopo.json --url https://app.cliente.test --crawl --active > laudo.json

# GraphQL a partir da introspection
codaprobe scan --scope escopo.json --url https://app.cliente.test/graphql --graphql introspection.json --active

O modo ativo testa query, header, cookie, formulário, segmento de path e o nome do parâmetro. Os payloads são benignos: revelam a falha sem explorá-la. Para falhas sem resposta visível há --temporal; a detecção out-of-band (--oob) vem desligada por padrão.

Flags que mudam o resultado: --rps <n> (cadência total, padrão 5), --concorrencia <n>, --fail-on <sev> (reprova só por finding confirmado), --ca-cert <pem> (prefira a --insecure, que desliga também a checagem de hostname), --correlate-src <envelope> (cruza com o envelope do codafort).

3. O laudo e o registro de auditoria

O laudo é coda-dast/1: findings moment: run, URL redigida (sem userinfo e sem query), o texto da autorização e a âncora do registro de auditoria. O registro (--audit-out) é encadeado por SHA-256 e se confere assim:

codaprobe verify-audit --file audit.json --report laudo.json    # exit 0 INTACT · 21 TAMPERED

Com --report (ou --expect-anchor), o comando confere o registro contra a âncora do laudo e responde INTACT (exit 0) ou TAMPERED (exit 21). Sem eles, o melhor veredito possível é CONSISTENT: quem edita o registro pode recalcular a cadeia, e só a âncora do laudo pega uma remoção com a cadeia refeita. Verifique sempre com o laudo.

4. No pipeline

codaprobe scan --scope escopo.json --url "$ALVO" --contract openapi.yaml --active \
  --auth-file auth.txt --rps 10 --fail-on high --audit-out audit.json > laudo.json

Só finding confirmado reprova o build; candidato não reprova.

O que ele nunca faz

Não relaxa o escopo, o modo não destrutivo nem a redação da URL para achar mais falhas. Não guarda segredo no laudo.