O segredo de vida longa que ainda não tem substituto

Montar o inventário das credenciais que publicam em produção, com dono nomeado, escopo mínimo, calendário de rotação e revogação já testada com tempo medido.

• Separar o que a federação de identidade já resolve neste stack do que ela ainda não resolve.
• Atribuir dono, escopo e prazo de rotação a cada credencial capaz de publicar em nosso nome.
• Exigir procedimento de revogação testado, com o tempo cronometrado antes do próximo incidente.

Em linguagem simples

Para publicar automaticamente, a esteira precisa provar ao fornecedor que é a sua empresa. Essa prova é uma credencial: um texto longo, guardado em cofre, que o robô apresenta a cada publicação. Quem tiver esse texto publica em nome da empresa, de qualquer lugar do mundo, sem passar por ninguém.

O mercado passou os últimos anos migrando para credenciais de curta duração, que nascem no momento do uso e morrem em uma hora. É melhor por um motivo simples: um texto roubado hoje não serve amanhã. O detalhe incômodo é que, para publicar nestes dois fornecedores específicos, esse caminho não existe até 24 de julho de 2026. A credencial continua sendo de vida longa, e a empresa precisa decidir o que coloca no lugar da proteção que falta.

1. 01A credencial vale por si, sem senha e sem segundo fator. Ela não pergunta quem está do outro lado. Quem apresenta, publica. É por isso que o cofre onde ela mora importa menos do que a lista de tudo que roda ao lado dela.
2. 02Escopo é a diferença entre um incidente e uma crise. Credencial de conta inteira publica em todos os projetos. Credencial por projeto limita o estrago ao projeto comprometido. O escopo se escolhe no momento da criação e quase nunca é revisitado.
3. 03Vida longa exige calendário, não boa vontade. Sem data de rotação escrita e dono nomeado, a credencial fica ativa até alguém lembrar dela, normalmente durante a apuração de um incidente.
4. 04Revogar é o controle que precisa ser cronometrado. O valor de um plano de revogação é o tempo que ele leva na prática, medido em ensaio, e não a existência do parágrafo no documento.

Confusão mais comum: Confundir o local onde o segredo mora com a proteção do segredo. Guardar o token em um cofre de qualidade não impede nada se o processo que lê o cofre executa, no mesmo instante, código de centenas de autores desconhecidos. Nos ataques de maio e de julho de 2026 nenhum cofre foi arrombado: a credencial foi lida da memória do processo que a estava usando.

Explique em voz alta: Responda ao seu CFO, sem consultar o time, o que exatamente uma pessoa consegue fazer com o token de publicação da sua empresa se ele vazar hoje às 18h, e quanto tempo levaria até esse poder acabar.

A boa prática do mercado, e a exceção que alcança justamente a sua esteira

Qualquer material de segurança escrito depois de 2024 diz a mesma coisa: elimine segredo de vida longa, troque por identidade federada, faça a credencial nascer no momento do uso e morrer em minutos. A recomendação é boa e tem histórico de resultado. Ela simplesmente não descreve o caso de quem publica na Vercel ou na Cloudflare a partir do GitHub Actions.

Verificado em 24 de julho de 2026, não existe autenticação federada para deploy em nenhuma das duas plataformas. A documentação de federação de identidade da Vercel, atualizada em 16 de junho de 2026, trata do movimento oposto: a aplicação já em produção recebe uma prova de identidade e a troca por credencial temporária na AWS, no Google Cloud ou no Azure, com validade de 60 minutos e cache de até 45 minutos. Isso protege o acesso da aplicação a um banco de dados, e não protege o ato de publicar. Na Cloudflare, a documentação oficial da ferramenta de linha de comando continua exigindo token de conta e identificador de conta em ambiente de integração contínua, e o pedido de federação segue como discussão aberta no repositório do próprio fornecedor.

Há um avanço parcial que vale registrar sem exagerar seu alcance. Em 13 de maio de 2026 a Vercel lançou o Trusted Sources, que aceita uma prova de identidade curta no lugar do segredo de vida longa usado para contornar a proteção de ambientes de prévia. É um segredo a menos na lista. O segredo que publica em produção continua lá.

A consequência prática é desconfortável e precisa ser dita em comitê exatamente assim: o controle recomendado pelo mercado não está disponível para nós neste ponto, então assumimos controle compensatório, com nome, prazo e data de reavaliação. Registrar a exceção é o que separa uma decisão consciente de uma omissão que ninguém percebeu.

