Skip to main content

De onde vêm os patches de segurança?

Escrito por

25 de janeiro de 2018

0 minutos de leitura

Vulnerabilidades conhecidas em softwares são um problema amplamente reconhecido e causaram algumas das maiores violações de segurança do mundo, incluindo a violação da Mossack Fonesca (Panama Papers), a violação da VerticalScope, na qual 45 milhões de senhas e endereços IP foram roubados de uma rede com 1.100 sites, e a violação dos fóruns do Ubuntu, na qual 2 milhões de nomes de usuário e senhas foram roubados.

A melhor solução para vulnerabilidades conhecidas é atualizar o software. No entanto, nem sempre isso é possível. Talvez ainda não haja uma atualização de segurança disponível para o software de que você depende. Ou a atualização pode incluir grandes mudanças funcionais, conhecidas como “breaking changes”, que afetam a maneira como as pessoas ou outros sistemas integrados acessam e usam o software. Isso torna as atualizações caras e, muitas vezes, inviáveis.

A próxima melhor opção é aplicar um patch ao software. Um patch de segurança é uma atualização de um software que corrige um problema de segurança específico, fazendo o mínimo possível de alterações nas funcionalidades.

No caso de software de código fechado, a única maneira de obter um patch de segurança é recebê-lo do fornecedor do software e instalá-lo. Um exemplo conhecido é o Windows Update, que costuma distribuir patches de segurança para milhões de PCs com Windows. O gerenciamento de patches de fornecedores de software comercial é um campo em expansão, e muito já foi escrito sobre “gerenciamento de patches” — o processo de obter, testar e aplicar patches de segurança às suas aplicações. Várias ferramentas foram desenvolvidas para ajudar profissionais de TI a identificar o lançamento de novos patches e implantá-los em seus computadores.

O software de código aberto está se tornando o padrão de fato em muitos casos de uso organizacionais, especialmente como infraestrutura para o desenvolvimento de novos softwares. O código aberto é tão vulnerável quanto o código fechado, mas nem sempre fica claro onde encontrar um patch de segurança para a vulnerabilidade mais recente. Além disso, muitos responsáveis pela manutenção de projetos de código aberto fazem esse trabalho no tempo livre. Por isso, mesmo depois que uma vulnerabilidade é descoberta, o software pode levar algum tempo para ser atualizado ou receber um patch.

Quatro maneiras de encontrar patches de segurança para software de código aberto

1. Atualize ou aplique um patch dos autores do projeto de código aberto

O primeiro lugar para procurar um patch é em uma nova versão do software de código aberto vulnerável. Na maioria das vezes, as vulnerabilidades são corrigidas pelos responsáveis pela manutenção da biblioteca.

2. Pull requests

Em alguns casos, colaboradores de projetos de código aberto criam uma pull request com uma proposta de código para corrigir uma vulnerabilidade de segurança. Mas pode levar tempo até que ela seja incorporada à versão principal do software — se isso acontecer.

Por exemplo, a popular biblioteca JavaScript de análise de Markdown, marked, teve uma vulnerabilidade de XSS com uma pull request de correção aberta por um ano inteiro, até que a correção foi incluída em uma nova versão.

Se houver uma pull request aberta que corrija a vulnerabilidade, os usuários podem baixar o código dela e usá-lo como uma nova versão corrigida. Ainda existe o risco de que as alterações propostas não funcionem como esperado ou causem regressões no software. Por isso, é recomendável verificar se o novo código foi avaliado por outros membros da comunidade e testá-lo antes da implantação.

3. Faça um fork e corrija

Usuários que também são desenvolvedores podem fazer um fork — criar sua própria versão — do software de código aberto e corrigir a vulnerabilidade por conta própria. A vantagem é a confiabilidade: quem faz a correção sabe que tem uma versão estável que atende às suas necessidades e não contém a vulnerabilidade.

A desvantagem é que, ao fazer um fork, os usuários se afastam do fluxo principal de atualizações e correções do software e podem acabar em uma situação mais vulnerável. Afinal, novas vulnerabilidades são descobertas o tempo todo.

4. Feeds de atualizações

