Quem aperta o botão, e onde fica o freio

Publicar a matriz de publicação por ambiente, com ramos que podem publicar, portão humano na fronteira de produção e cada exceção nomeada, justificada e com data de encerramento.

• Separar quem escreve código de quem dispara a publicação, com controle de plataforma e não com combinado verbal.
• Estender a proteção de ramo a todo ramo capaz de publicar, e não apenas ao principal.
• Nomear cada exceção de segurança da esteira, com justificativa e data de encerramento.

Em linguagem simples

Na maior parte das empresas, quem tem permissão de escrever código no repositório tem, pelo mesmo crachá, a capacidade de disparar a esteira que publica em produção com as credenciais da empresa. As duas coisas parecem próximas e são muito diferentes: uma altera um arquivo que ainda passa por revisão, a outra coloca uma versão diante do cliente.

Até junho de 2026 essa separação não existia de forma nativa na plataforma e dependia de combinado verbal. Passou a existir. O padrão continua sendo o antigo, o que significa que a empresa que não configurar nada segue com a lista de quem publica igual à lista de quem escreve.

1. 01Permissão de escrita é permissão de disparo, por padrão. Quem consegue enviar código consegue acionar a esteira que carrega a credencial de produção. Mudar isso é configuração, e configuração que ninguém fez continua no padrão.
2. 02Todo ramo que publica é ramo de produção. Proteção aplicada apenas ao ramo principal deixa aberto qualquer ramo de pré-produção que também dispare publicação. Foi exatamente assim que um projeto conhecido foi comprometido em julho de 2026.
3. 03Referência flutuante entrega mudanças sem aviso. Quando a esteira aponta para uma versão genérica de um componente de terceiro, ela recebe automaticamente o que for publicado ali. Em 20 de julho de 2026 uma mudança de comportamento chegou assim a quem usava esse formato.
4. 04Exceção sem data volta a ser padrão. Toda exceção de segurança precisa de nome, justificativa e data de encerramento. Sem a data, ela envelhece em silêncio e passa a ser tratada como configuração normal.

Confusão mais comum: Achar que revisão obrigatória no ramo principal cobre a publicação. Ela cobre o que entra no ramo principal. Se existe um ramo de pré-produção que também dispara publicação e não tem proteção, a revisão do ramo principal não é atravessada, ela é contornada.

Explique em voz alta: Sustente em uma frase, para o comitê, quantas pessoas conseguem hoje disparar uma publicação em produção da sua empresa, e quantas dessas você nomeia sem consultar lista.

Duas permissões que a empresa trata como uma

A pergunta que abre este módulo costuma provocar silêncio na sala, porque quase todo mundo intui que a resposta é sim e ninguém verificou. Escrever código e publicar em produção são, na configuração padrão da plataforma, a mesma permissão. Quem consegue enviar uma linha para o repositório consegue acionar a esteira que carrega a credencial de produção e coloca uma versão diante do cliente.

Isso não é descuido de ninguém em particular: é o padrão do produto, e até 18 de junho de 2026 não havia alternativa nativa. Nessa data o provedor liberou, em prévia pública, regras que definem quem pode disparar um fluxo de trabalho e quais eventos são permitidos, nos níveis de empresa, organização e repositório. O padrão, porém, continua sendo o antigo. A empresa que não configurar nada permanece com as duas permissões somadas.

A segunda metade do problema é onde a proteção foi aplicada. Muita empresa protege o ramo principal com revisão obrigatória e considera o assunto encerrado. Em 14 de julho de 2026, num projeto com milhões de descargas semanais, os ramos principais estavam protegidos e os ramos de pré-produção não. A publicação maliciosa saiu por um deles, pelo pipeline oficial, doze minutos depois do envio. A regra que sobra desse caso cabe em uma frase: qualquer ramo com permissão de publicar é ramo de produção.

As quatro capacidades que costumam vir somadas

Preencha a coluna do meio com o número real da sua empresa antes da próxima reunião de segurança. A distância entre a segunda e a terceira coluna é o tamanho do problema.

Evidência pública

Caso documentado: o ramo de pré-produção que ninguém protegeu

AsyncAPI, projeto de especificação de APIs

Em 14 de julho de 2026, o atacante obteve permissão de envio em um ramo de pré-produção às 06h58 UTC e o workflow oficial de publicação enviou pacotes maliciosos ao registro às 07h10 UTC. Os ramos principais do projeto tinham proteção e revisão obrigatória. Os ramos de pré-produção que disparavam publicação, não.

• Doze minutos entre o envio ao ramo desprotegido e a publicação no registro.
• Em um segundo repositório do mesmo projeto houve comprometimento do ramo principal entre 08h06 e 08h30 UTC.
• Nenhum token de publicação foi roubado: a publicação usou o pipeline legítimo.
• Os quatro pacotes afetados somavam mais de 2,9 milhões de descargas semanais.

O inventário que importa é o de ramos que disparam publicação. Qualquer ramo dessa segunda lista que não esteja na primeira é uma porta aberta com aparência de porta interna.