O que já tem credencial curta neste stack e o que ainda não tem

Tabela verificada em 24 de julho de 2026 na documentação primária de cada fornecedor. A coluna da direita é a única que importa para a decisão: onde a resposta é não, o controle precisa ser compensatório e precisa estar escrito.

Modelo operacional

Os seis controles compensatórios que substituem o que não existe

Nenhum deles é novo nem caro. O que costuma faltar é o nome de uma pessoa ao lado de cada um e uma data no calendário. Onde o controle recomendado não está disponível, o comitê aprova estes seis por escrito e registra que são compensatórios.

• Escopo mínimo por projeto: Uma credencial por projeto, com o menor alcance que a publicação exigir. Credencial de conta inteira só existe onde alguém provar que não há alternativa, e essa prova vira exceção nomeada com prazo. Exemplo: O projeto de marketing e o produto que fatura deixam de compartilhar a mesma credencial, então um vazamento no primeiro não publica no segundo.
• Dono nomeado, nunca uma equipe: Equipe não responde por credencial. Pessoa responde. O dono é quem aprova a criação, quem executa a rotação e quem é acordado se o alerta disparar às três da manhã. Exemplo: Nome, papel e suplente escritos na mesma linha do inventário, com a data em que a atribuição foi feita.
• Calendário de rotação com data futura: Rotação sem data marcada não acontece. A data entra no calendário corporativo, com lembrete, e a rotação segue a ordem criar, migrar, confirmar publicação, revogar a anterior. Exemplo: O npm impõe validade máxima de 90 dias em token de escrita desde 09/12/2025. Adotar a mesma cadência onde o fornecedor não impõe é a forma barata de manter o músculo treinado.
• Alerta de uso fora do pipeline: Toda publicação legítima nasce de um lugar previsível. Publicação que nasce fora dele é sinal de comprometimento e precisa gerar aviso para uma pessoa, não uma linha em um painel que ninguém abre. Exemplo: Registro de publicação comparado com o registro de execuções da esteira, com divergência virando aviso no canal de plantão.
• Detecção de vazamento ligada e verificada: A proteção que bloqueia o envio de segredo para o repositório vale por padrão em todos os repositórios com a varredura ativa, incluindo repositórios públicos gratuitos, conforme atualização de 15 de julho de 2026. Os produtos pagos acrescentam cobertura de histórico e verificação de validade da credencial vazada, a US$ 19 por committer ativo por mês para proteção de segredo e US$ 30 para segurança de código, valores de tabela consultados em 24 de julho de 2026. Exemplo: A verificação de validade é o que permite priorizar: credencial vazada e ainda ativa é plantão, credencial vazada e já revogada é registro.
• Revogação testada com tempo medido: O procedimento precisa ter sido executado de verdade, em dia útil, com cronômetro. O número que interessa é o tempo até a esteira voltar a publicar com a credencial nova, e a meta declarada é menos de uma hora. Exemplo: Ensaio trimestral em um projeto de baixo risco, com os dois maiores gargalos virando item de plano de trabalho.

Os seis controles não substituem a federação de identidade e não devem ser apresentados como se substituíssem. Eles reduzem alcance, encurtam janela e criam capacidade de resposta. O resíduo de risco continua existindo e precisa aparecer no documento com essa palavra.

Evidência pública

Caso documentado: o registro que forçou a migração e virou referência de cobrança

npm, registro de pacotes do GitHub

Em 9 de dezembro de 2025 o npm revogou permanentemente todos os tokens clássicos, impôs validade máxima de 90 dias a tokens granulares com permissão de escrita e transformou a autenticação de linha de comando em sessão de duas horas com segundo fator obrigatório para publicar. É o único componente deste stack que já eliminou o segredo de vida longa por decisão do fornecedor.

• Tokens clássicos revogados de forma permanente, sem período de convivência.
• Tokens granulares com escrita passaram a ter vida máxima de 90 dias, e os que expirariam mais tarde foram ajustados para 3 de fevereiro de 2026.
• O login de linha de comando passou a devolver sessão de 2 horas, com segundo fator obrigatório no ato de publicar.
• O caminho recomendado passou a ser publicação confiável por identidade federada, disponível para GitHub Actions e GitLab CI/CD, com geração automática de atestação de proveniência.

