O que é backporting? Processo, considerações, dicas e muito mais

Principais conclusões

• O backporting consiste em aplicar uma correção de uma versão mais recente à versão mais antiga que você utiliza, sem a necessidade de uma atualização do código-fonte original.
• A Red Hat corrigiu a vulnerabilidade Heartbleed no OpenSSL 1.0.1e sem alterar a versão original, de modo que os verificadores que analisam apenas a versão ainda assim a identificam.
• Confirme um backport com o comunicado da distribuição e o histórico de alterações do pacote, e não com o número da versão.
• Quando o suporte padrão chega ao fim, as correções dependem do suporte estendido, de um fork mantido ou da sua própria equipe.

Seu scanner indica que o servidor está executando uma versão vulnerável do OpenSSL. Seu administrador de sistemas diz que ela foi corrigida no mês passado. Ambos estão analisando o mesmo host e verificando o mesmo pacote, mas apenas um deles está certo sobre a vulnerabilidade. Essa discussão é um problema de retroportabilidade. Uma correção de uma versão mais recente foi aplicada à versão ainda em execução, e o número da versão original nunca mudou. No ambientes corporativos de Linux , investigar esse tipo de alarme falso pode consumir mais horas do que algumas vulnerabilidades reais.

Este artigo aborda o que é o backporting, por que o número da versão permanece o mesmo após a implementação de uma correção, por que isso confunde os verificadores baseados em versão, como verificar uma correção por conta própria e quem continua a fornecer os backports depois que uma versão chega ao fim de sua vida útil.

O que é backporting?

Backporting significa extrair uma correção para uma falha de segurança de uma versão mais recente de um pacote de software e aplicá-la a uma versão mais antiga que ainda esteja em uso. A vulnerabilidade é corrigida sem a necessidade de migrar para uma versão mais recente do desenvolvedor original e sem ter que incorporar todas as alterações não relacionadas a ela.

Mas o que significa “backport” na prática? Veja aqui um exemplo concreto. Os mantenedores do OpenSSL corrigiram a vulnerabilidade Heartbleed na versão 1.0.1g. Os clientes da Red Hat estavam usando a versão 1.0.1e, e migrá-los para a 1.0.1g teria trazido todas as outras alterações feitas entre essas versões. Assim, a Red Hat fez o backport apenas da correção do Heartbleed para sua base de código 1.0.1e e lançou a versão openssl-1.0.1e-16.el6_5.7 sob o aviso RHSA-2014:0376. A mesma linha de base de recursos do upstream, o mesmo comportamento fora do caminho de código corrigido e sem mais Heartbleed.

A retroportação de correções de segurança dessa forma tem sido uma prática padrão na maioria das distribuições Linux, incluindo RHEL, Ubuntu, Debian, SUSE e suas derivadas, há duas décadas. Execute o comando `dnf update` em um host RHEL e muitas das correções recebidas são retroportações.

Você sabia?: O campo “release” no final é como você identifica uma compilação retroportada. Em openssl-1.0.1e-16.el6_5.7, 1.0.1e é a versão original, e, no caso de uma atualização retroportada, ela permanece exatamente onde está. O parte 16.el6_5.7 é a versão do pacote da distribuição e muda sempre que a distribuição lança uma compilação revisada.

Como funciona o backporting

Um mantenedor identifica a correção no código original, isola-a de todas as outras alterações, adapta-a a uma base de código que sofreu mudanças, testa se há regressões e a distribui pelo canal de atualização normal, mantendo intacto o número da versão do código original.

Manter esse número de versão do upstream é uma decisão tão deliberada quanto a própria correção. Isso indica que, na essência, o pacote ainda é a mesma versão, com sua API e seu comportamento geral preservados fora do caminho de código corrigido. Apenas o identificador de versão da distribuição é alterado.

1. Identificar a correção na origem

Alguém relata uma falha, os mantenedores do projeto original escrevem uma correção, e ela é incorporada a uma versão mais recente. A equipe de segurança da distribuição precisa identificar a alteração exata — ou o conjunto de alterações — que corrige a falha, e não apenas a versão que a contém.

