Governança que Você Não Consegue Rastrear Não é Governança

Apenas 12% dos pull requests que implementam uma decisão de segurança têm ligação com o threat model que produziu essa decisão. A Dropbox mediu isso no próprio código e publicou o número em junho de 2026. Nos outros 88% das vezes, um requisito de segurança foi acordado numa revisão de design, e o código que deveria atendê-lo foi para produção sem nenhuma conexão rastreável com o que ficou combinado.

Esse é o estado da governança numa empresa com função de segurança madura, processo de revisão documentado e engenheiros que se importam. A revisão aconteceu. A decisão foi tomada. A verificação de que o código respeitou a decisão não aconteceu, porque ninguém conseguia achar o código que deveria respeitá-la.

O número por trás do número

Os 12% são a manchete, mas os dados de tempo embaixo deles explicam por que a ligação se rompe.

A Dropbox olhou para quando os pull requests de implementação de fato abrem em relação à revisão de segurança que os governa. Só 29% abrem dentro de duas semanas da revisão. A mediana fica perto de cinco semanas. Mais da metade (54%) abre mais de um mês depois da revisão, e a cauda se estende para além de onze meses. Cerca de 15% das revisões foram registradas de forma retroativa, escritas depois que o código já existia.

Leia esses números juntos e o modo de falha fica óbvio. Uma revisão de design produz um conjunto de requisitos de segurança. Semanas passam. Quem escreve a implementação muitas vezes não é quem sentou na revisão. Quando o código chega, o threat model é um documento que alguém escreveu um mês atrás, em outra ferramenta, sem amarração mecânica nenhuma com o diff em revisão. Quem aprova o pull request está revisando o código. Não está revisando o código contra o design, porque o design não está na frente dele.

Essa é a distinção que importa. “Revisar o código” e “revisar a implementação contra o design” são atividades diferentes. A primeira checa se o código está correto nos próprios termos. A segunda checa se o código faz o que a organização decidiu que ele deveria fazer. A maioria dos processos de revisão executa a primeira e assume em silêncio que ela cobre a segunda. Não cobre.

Por que a ligação some

A conexão entre uma decisão de design e sua implementação é frágil por uma razão que não tem nada a ver com disciplina. É um problema de ferramenta.

Revisões de design moram num sistema: um doc, um wiki, um ticket. O código mora em outro: o repositório, o pull request, o diff. Os dois sistemas não sabem um do outro. A única coisa que os conecta é um humano lembrar de colar um link, e humanos esquecem, ainda mais cinco semanas depois. A Dropbox confirmou o quanto a ligação explícita é fraca quando tentou reconstruir as conexões depois do fato.

Aqui está a parte que vale demorar. Quando a Dropbox usou busca semântica entre docs de design e código para recuperar as ligações perdidas, conectou 80% de 150 revisões de design ao código que as implementava. Dessas ligações recuperadas, 69% só eram encontráveis por busca semântica. Não tinham referência explícita nenhuma. Nenhuma URL colada, nenhum número de ticket, nenhuma menção. A relação existia no trabalho e era invisível nos metadados.

Então o problema de cobertura não é que o trabalho foi desleixado. O trabalho aconteceu. A implementação correspondia ao design mais vezes do que as ligações explícitas sugeriam. O que faltava era qualquer registro rastreável conectando os dois, o que significa que não havia como auditar se o design foi respeitado sem um humano caçar o código manualmente meses depois. Governança que depende de um humano lembrar de colar um link é governança que falha 88% das vezes.

Governança como produto, não como checklist

A correção que a Dropbox construiu é a parte interessante, e ela generaliza bem para muito além de segurança.

Eles amarraram revisões de design e código com MCP e busca semântica, de modo que um agente consegue pegar uma revisão de segurança, ir achar os pull requests que a implementam e checar se a implementação de fato atende aos requisitos que a revisão especificou. A metodologia não foi uma demo de uma tacada só. Eles validaram contra 79 pares verificados de design para código e depois rodaram em 150 revisões ao longo de 18 meses. O auto-link é o substrato. A checagem de alinhamento é o produto.

Isso reposiciona para que serve uma ferramenta de governança. O modelo tradicional trata governança como portão: uma revisão acontece, uma caixa é marcada, o trabalho segue. A caixa diz que a revisão ocorreu. Não diz nada sobre se o código mesclado corresponde ao que a revisão decidiu. Essa segunda pergunta é a que de fato te protege, e é a que nenhum checklist responde.

Construir governança como produto significa que o sistema responde continuamente “a implementação corresponde ao design” em vez de “houve uma revisão”. O agente faz a ligação que os humanos esquecem. O agente lê o threat model e o diff juntos e sinaliza onde eles divergem. A atenção de quem revisa migra de redescobrir contexto para julgar alinhamento. Esse é um uso melhor de um engenheiro sênior do que arqueologia.

Audite cobertura, não taxa de aprovação

A métrica que a maioria das funções de segurança e governança reporta é uma taxa de aprovação: que porcentagem das revisões foi aprovada, que porcentagem dos pull requests passou na checagem. Os dados da Dropbox expõem por que essa métrica mente. Uma taxa de aprovação de 100% nas revisões que acontecem não te diz nada se só 12% do código de implementação é rastreável até alguma revisão. A taxa de aprovação mede o trabalho que você consegue ver. Cobertura mede o trabalho que você não consegue.

Cobertura é o número mais difícil e o mais honesto. Ele pergunta: de todas as decisões de segurança que tomamos, que fração conseguimos rastrear até o código que deveria implementá-las, e verificar que ele implementou? Um time que reporta 95% de aprovação e 12% de rastreabilidade está descrevendo um problema bem maior que papelada: ele desconhece o que 88% do próprio código faz em relação às próprias decisões de segurança.

Se você toca uma função de governança, segurança ou plataforma, esta é a auditoria para rodar neste trimestre. Pegue uma amostra representativa das suas revisões de design ou de segurança do último ano. Para cada uma, tente achar o código que a implementa e confirmar que o código respeita a decisão. Meça a porcentagem em que você consegue fazer as duas coisas. Esse número é a sua cobertura real, e ele vai ser menor que a sua taxa de aprovação. Depois decida se você quer um humano continuar fazendo essa arqueologia ou se você quer amarrar design à implementação para que um agente faça isso a cada merge. A Dropbox já mostrou que a segunda opção funciona.

Se você não consegue rastrear da decisão até o código mesclado, o que você tem é o registro de que uma reunião aconteceu. Chamar isso de governança é otimismo.

Fontes

Dropbox Tech. “How Dropbox uses MCP + Dash for design and code security review.” Junho de 2026.

A Victorino ajuda equipes a tornar a governança rastreável da revisão de design até o código mesclado: contato@victorino.com.br | www.victorino.com.br