O mesmo incidente aparece no módulo 14 sob outro ângulo, o da dependência publicada. Aqui interessa o controle de acesso ao ramo que dispara a publicação.

Modelo operacional

A matriz de publicação, coluna a coluna

Uma linha por ambiente: desenvolvimento, homologação e produção. As colunas não mudam. O documento cabe em uma página e é a primeira coisa que um auditor pede quando pergunta como a empresa controla mudanças em produção.

• Quem escreve: Quem tem permissão de enviar código ao repositório. Deve ser amplo, porque restringir aqui atrapalha o trabalho sem reduzir risco relevante. Exemplo: Time de engenharia inteiro, incluindo prestadores, com revisão de acessos a cada trimestre e saída imediata no desligamento.
• Quem revisa: Quem aprova a entrada do código no ramo. Pelo menos uma pessoa independente de quem escreveu, com a regra valendo em todo ramo que dispara publicação. Exemplo: Revisão obrigatória aplicada aos três ramos que disparam esteira, e não apenas ao principal.
• Quem dispara: Quem pode acionar o fluxo de trabalho que carrega a credencial de produção. Grupo pequeno, nomeado e revisado, separado por configuração de plataforma e não por combinado verbal. Exemplo: Regras de ator e de evento, disponíveis em prévia pública desde 18/06/2026 nos níveis de empresa, organização e repositório.
• Quem aprova a ida para produção: O portão humano com segundo fator definido no módulo anterior. Dois nomes com suplente, evidência obrigatória na tela e prazo máximo de espera declarado. Exemplo: Ambiente protegido com revisores obrigatórios, com os segredos de produção existindo apenas nesse ambiente.
• Quais ramos podem publicar: A lista completa, incluindo os ramos antigos que ninguém lembra que ainda disparam a esteira. Todo item desta lista precisa ter proteção equivalente à do ramo principal. Exemplo: O levantamento da Nortis encontrou três ramos, e o terceiro era um ramo de correção emergencial esquecido desde 2025.
• Exceções nomeadas: Cada desvio da matriz recebe nome de quem solicitou, motivo escrito, aprovador e data de encerramento no calendário. Exceção sem data volta silenciosamente a ser padrão. Exemplo: A configuração que permite buscar código de bifurcação em fluxo disparado por evento não confiável é exceção, e não configuração de rotina.

A matriz não impede que uma das pessoas autorizadas tenha a conta comprometida. Ela reduz o número de contas cujo comprometimento publica em produção, o que é diferente e mensurável.

Guardrail

O que quebrou sozinho em 20 de julho de 2026, e por quê

Em 18 de junho de 2026 o provedor publicou uma versão maior do componente de busca de código que passa a recusar, por padrão, buscar código de pedido de alteração vindo de bifurcação em fluxos disparados por eventos não confiáveis. Em 20 de julho de 2026 a mesma mudança foi retroportada como alteração incompatível para todas as versões maiores suportadas. Quem apontava para o apelido genérico da versão recebeu a mudança automaticamente, e alguns pipelines pararam de funcionar sem que ninguém tivesse tocado no repositório. A leitura correta desse evento é positiva: se o pipeline quebrou, ele estava vulnerável.

• As referências a componentes de terceiro na esteira estão fixadas em versão exata e imutável, e a atualização passa por revisão como qualquer dependência.
• Nenhum fluxo de trabalho usa a configuração de contorno que permite buscar código de bifurcação em evento não confiável; onde usar, existe exceção nominal com prazo.
• Existe a lista completa dos ramos que disparam publicação, e cada um tem proteção equivalente à do ramo principal.
• As permissões de cada fluxo de trabalho são declaradas de forma explícita e mínimas, em vez de herdadas do padrão do repositório.
• Os segredos de produção existem apenas no ambiente que exige aprovação, e não no nível do repositório.
• A versão do ambiente de execução usada na esteira não é a que será removida da máquina de construção em 16 de setembro de 2026; o calendário de obsolescência do módulo 11 governa essa data.

Conexão com o portal

Do fluxo de trabalho de código para o controle de mudança: aprovar não é revisar

Revisão de código verifica se a mudança está correta. Proteção de ramo impede que a mudança entre sem revisão. As duas atuam sobre o que entra no repositório, e nenhuma das duas atua sobre o que sai para o cliente.

Tradução executiva: Quando o time apresenta revisão obrigatória como controle de produção, a pergunta a fazer é qual ramo essa regra protege e quantos ramos disparam publicação. É comum que a resposta seja um e três. A diferença entre esses dois números é o tamanho do controle que a empresa acha que tem e não tem.

Use quando: alguém responder que a publicação é segura porque todo código passa por revisão obrigatória.

Fronteira: Mesmo com todos os ramos protegidos, a revisão não detecta artefato comprometido que nasce depois dela, no momento da construção. É por isso que a matriz de publicação anda junto com a política de dependências e com o portão humano, e não no lugar deles.

GitHub na prática

Guia prático · Guia de marketing 8 · Teste A/B e freio