A RedHat e a Canonical, duas empresas que apoiam o ecossistema Linux, oferecem aos usuários Linux um feed de atualizações que inclui atualizações de segurança.

O serviço LivePatch da Canonical aplica patches críticos ao kernel do Ubuntu sem exigir a reinicialização do sistema.

A RedHat oferece o gerenciador de pacotes Yum, que permite atualizar qualquer pacote Linux para a versão mais recente disponível, que em muitos casos inclui correções de segurança. O comando yum check-update verifica quais pacotes instalados têm atualizações disponíveis, e o comando yum update package os atualiza automaticamente para a versão mais recente.

O plugin de segurança do Yum indica quais atualizações estão relacionadas à segurança. O plugin está disponível no RedHat Enterprise Linux 5.0 e vem integrado ao RedHat Enterprise Linux 7.0 e versões posteriores.

Além disso, gerenciadores de pacotes como npm (Node.js) e Maven (Java) podem ajudar a manter os pacotes atualizados e instalar atualizações de segurança, embora não identifiquem quais atualizações estão relacionadas à segurança.

5. Snyk

Uma ferramenta para gerenciar vulnerabilidades conhecidas deveria ser indispensável em um fluxo de trabalho com código aberto, mas é importante garantir que ela ofereça correções por meio de patches. Por isso, incluímos essa funcionalidade na nossa oferta principal desde o primeiro dia. Mantemos nosso próprio conjunto de patches no nosso banco de dados de vulnerabilidades. A maioria deles é composta por correções originais adaptadas para versões anteriores que ainda são vulneráveis. Alguns são pull requests testadas e empacotadas como patches prontos para instalação. E outros são desenvolvidos pela equipe de pesquisa de segurança da Snyk.

Solicitação de pull request do GitHub criada pelo snyk-bot corrige dependências npm vulneráveis, com todas as verificações aprovadas e sem conflitos de mesclagem.

Você pode incorporar esses patches ao processo automatizado de build usando a CLI ou até enviá-los ao seu projeto em uma pull request automatizada. Ao reduzir os obstáculos para aplicar patches, você consegue testá-los e aplicá-los rapidamente como parte do seu fluxo de trabalho habitual.

Conclusão

A maioria — se não todos — os produtos de software acaba ficando vulnerável e precisa de atualizações ou patches. A questão é quão rápido você consegue obter um patch que resolva a vulnerabilidade e quão fácil será aplicá-lo.

No caso de software de código fechado, os usuários dependem dos fornecedores, que estão se tornando gradualmente mais ágeis na resposta a problemas de segurança. Para software de código aberto, uma comunidade ativa de responsáveis pela manutenção é a melhor garantia contra vulnerabilidades e outras falhas de segurança. Mas, em muitos casos, a comunidade de código aberto não fornecerá o patch de que você precisa, quando precisa dele.

Você pode se empenhar para encontrar ou criar um patch por conta própria — ou recorrer a fornecedores como Canonical, RedHat ou Snyk para obter uma correção automatizada. Com a crescente complexidade do ecossistema de código aberto, prevemos que as ferramentas se tornarão um componente essencial da postura de segurança de qualquer organização.

Leia mais

Blog

Modelos de ponta encontraram as vulnerabilidades. Só o atacante encontrou as cadeias.

A análise estática encontrou as falhas, mas só os testes de ataque em aplicações ativas provaram como elas poderiam ser encadeadas para causar invasões. Uma comparação entre Evo COS, Claude Security e Claude Code Security.

feature insights context
Blog

Os ataques autônomos já chegaram. A defesa precisa acompanhar o ritmo.

Os atacantes autônomos estão reduzindo o tempo disponível para a defesa. Saiba como a descoberta, a correção, a validação e a prevenção contínuas ajudam as equipes de segurança a acompanhar esse ritmo.

Blog

Seu backlog de vulnerabilidades não é mais uma dívida técnica — é uma superfície de ataque

Um backlog crescente de vulnerabilidades é mais do que uma dívida técnica: ele é uma superfície de ataque. Entenda por que suposições de risco desatualizadas, atacantes automatizados e descobertas encadeadas exigem uma nova abordagem.