A migração é tecnicamente possível e já foi executada em escala por um fornecedor deste mesmo ecossistema. Isso muda a natureza da conversa com Vercel e Cloudflare: em vez de aceitar que não dá, o comprador pede prazo formal para publicação federada e registra a resposta na ata de renovação de contrato.

O caso serve como referência de exigibilidade contratual, não como afirmação de que Vercel ou Cloudflare tenham anunciado prazo equivalente.

Rotina real

A rotação que nunca acontece porque ninguém é dono dela

Líder de plataforma da Nortis, responsável pela esteira de publicação · Primeira quinta-feira útil de cada trimestre, quarenta minutos reservados no calendário para a rotação das credenciais de publicação.

Situação: A rotação estava prevista na política escrita havia dois anos e nunca tinha sido executada. O motivo não era negligência: a política dizia que a equipe de plataforma era responsável, e equipe não acorda às três da manhã.

Entradas: Inventário com quatro credenciais, cada uma com escopo declarado, dono nomeado, data da última rotação e data da próxima já no calendário corporativo.

Processo: Para cada credencial, na ordem: criar a nova já com escopo do projeto, atualizar o cofre da esteira, disparar uma publicação de verificação em ambiente de prévia, confirmar que publicou, revogar a anterior e registrar a data no inventário.

Saída: Inventário atualizado com quatro linhas rotacionadas, o tempo gasto em cada uma e a lista do que travou, com prazo de correção.

Verificação humana: Antes de revogar a credencial antiga, uma segunda pessoa confirma que a publicação de verificação realmente saiu com a credencial nova. Revogar antes de confirmar transforma manutenção de rotina em incidente de indisponibilidade.

Como se mede: Idade máxima de credencial de publicação em produção, medida em dias, apresentada no comitê trimestral ao lado do tempo medido no último ensaio de revogação.

Guardrail

O inventário que o auditor pede, e que o incidente cobra

Nenhum destes itens exige ferramenta nova. Todos exigem uma decisão de quem responde pela plataforma e uma linha em um documento. O teste de qualidade do inventário é simples: entregue a planilha a alguém que acabou de chegar na empresa e pergunte se essa pessoa consegue revogar tudo em uma hora sem falar com ninguém que esteja de férias.

• Cada credencial capaz de publicar em produção está na lista, incluindo as criadas em máquina pessoal para resolver um problema pontual.
• Cada linha traz escopo declarado, e não a palavra completo por falta de verificação.
• Cada linha traz nome de pessoa e nome de suplente, nunca nome de equipe.
• Cada linha traz a data da última rotação e a data da próxima, já lançada no calendário corporativo.
• Existe alerta quando uma publicação nasce fora da esteira prevista, e esse alerta chega a uma pessoa de plantão.
• O procedimento de revogação foi executado em ensaio, com tempo cronometrado e os gargalos registrados como item de plano de trabalho.
• Está escrito, com essas palavras, que o controle é compensatório porque a federação de identidade para publicação não existe neste stack até 24/07/2026, com data marcada para reavaliar.

Conexão com o portal

Da autorização delegada para a esteira: credencial curta reduz janela, não elimina poder

Credencial de curta duração troca uma proteção difícil, impedir o roubo, por uma proteção viável, encurtar a janela em que o roubo tem valor. O poder concedido continua sendo exatamente o que estava no escopo.

Tradução executiva: Quando alguém propuser que a federação de identidade resolveria o problema da esteira, a pergunta certa é qual janela ela encurta e qual poder ela mantém. Uma credencial de 60 minutos com alcance de conta inteira continua publicando em todos os projetos durante esses 60 minutos. Escopo e janela são controles diferentes, e o mercado costuma vender o segundo como se cobrisse o primeiro.

Use quando: alguém apresentar identidade federada como solução completa para o risco de publicação, sem falar de escopo.

Fronteira: Neste stack a discussão é anterior a isso: para publicar não existe a opção curta até 24 de julho de 2026. O que resta sob nosso controle é o escopo, o calendário de rotação e a capacidade de revogar rápido, e é sobre esses três que o comitê decide.

OAuth e Autorização Delegada

Caso Nortis · Semana 9

O CISO pede a lista de credenciais capazes de publicar em produção. Voltam quatro tokens, dois sem dono nomeado e um criado por alguém que saiu da empresa em março.