Isso é mais difícil do que parece. Os projetos de código-fonte nem sempre lançam uma correção de segurança como um único commit limpo e isolado. Ela pode estar distribuída por três commits, incluída em uma refatoração maior ou mesclada com uma mensagem vaga antes que o CVE seja divulgado. As equipes de segurança monitoram continuamente os repositórios de código-fonte, as listas de discussão e os feeds de CVE para identificar essas correções.

O resultado dessa etapa é um patch — às vezes composto por vários commits —, além de uma compreensão clara de quais linhas, exatamente, corrigem a falha e por quê. Tudo o que vem a seguir depende de se fazer isso corretamente — se você deixar de corrigir metade do problema, acabará lançando um pacote que alega estar corrigido, mas na verdade não está.

2. Isolar essa alteração de outras que não estejam relacionadas

A correção do upstream chega misturada com tudo o mais nessa versão: novos recursos, refatorações, alterações nos padrões e atualizações de dependências. O mantenedor remove tudo isso.

O que restar deve ser a alteração mínima necessária para corrigir a falha, nada mais. Essa é toda a proposta de valor do backport. Você obtém a correção de segurança sem a nova sintaxe de configuração que prejudica sua função do Ansible.

Dica: Alguns registros de alterações das distribuições mencionam a versão ou o commit do código-fonte de onde veio uma correção retroportada. Quando isso acontece, essa referência indica a origem da correção, e não o que está instalado. Seu pacote permanece na versão original do código-fonte, e apenas o número da versão da distribuição é alterado. Os auditores costumam confundir os dois, portanto, destaque essa diferença uma vez em seu pacote de evidências e você não precisará explicá-la cinco vezes durante a revisão.

O isolamento também exige bom senso. Decidir quais linhas realmente pertencem à correção significa compreender a própria vulnerabilidade, o que é um desafio maior do que aplicar um patch que foi criado para o código que você tem diante de si.

3. Adaptá-lo à base de código mais antiga

Agora, o patch precisa ser reescrito para se adequar. As assinaturas das funções são diferentes, as estruturas de dados mudaram de formato e as funções auxiliares podem ainda não existir na árvore mais antiga. Uma correção que afeta uma função renomeada há duas versões não pode ser aplicada literalmente.

O mantenedor reimplementa a mesma lógica defensiva utilizando o que a base de código mais antiga oferece. Quando as duas árvores não se distanciaram muito, isso pode ser um trabalho rápido. Quando elas divergiram por anos, isso pode significar uma reimplementação substancial e, às vezes, pode ser totalmente impossível de ser feito, o que é um dos limites reais abordados mais adiante.

Um exemplo prático: uma correção autônoma que adiciona uma verificação de limites geralmente é fácil de portar. Uma correção que elimina uma condição de corrida alterando o modelo de bloqueio é muito mais difícil, pois o código antigo pode não possuir as primitivas de bloqueio das quais a correção depende. O mantenedor precisa, então, resolver o mesmo problema de segurança de outra maneira.

É por isso que “quem cuida dos seus backports” é uma questão concreta de aquisição e não apenas um slogan de marketing. A competência da equipe responsável por esse trabalho determina se o seu sistema “corrigido” está realmente corrigido.

4. Verifique se o comportamento não muda

O pacote corrigido é compilado e testado com base em dois critérios: a falha foi corrigida e a correção não causou regressões indesejadas.

A segunda metade é o desafio mais difícil. Conjuntos de testes de regressão, verificações de compatibilidade de ABI e testes de integração são todos executados nesta fase, pois o objetivo principal de um backport é que ele possa passar pelo ciclo normal de patches, em vez de se transformar em um projeto de migração. Basta quebrar essa promessa uma vez para que os clientes deixem de confiar no canal de atualizações.

As distribuições corporativas dedicam grande esforço à compatibilidade de ABI para pacotes de bibliotecas, de modo que um backport não altere inadvertidamente um símbolo do qual o aplicativo compilado de um cliente dependa. O RHEL, por exemplo, publica compromissos explícitos de compatibilidade de API e ABI para suas versões. Essa disciplina é um dos principais motivos pelos quais as versões com suporte de longo prazo permanecem utilizáveis por uma década.