Rode o teste A/B da landing com flag, e desligue a variante sem publicar

Caso de uso: Otimização de conversão · duas versões do título e do formulário

No fim deste guia a landing serve duas variantes divididas por percentual, a divisão real é conferida no painel, a conversão de cada variante é medida, e qualquer pessoa autorizada desliga a variante perdedora sem nova publicação.

Onde fica: Vercel: projeto > Flags para criar a flag e as regras; Storage > Global Config para valores lidos a cada requisição; Analytics para a conversão por variante.

Critério de pronto e como medir

• Critério de pronto: proporção servida conferida no painel de avaliações, evento de conversão chegando com a variante, e o desligamento ensaiado uma vez na prévia.
• Conversão por variante com o número mínimo de conversões definido antes do início, comparada só depois do prazo combinado.

Caso Nortis · Semana 10, sexta-feira

A lista de quem consegue disparar a publicação é idêntica à lista de quem tem permissão de escrita no repositório: dezenove pessoas, incluindo dois estagiários e um prestador.

A proteção de ramo foi aplicada só no ramo principal. Os ramos de pré-produção, que também disparam publicação, estão desprotegidos, exatamente o padrão que derrubou um projeto conhecido em 14 de julho de 2026.

Publicar a matriz de publicação: quem escreve, quem revisa, quem dispara, quem aprova e quais ramos podem publicar, com cada exceção nomeada, justificada e com data de encerramento.

Exemplo trabalhado

Dezenove pessoas, dois estagiários e um prestador

CISO da Nortis, montando a matriz de publicação para o comitê

A pergunta feita ao time foi quem consegue disparar uma publicação em produção. A resposta veio como uma lista de dezenove nomes, que era exatamente a lista de quem tinha permissão de escrita no repositório, incluindo dois estagiários e um prestador de serviço contratado por três meses.

Resultado: A matriz sai com quatro colunas preenchidas, três ramos identificados e protegidos, referências fixadas e duas exceções com prazo. A lista de quem publica cai de dezenove para seis, e o prestador sai dela no mesmo dia.

Continua sob responsabilidade humana: A matriz reduz o número de pessoas com poder de publicar e não impede que uma dessas seis tenha a conta comprometida. É por isso que ela anda junto com o portão humano com segundo fator do módulo anterior e com o inventário de credenciais do módulo 13. Cada um cobre uma parte, e a política precisa deixar visível qual parte cada controle cobre.

Laboratório de decisão

Restringir quem dispara vai atrasar o time, diz o líder de engenharia

A proposta de separar quem escreve de quem dispara chega ao comitê com objeção do líder de engenharia: seis pessoas com poder de disparo significa fila quando duas estiverem de férias, e o time entrega em ritmo alto justamente porque não há intermediário.

Como reduzir o número de contas com poder de publicação sem transformar a esteira em fila de espera?

• A. Manter as dezenove pessoas, aceitando o risco em nome da velocidade de entrega.: Preserva o ritmo e mantém dezenove contas cujo comprometimento publica em produção, incluindo dois estagiários e um prestador com contrato de três meses. É uma escolha defensável apenas se for escrita, datada e assinada por quem responde pelo risco.
• B. Reduzir para duas pessoas, o mínimo absoluto, e centralizar toda publicação nelas.: Reduz muito a superfície e cria gargalo real, com o efeito colateral previsível: em duas semanas alguém compartilha credencial para destravar uma urgência, e o controle formal passa a divergir do controle efetivo.
• C. Reduzir a um grupo nomeado de seis, com revisão trimestral, mantendo a publicação automática e colocando o portão humano apenas na fronteira de produção.: Preserva a automação até a fronteira, onde o atraso é medido em minutos, e reduz de dezenove para seis o número de contas cujo comprometimento chega à produção. Exige prazo máximo de espera declarado e suplente, sem os quais a objeção do líder de engenharia se confirma.

Recomendação: A terceira opção, com prazo máximo de espera declarado, suplente designado e revisão trimestral da lista.

A objeção do líder de engenharia é legítima e merece ser tratada como requisito, não como resistência. Velocidade de entrega é métrica de negócio, e um controle de segurança que a destrói será contornado, formalmente ou não. A saída está em colocar o freio no ponto em que ele custa minutos, que é a fronteira de produção, e não em cada ação do dia a dia. Reduzir de dezenove para seis não introduz nenhuma espera no fluxo normal de trabalho: apenas retira a capacidade de publicar de quem nunca precisou dela. O prazo máximo e o suplente são a parte que responde diretamente à objeção, e sem eles a proposta merece a crítica que recebeu.

• Eu sei quantas contas, se comprometidas hoje, publicam em produção da minha empresa sem passar por mais ninguém.
• Eu tenho a lista completa dos ramos que disparam publicação, e todos têm proteção equivalente à do ramo principal.
• Eu tenho cada exceção de segurança da esteira com nome, justificativa e data de encerramento no calendário.

Com o acesso sob controle, sobra o cenário que nenhum controle evita: a queda.