PR Diff Red-Team Gate
O fluxo completo que roda quando um pull request encosta em um artefato de prompt observado. A GitHub App recebe o webhook pull_request, parseia o .doesitdefend.yml do repo, deriva as categorias OWASP que o diff de fato toca, roda uma execução com escopo do diff, compara contra a baseline mais recente no mesmo alvo (dentro do TTL de 30 dias) e devolve check run + comentário idempotente no PR. O concept de CI Integration trata da ferramenta (CLI + Action); este concept trata do fluxo.
O PR Diff Red-Team Gate é o fluxo completo por trás do check que o time vê no pull request: webhook de entrada, diff interpretado, categorias derivadas, scan executado, referência comparada, veredito publicado.
Ele é distinto do concept de ferramenta (CLI e Action): aquela página descreve o que você instala; esta descreve o que acontece quando o fluxo roda.
Pontos-chave
- Escopo do diff: só rodam as categorias OWASP cujos probes encostam nos arquivos mudados. PR só de README dispara zero minutos de scan.
- Consciente de baseline: regressões são computadas contra a execução anterior no mesmo alvo. Alvo novo recebe `no_baseline` (informativo, nunca bloqueia).
- Idempotente: amend / force-push reescreve o check run + comentário em vez de empilhar.
- Schema com padrão: `llm_config.scenarios` cai pras 10 categorias OWASP quando omitido, então o manifest fica enxuto.
Modos de veredito
- regression (padrão): falha o build só quando o score de postura cai além de um limiar material (configurável; ±5 pontos por padrão).
- findings: falha o build sempre que qualquer achado novo aparece, independente da comparação de baseline.
- never: modo consultivo; check sempre passa, comentário carrega o veredito pra revisão.
Os modos de veredito existem porque os times diferem em como um gate deve falhar. No modo consultivo o check fica sempre verde e o comentário carrega o veredito; nos modos de bloqueio, ele impede. Em ambos, o comentário — não o ícone do check — é onde vive o raciocínio.
O que o PR vê
- Check Run do GitHub no head commit com título de uma linha e summary em markdown.
- Comentário no PR com as categorias OWASP selecionadas pelo diff, evidência por achado e, em uma execução elegível do Starter+, link para o pacote completo de evidências.
- Se o gate dá erro (manifest inválido, alvo inacessível, timeout), o check run fica em `neutral` pra não emperrar o build.
Quando o gate não consegue rodar — manifesto inválido, alvo inacessível, timeout — o check run registra o erro em vez de inventar um passe. Um gate ilegível é um controle quebrado; um gate que falha com motivo é um controle funcionando.
Recursos relacionados