Atenção: Um backport que foi validado em relação à falha não foi necessariamente validado em relação ao seu aplicativo. Os testes de regressão do fornecedor abrangem o próprio pacote. Mantenha seus próprios testes de verificação no caminho crítico.

5. Envie-o mantendo a versão do upstream inalterada

O pacote é distribuído pelo repositório normal. A versão original permanece exatamente como estava, e o sufixo de lançamento da distribuição é alterado.

openssl-1.0.1e-16.el6_5.4 torna-se openssl-1.0.1e-16.el6_5.7. Para o seu gerenciador de pacotes, essa é uma atualização de rotina. Para um verificador baseado em versão que compara “1.0.1e” com um banco de dados CVE de origem que indica “corrigido na versão 1.0.1g”, parece que você não fez absolutamente nada.

Essa incompatibilidade é uma escolha deliberada de compatibilidade com um efeito colateral conhecido na geração de relatórios e é uma das fontes mais comuns de resultados falsos positivos na detecção de vulnerabilidades em ambientes Linux.

Retroportação x Atualização

Ambos corrigem a falha. Eles diferem em quase tudo o mais.

	Retroportagem	Atualização
O que você recebe	Correções específicas, sem migrar para uma versão mais recente do upstream	As correções, além dos novos recursos, das configurações padrão alteradas e das APIs modificadas
Impacto na estabilidade	Projetado para preservar o comportamento atual	O comportamento pode mudar, por isso é necessário realizar testes
Esforço por você	Atualização de rotina dos pacotes	Testes de compatibilidade, migração de configuração, possíveis alterações no código
Risco de quebra	Menor do que uma grande atualização, mas não é zero	Moderado a alto, dependendo da diferença entre as versões
Quem faz o trabalho?	Distribuidora ou fornecedor de suporte	Sua equipe
Por quanto tempo dura	Até que quem cuida dos backports pare	Até que a versão recém-atualizada chegue ao fim de sua vida útil (EOL)

A atualização pode trazer um fortalecimento mais abrangente, configurações padrão mais seguras e melhorias arquitetônicas, além da correção específica de que você precisava. O backporting permite obter a correção específica com o mínimo possível de alterações colaterais. Essa relação custo-benefício é um dos principais motivos pelos quais as versões com suporte de longo prazo privilegiam a manutenção direcionada em vez de rebasamentos frequentes.

A equação muda quando a diferença entre as versões se torna grande o suficiente. Uma cadeia de backports que manteve um pacote atualizado por oito anos acumula muitas divergências, e, em determinado momento, a migração pode ser a opção mais prática. A questão é se você pode escolher o momento certo, e nossa comparação entre “fim da vida útil” e “fim do suporte” aborda o que determina essa decisão.

Por que os scanners sinalizam correções retroativas

Alguns scanners baseados em versão comparam a versão do pacote detectada com as versões de correção do CVE do desenvolvedor original. Seu pacote indica a versão 1.0.1e. O banco de dados indica que a vulnerabilidade Heartbleed foi corrigida na versão 1.0.1g. O scanner informa que você está vulnerável. Se esse veredicto se basear apenas na sequência de caracteres da versão, trata-se de um falso positivo, pois o scanner nunca levou em conta a correção retroportada. A própria documentação de segurança da Red Hat destaca exatamente esse comportamento.

Aqui está o exemplo detalhado, do início ao fim.

O que cada parte vê	Valor
Seu pacote instalado	openssl-1.0.1e-16.el6_5.7
Versão de correção na fonte para CVE-2014-0160	1.0.1g
Veredicto do scanner simplista	Vulnerável
Status atual	Corrigido por meio do RHSA-2014:0376

Verifique você mesmo, começando pelo registro de alterações. Verifique se o pacote instalado contém o CVE:

rpm -q –changelog openssl | grep CVE-2014-0160

Se o CVE aparecer, isso é um forte indício de que a correção está incluída, e o comunicado de segurança da distribuição é onde você pode confirmar isso. A mesma verificação funciona para um arquivo RPM que ainda não foi instalado:

rpm -qp kernel-3.10.0-862.11.6.el7.x86_64.rpm –changelog | grep CVE-2017-12190

No Debian e no Ubuntu, o equivalente é o changelog do Debian:

zcat /usr/share/doc/openssl/changelog.Debian.gz | grep CVE-2014-0160

Swap in whatever package you’re checking. Most Debian and Ubuntu packages ship this file at /usr/share/doc/<package>/changelog.Debian.gz. Don’t confuse it with changelog.gz, which is normally the upstream changelog. Debian’s own package changes, backports included, are recorded in changelog.Debian.gz. Minimal and container images often strip /usr/share/doc entirely, and in that case apt changelog <package> fetches the changelog from the archive instead.

Verifique três fontes, pois elas respondem a perguntas diferentes. O aviso de segurança da distribuição é a referência para saber qual compilação de pacote corrige um determinado CVE, e a Red Hat, a Canonical e o Debian publicam páginas específicas para cada CVE, listando as versões exatas dos pacotes corrigidos. Os metadados e o registro de alterações do pacote instalado informam o que realmente está no host e, geralmente, indicam os CVEs que a compilação corrige, o que os torna uma verificação inicial rápida. Feeds legíveis por máquina são destinados às suas ferramentas. Formatos como OVAL e, quando um fornecedor os publica, dados VEX ou CSAF permitem que os scanners utilizem a própria avaliação da distribuição, em vez de fazer suposições com base em uma string de versão. Se o seu scanner for compatível com eles, ative-os.

A solução estrutural consiste em uma ferramenta que determine o status real do patch, em vez de confiar apenas na correspondência com a versão do upstream.TuxCare Radar foi desenvolvido para funcionar em conjunto com seus scanners existentes, visando preencher essa lacuna específica. Ele reconhece backports de distribuições, patches sem reinicialização do KernelCare e atualizações do ELS, de modo que um host com patch instalado seja reportado como atualizado, e pode exportar as evidências quando alguém solicitar comprovação.

Dica profissional: Antes de contestar uma constatação com um auditor, exporte a linha do changelog e a URL do aviso da distribuição juntos. “O CVE está listado no changelog do pacote e o aviso do fornecedor confirma essa versão” encerra a conversa. “Acredite em mim, foi retroportado” não.

Quem faz o backport de correções e por quanto tempo

Normalmente, três grupos realizam esse trabalho: projetos de desenvolvimento com ramificações estáveis que recebem suporte, equipes de segurança das distribuições e fornecedores de suporte estendido. É nas transições entre eles que os ambientes ficam vulneráveis.

Os projetos upstream geralmente mantêm um número reduzido de ramificações com suporte, às vezes incluindo uma ramificação LTS de vida útil mais longa, e selecionam correções para incorporá-las nessas ramificações. Quando uma ramificação sai desse período de suporte, o suporte é encerrado.

Equipes de segurança das distribuições fazem o backport para as versões que distribuem, durante todo o período de suporte. As principais versões atuais do RHEL contam com dez anos de Suporte Completo e Suporte de Manutenção, e a Red Hat oferece cobertura estendida além desse prazo. O RHEL 7 está no complemento ELS mais antigo, enquanto o RHEL 8.10 e versões posteriores passam para o Extended Life Cycle Premium. O Ubuntu LTS recebe cinco anos de manutenção de segurança padrão, até dez com o Ubuntu Pro e até 15 com o complemento pago “Legacy” da Canonical.

Fornecedores de suporte estendido assumem a responsabilidade a partir daí, e somente se você adquirir o serviço. Às vezes, trata-se do próprio programa pago do fornecedor original; outras vezes, é de um terceiro.

As datas são definitivas e, para muitos sistemas de produção, já passaram. As informações estão atualizadas em setembro de 2026:

Comunicado	Fim do suporte padrão	Situação atual
Python 2.7	1º de janeiro de 2020	Sem correções de segurança
Ubuntu 16.04	30 de abril de 2021 (o ESM venceu em maio de 2026)	Apenas para o complemento pago Legacy, até maio de 2031
CentOS Linux 8	31 de dezembro de 2021	Não há atualizações do upstream
PHP 7.4	28 de novembro de 2022	Sem correções de segurança
Ubuntu 18.04	31 de maio de 2023 (Ubuntu Pro ESM até maio de 2028)	Apenas ESM
PHP 8.0	26 de novembro de 2023	Sem correções de segurança
CentOS Linux 7	30 de junho de 2024	Não há atualizações do upstream
RHEL 7	30 de junho de 2024 (Red Hat ELS até maio de 2029)	Apenas suporte estendido pago
Ubuntu 20.04	31 de maio de 2025 (Ubuntu Pro ESM até maio de 2030)	Apenas ESM
PostgreSQL 13	13 de novembro de 2025	Sem correções de segurança
PHP 8.1	31 de dezembro de 2025	Sem correções de segurança

