O calendário que o fornecedor controla e a dívida com prazo

Montar o calendário de obsolescência com data, sistema afetado, dono interno e prazo de correção, junto do inventário de dívida técnica com prazo.

• Identificar as datas de fim de vida que param a publicação de projetos estáveis.
• Medir o tamanho da dívida técnica criada por recomendações que o próprio fornecedor reverteu.
• Fixar política de atualização com prazo interno de aplicação de correção de segurança.

Em linguagem simples

Toda plataforma tem um calendário de obsolescência: datas em que versões de ambiente de execução, formatos de configuração e produtos inteiros deixam de ser aceitos. Essas datas são definidas pelo fornecedor, publicadas em canais técnicos e quase nunca chegam a quem aprova orçamento. O efeito é binário: no dia marcado, o projeto para de aceitar publicação nova.

O cenário mais perigoso é o do projeto estável, aquele que ninguém toca há meses porque funciona. Ele passa pela data de corte sem que nada aconteça, porque publicações antigas continuam servindo. A falha aparece no dia em que alguém precisa de uma correção urgente, que é o pior dia possível para descobrir uma dívida com prazo vencido.

1. 01Fim de vida de ambiente de execução tem data e efeito binário. A versão é desabilitada nas configurações e novas publicações passam a dar erro. Publicações já existentes continuam servindo, o que esconde o problema até a próxima correção urgente.
2. 02Recomendação de fornecedor também expira. O que foi vendido como boa prática entre 2022 e 2024 pode estar hoje marcado como caminho a abandonar. A dívida técnica gerada por seguir a recomendação anterior é da empresa, e o prazo de migração é do fornecedor.
3. 03Ferramenta de linha de comando muda de versão maior sem cerimônia. Três versões maiores publicadas em quinze dias, verificado em 24 de julho de 2026. Pipeline que instala a ferramenta sem versão fixada quebra sozinho entre uma publicação e outra.
4. 04Correção de segurança de framework é decisão de prazo, não de gosto. Falha de desvio de verificação de acesso permite pular autenticação. O que a empresa decide é em quantos dias aplica a correção, e essa decisão precisa estar escrita antes do próximo boletim.

Confusão mais comum: Achar que projeto parado é projeto sem risco. O oposto se aplica: projeto estável não recebe atualização, atravessa a data de corte sem sinal e falha na primeira tentativa de publicação urgente.

Explique em voz alta: Formule a pergunta que você faria ao seu time sobre qual sistema está há mais tempo sem publicação e em qual versão de ambiente de execução ele roda.

O relógio que corre fora da empresa

Existe uma categoria de risco que não aparece em nenhum painel interno: as datas que o fornecedor define sozinho. Elas não dependem de decisão da empresa, não são negociáveis no plano padrão e chegam pelo canal técnico de mudanças, que raramente tem leitor designado.

O efeito dessas datas é binário e silencioso. Publicações antigas continuam servindo, o produto segue no ar e nada indica problema. A falha aparece na primeira tentativa de publicar depois da data de corte, e a primeira tentativa costuma ser justamente a correção urgente que alguém precisa subir com pressa.

Há um segundo tipo de dívida com prazo, mais desconfortável: a que nasceu de seguir a recomendação anterior do próprio fornecedor. Quem padronizou o runtime de borda em 2024, porque era o que a plataforma vendia, hoje tem um refactor com data, porque a mesma plataforma recomenda o caminho inverso desde 10 de junho de 2026. A dívida é da empresa; o calendário é do fornecedor.

Calendário de obsolescência com datas já publicadas

Datas verificadas em 24 de julho de 2026 nos canais oficiais de mudança dos fornecedores. Preencha a coluna da direita com o nome de quem responde por cada item dentro da sua empresa. O boletim de segurança de 20 de julho está fora da tabela de propósito: ele é tratado inteiro no caso documentado logo abaixo.

Modelo operacional

O inventário de dívida com prazo, em quatro perguntas

Quatro perguntas que qualquer diretoria consegue fazer e que o time responde em uma tarde. As respostas viram linhas do calendário, com dono e prazo interno anterior à data do fornecedor.

