Do corpus à prova EN

Curso / Aula 3 de 6

18 min · caso real sanitizado

Gates de prova e cobertura total

Objetivo: Projetar um gate de prova que cobre tudo — porque um gate parcial não é uma defesa mais fraca, é um convite ao bypass.

Primeiro, em linguagem simples

Um gate de prova é uma porta que só abre quando cada unidade de trabalho apresenta uma prova executada de verdade. Se a porta vigia 99% das unidades, o 1% restante não fica “menos protegido” — ele se torna o caminho preferido de qualquer trabalho que queira passar sem prova, por acidente ou por construção.

A disciplina da missão real foi adversarial: atacar o próprio gate, consertar o mínimo possível e atacar de novo. Foram necessárias sete rodadas. O gate só fechou quando uma bateria de treze ataques conhecidos passou 13/13 — com um Validator que não tinha autoria no código atacado.

Abra a camada técnica

As sete rodadas (cada uma: ataque → reparo mínimo → re-ataque):

RodadaBypass encontradoReparo mínimo
1Unidades sem carimbo de id ficavam invisíveis ao gate.Carimbar toda task; executável sem tag vira unidade própria, marcada para revisão.
2Metadata falsificável: kind:'proof' espúrio escondia trabalho; colisão de id dava carona na prova alheia.Exclusão só por forma completa (kind + id + índice de prova); colisão de id falha fechado.
3Comando escondido na tag de uma unidade já comprovada.Dentro de unidade tagueada, todo comando exige forma de prova completa.
4Subtarefas de coordenação executavam comandos invisíveis num sub-run filho (cobertura plana).Toda folha com comando deve ser prova completa, senão erro.
5Jurisdição desalinhada: o gate só olhava o topo; folha de prova falha convergia.O gate achata subtarefas; folha falha ou não registrada derruba o gate.
6Folha fantasma: kind interno sem comando convergia.Folha de instrumento fantasma vira erro.
7Bateria “greatest hits”: todos os ataques anteriores juntos.13/13; cobertura total de comandos; residuais documentados, não escondidos.

Lição estrutural: nenhum reparo “melhorou o código”; cada um fechou exatamente o bypass demonstrado e foi imediatamente re-atacado. Baseline do repositório verde o tempo todo — o adversário aqui é a lógica do gate, não o compilador.

Simulação determinística · pseudo-configurações sintéticas

Encontre o bypass

Cada cartão mostra uma configuração que passaria num gate ingênuo. Escolha onde está o bypass.

Config 1

tasks: [ { kind:'work', command:'build A' } ] gate: para cada unitId conhecido, exigir prova

Config 2

tasks: [ { id:'u7', kind:'proof', note:'verificado' }, { id:'u7', kind:'work', command:'deploy' } ]

Config 3

unit u3: prova ✓ (build + teste) tasks: [ { unitId:'u3', command:'publish extras' } ]

Config 4

task LEAD (coordenação) └─ sub-run filho: [ { kind:'work', command:'migrate' } ] gate: só olha o nível top

Config 5

tasks: [ { kind:'instrument', note:'observado' } ] gate: sem falhas registradas → converge

0 de 5 bypasses encontrados.