Assim que uma versão ultrapassa esse limite, as correções deixam de ser disponibilizadas pelo canal de atualização padrão. A proteção a partir desse ponto depende de um programa de suporte estendido pago — seja do fornecedor original, de um terceiro ou de manutenção interna.

O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare cobre esse período. O ELS continua fornecendo correções de segurança retrocompatíveis para sistemas operacionais, ambientes de execução, ecossistemas de linguagens e aplicativos após o término do suporte padrão, por meio do mesmo gerenciador de pacotes já em uso.

Veja a lista completa das tecnologias compatíveis. Para conhecer melhor o processo de aplicação de patches, este artigo técnico explica o processo com mais detalhes.

Desafios e limites do backporting

As bases de código divergem. A cada ano que passa, a árvore mais antiga se assemelha cada vez menos à mais recente. Um patch que foi aplicado sem problemas no segundo ano pode exigir uma reimplementação substancial no sétimo ano; assim, o trabalho se torna mais difícil e demorado exatamente à medida que o código envelhece.

Os testes também ficam mais complexos. Cada novo backport precisa ser validado em relação a uma base de código que pode já conter anos de backports anteriores e outras alterações de versões posteriores, e essas alterações podem interagir entre si. Quanto mais modificações um branch acumula, mais itens há para serem testados em testes de regressão.

Algumas correções não podem ser retroportadas diretamente de forma alguma. Quando o projeto original corrige uma falha alterando a arquitetura — por exemplo, com um novo modelo de memória, um sistema de permissões reprojetado ou um analisador reescrito —, pode não haver um patch independente para ser adaptado. As opções do fornecedor são: uma mitigação personalizada que alcance o mesmo resultado de segurança por meios diferentes, ou uma declaração honesta de que a falha não é corrigível naquele ramo. Ambas são legítimas. O silêncio, não.

E um backport, por definição, é restrito. Ele corrige a falha específica. Não traz o fortalecimento geral, as configurações padrão mais seguras nem a remoção de caminhos de código legados que uma nova versão principal poderia incluir. Uma versão mais antiga pode conter uma correção para cada CVE que seu mantenedor tenha resolvido e, ainda assim, manter código legado e limitações de segurança que versões mais recentes já removeram ou reprojetaram.

A qualidade do backport depende inteiramente de quem mantém os patches. Esse é um critério importante na hora de escolher uma distribuição ou um fornecedor de suporte estendido; portanto, pergunte sobre os prazos de backport, as práticas de testes de regressão e o que acontece quando uma correção não pode ser portada. Essas respostas são mais importantes do que uma lista de recursos e influenciam diretamente a forma como você gerencia vulnerabilidades e define a política de priorização delas.

Continue recebendo backports após o fim da vida útil (EOL) com a TuxCare

O backporting só oferece proteção enquanto alguém ainda estiver realizando essa tarefa. Quando o suporte padrão chega ao fim, as correções deixam de chegar pelo canal normal de atualizações, a menos que haja um suporte estendido em vigor. O sistema continua funcionando e as vulnerabilidades (CVEs) continuam surgindo — a partir desse momento, a proteção depende da migração ou de um provedor de suporte estendido.

Suporte de ciclo de vida ilimitado da TuxCare garante o fornecimento contínuo de patches de segurança para sistemas operacionais, ambientes de execução, ecossistemas de linguagens e aplicativos em fim de vida útil (EOL), mesmo muito tempo depois que o suporte padrão do desenvolvedor original ou do fornecedor tiver sido encerrado.

Veja como fica a cobertura para sua pilha, ou faça uma pergunta sobre uma versão específica que está chegando ao fim de vida útil.

Perguntas frequentes