• Em qual versão de ambiente de execução cada projeto está: A lista completa, projeto a projeto, com a data da última publicação ao lado. Projeto sem publicação recente é o mais exposto, porque a falha só aparece na próxima tentativa. Exemplo: Três projetos na versão 20, sendo um deles no caminho crítico de faturamento, com última publicação há sete meses.
• Quantas rotas declaram execução na borda: Um levantamento de dois minutos no código devolve o tamanho do refactor criado pela recomendação de migração do próprio fornecedor. É o número que transforma dívida abstrata em plano de trabalho. Exemplo: Verificação de autenticação, sinalização de recursos e detecção de país costumam ser as três famílias de rota escritas para a borda.
• Qual trilho de framework cada projeto usa: Linha ativa recebe recurso e correção; linha de manutenção recebe apenas correção. A política de atualização se escreve sobre o trilho, e não sobre a última versão publicada. Exemplo: Verificado no registro em 24/07/2026: 16.2.11 na linha ativa e 15.5.21 na linha de manutenção.
• Em quantos dias a empresa aplica correção de segurança: O prazo interno precisa estar escrito antes do próximo boletim. Sem prazo, cada falha vira negociação entre engenharia e produto, no pior momento. Exemplo: Prazo de sete dias corridos para falha de severidade alta que envolva desvio de verificação de acesso, com responsável nomeado por acompanhar o canal de segurança.

As quatro respostas cabem em uma página e valem por um trimestre. O que não vale por um trimestre é a lista de datas: ela precisa de revisão marcada, porque novas datas são anunciadas o tempo todo.

Evidência pública

Caso documentado: nove falhas em um boletim, quatro delas de severidade alta

Next.js, boletim de segurança de julho de 2026

Em 20 de julho de 2026 o framework publicou um boletim com nove falhas de segurança, quatro classificadas como de severidade alta, com correções nas versões 16.2.11 e 15.5.21. Na semana anterior, o fornecedor havia anunciado a adoção de um modelo de boletim de segurança pré-anunciado.

• Negação de serviço por meio de ações de servidor, identificada como CVE-2026-64641.
• Desvio da camada de intermediação com o compilador novo e idioma único, identificado como CVE-2026-64642.
• Duas falhas de requisição forjada no servidor, identificadas como CVE-2026-64645 e CVE-2026-64649.
• Correções disponíveis nas versões 16.2.11, da linha ativa, e 15.5.21, da linha de manutenção.

Desvio da camada de intermediação significa que verificações de autenticação podem ser puladas. É falha de controle de acesso, e não questão de desempenho, o que a coloca na mesma categoria de risco de um vazamento de credencial. Com boletim pré-anunciado, a empresa ganha janela para planejar em vez de reagir, e essa janela só serve a quem já tem prazo interno escrito.

O comprometimento pode nascer no framework, e não no código da empresa, sem que isso altere de quem é o dever de notificar o titular do dado e o regulador.

Guardrail

O que impede a data de virar emergência

Nenhum dos controles abaixo exige ferramenta nova ou orçamento. Todos exigem que alguém tenha o nome escrito ao lado do item, com prazo interno anterior à data do fornecedor. Calendário sem dono é lista de leitura.

• Cada projeto tem a versão do ambiente de execução declarada e a data da última publicação registrada ao lado.
• Existe pessoa nomeada para acompanhar os canais de mudança dos dois fornecedores, com revisão trimestral do calendário.
• As versões da ferramenta de linha de comando de publicação estão fixadas no projeto, e não instaladas de forma global sem versão.
• O prazo interno de aplicação de correção de segurança está escrito, com faixa diferente para severidade alta.
• O inventário de rotas escritas para o runtime de borda existe, com número e com data de levantamento.
• Todo prazo interno é anterior à data do fornecedor, com margem declarada, e não coincide com ela.

Caso Nortis · Semana 7

Um projeto estável, que ninguém toca há sete meses, é o sistema de emissão de comprovantes. Ele roda numa versão de runtime que o fornecedor desabilita em 1º de outubro de 2026, e nos executores de integração contínua a mesma versão sai em 16 de setembro de 2026.