A recomendação genérica de eliminar segredo de vida longa com federação de identidade não se aplica a este conjunto de fornecedores: até 24 de julho de 2026 não existe esse caminho para publicar, e os tokens estáticos continuam obrigatórios.

Assumir controle compensatório: escopo mínimo por projeto, dono nomeado, calendário de rotação, alerta de uso fora do pipeline e procedimento testado de revogação em menos de uma hora.

Exemplo trabalhado

As quatro credenciais que publicam em nome da Nortis

CISO da Nortis, com o líder de plataforma ao lado

O pedido foi de uma linha: a lista de tudo que consegue publicar em produção sem passar por uma pessoa. Voltaram quatro tokens. Dois sem dono nomeado, um criado por alguém que saiu da empresa em março e um cujo escopo ninguém soube declarar de cabeça.

Resultado: O inventário sai de quatro linhas sem dono para quatro linhas com dono, escopo declarado, data da última e da próxima rotação e um tempo de revogação medido, não estimado. Os dois gargalos do ensaio viram itens com prazo, e não descoberta de madrugada.

Continua sob responsabilidade humana: O inventário reduz o estrago e não elimina o risco. Enquanto a credencial for de vida longa, quem a lê no momento do uso continua conseguindo publicar em nome da empresa. Esse resíduo precisa estar escrito no documento, com a frase de que o controle é compensatório, e precisa ser reapresentado ao comitê na data em que algum dos dois fornecedores anunciar publicação federada.

Laboratório de decisão

O CISO quer bloquear a publicação automática até existir identidade federada

Na reunião de segurança, o CISO propõe suspender a publicação automática até que os fornecedores ofereçam credencial curta. O líder de plataforma responde que isso devolve a empresa ao deploy manual, que é justamente o que a auditoria anterior apontou como risco. Marina precisa decidir na mesma reunião.

Como tratar um risco real cujo controle recomendado não existe, sem parar a operação nem fingir que o risco foi resolvido?

• A. Suspender a publicação automática e voltar ao processo manual até haver federação de identidade.: Troca um risco conhecido e mensurável por vários riscos difusos: passo manual sem registro, credencial pessoal em máquina de desenvolvedor, publicação sem rastro de quem fez o quê. Além disso, não existe data anunciada por nenhum dos dois fornecedores, então a suspensão não tem prazo de término.
• B. Manter como está, registrando em ata que o mercado ainda não oferece alternativa.: Documenta a ciência do problema e não muda nada na prática. É a opção que sobrevive melhor a uma reunião e pior a uma apuração de incidente, porque a pergunta seguinte do auditor é o que foi feito depois que se soube.
• C. Manter a publicação automática e aprovar os seis controles compensatórios com dono, prazo e data de reavaliação, mais uma cobrança formal de prazo aos dois fornecedores.: Reduz alcance por escopo, encurta janela por rotação, cria capacidade de resposta por ensaio de revogação e transfere parte da pressão para quem pode resolver de fato. O resíduo de risco fica escrito, com essa palavra, e volta ao comitê em data marcada.

Recomendação: A terceira opção, com a exceção escrita no documento e a data de reavaliação já no calendário do comitê.

As três opções aceitam o mesmo fato: não há caminho federado para publicar neste stack até 24 de julho de 2026. A diferença está no que cada uma faz com esse fato. Suspender a automação parece severo e piora a rastreabilidade, que é justamente o que sustenta apuração de incidente. Registrar em ata sem agir é a forma mais educada de não decidir. A terceira opção reconhece o limite e trabalha nas três dimensões que continuam sob controle da empresa, escopo, janela e velocidade de resposta, com a honestidade de dizer que o resultado é mitigação e não solução. E ao pedir prazo formal aos fornecedores, converte uma limitação técnica em item de negociação contratual, que é onde ela pode efetivamente ser resolvida.

• Eu consigo listar, sem consultar o time, tudo que publica em produção em nome da minha empresa sem passar por uma pessoa.
• Eu sei explicar em uma frase por que a recomendação de eliminar segredo de vida longa não se aplica a este stack hoje.
• Eu tenho o tempo real de revogação medido em ensaio, e não um número estimado em reunião.

Protegida a credencial, resta o que roda ao lado dela toda vez que o time publica.