O efeito é binário e chega no pior dia possível: o projeto para de aceitar publicação nova justamente quando alguém precisar de uma correção urgente.

Montar o calendário de obsolescência com data, sistema afetado, dono e prazo interno de correção, incluindo a dívida técnica de quem adotou a recomendação de borda que o próprio fornecedor reverteu em 10 de junho de 2026.

Exemplo trabalhado

O sistema que ninguém tocava e que ia parar em outubro

CTO da Nortis, preparando o comitê de risco

O sistema de emissão de comprovantes roda há sete meses sem publicação nova. Funciona, ninguém reclama e ninguém olha. O inventário de versões de ambiente de execução nunca foi feito.

Resultado: A Nortis descobre em uma tarde três projetos que parariam de aceitar publicação em outubro, um deles no caminho crítico de faturamento. A correção entra no plano do trimestre, com dono, em vez de virar emergência no dia de uma correção urgente.

Continua sob responsabilidade humana: O calendário registra as datas conhecidas em 24 de julho de 2026 e não protege contra as que ainda serão anunciadas. O valor do artefato está na rotina de revisão trimestral, com alguém nomeado para acompanhar os canais de mudança dos fornecedores, e não na lista congelada.

Laboratório de decisão

Três projetos param em outubro e o trimestre já está cheio

O levantamento mostrou três projetos na versão 20 do ambiente de execução, um deles no caminho crítico de faturamento. O trimestre já tem escopo aprovado e o time alega que não cabe mais nada. A data do fornecedor é 1º de outubro de 2026, e a dos executores de integração contínua é 16 de setembro.

Empurrar para o trimestre seguinte, atualizar tudo agora ou tratar por criticidade?

• A. Empurrar para o próximo trimestre, porque o produto continua no ar.: Verdadeiro até a primeira correção urgente. A falha chega no dia de maior pressão, com o time reagindo em vez de planejando, e a janela de correção do sistema de faturamento passa a depender de uma migração de ambiente de execução feita às pressas.
• B. Atualizar os três projetos agora, com prioridade sobre o escopo aprovado.: Elimina o risco e paga o preço integral em escopo de produto. Trata como igual um projeto de faturamento e um painel interno usado por quatro pessoas, o que é caro sem necessidade.
• C. Tratar por criticidade: o sistema de faturamento entra agora, os outros dois entram com prazo interno anterior à data do fornecedor, e o calendário passa a ter revisão trimestral com dono.: Custa uma fração do escopo, remove o risco do caminho crítico primeiro e institucionaliza a rotina que evita a próxima descoberta tardia. Deixa margem entre o prazo interno e a data do fornecedor.

Recomendação: A terceira opção, com o prazo interno dos dois projetos restantes fixado em pelo menos três semanas antes de 16 de setembro de 2026.

A decisão parece de engenharia e é de sequenciamento de risco. Empurrar tudo transfere um trabalho previsível para o dia mais caro do ano, que é aquele em que o faturamento precisa de correção urgente. Atualizar tudo com a mesma prioridade queima escopo de produto para proteger sistemas cujo custo de indisponibilidade é próximo de zero. Tratar por criticidade resolve os dois problemas e produz um efeito que sobrevive ao trimestre: uma vez que o calendário passa a ter dono e revisão marcada, a próxima data anunciada pelo fornecedor chega como item de planejamento e não como incidente. A margem entre o prazo interno e a data do fornecedor existe porque migração de ambiente de execução costuma revelar dependência incompatível, e descobrir isso na véspera anula todo o planejamento.

• Eu sei quais datas definidas pelos meus fornecedores atingem a minha operação nos próximos doze meses, e quem responde por cada uma.
• Eu tenho o número de rotas que executam na borda, com a data do levantamento ao lado.
• Eu tenho prazo interno escrito para aplicar correção de segurança de framework, com faixa própria para severidade alta.

Com o calendário na mesa, o conselho pergunta o que aconteceria se a decisão fosse sair de vez.