Tudo o que você queria saber sobre como corrigir vulnerabilidades de segurança em contêineres baseados em Linux

Pense na imagem de contêiner mais importante que está em produção neste momento. Como você escolheu a imagem base? Sabe quantas vulnerabilidades ela tem? Não gostaria de saber?

Aqui na Snyk, queremos tornar o processo de escolha da imagem base mais segura mais inteligente, simples e, acima de tudo, baseado em dados.

Mas, primeiro, vamos falar um pouco sobre a segurança das distribuições Linux, já que este post trata de imagens baseadas em Linux.

Distribuições Linux em poucas palavras

Uma distribuição Linux (distro) é um sistema operacional (SO) criado a partir de uma coleção de software que inclui o kernel Linux (o núcleo do sistema operacional), um sistema de gerenciamento de pacotes e ferramentas e bibliotecas GNU, além de outros softwares e documentação. Tudo isso é agrupado e adaptado pelos responsáveis pela manutenção para maximizar os recursos e atender às necessidades de diferentes plataformas e dispositivos.

As distribuições geralmente são disponibilizadas de duas formas:

• como binários compilados (imagens empacotadas), disponíveis para download em repositórios de imagens, como o Docker Hub. Em geral, as imagens são empacotadas a partir das bibliotecas mantidas como código-fonte.

• como código-fonte, permitindo modificar o software original. Isso oferece grande flexibilidade, especialmente porque a maior parte dos softwares incluídos na distribuição costuma ser de código aberto.

Hoje, existem centenas de distribuições Linux disponíveis, e a maioria recebe manutenção ativa. Com ampla disponibilidade e flexibilidade de recursos, elas são usadas em diversas plataformas e dispositivos, inclusive em contêineres.

Assim como qualquer outro software, os contêineres também estão sujeitos a ataques causados por vulnerabilidades que possam existir em seu código.

Como a segurança varia entre as diferentes distribuições Linux e suas versões?

Cada distribuição tem suas próprias formas de criação e manutenção. As diferenças podem incluir como os componentes são agrupados e gerenciados, entre outros fatores, e resultam em variações no tamanho da distribuição, nos gerenciadores de pacotes e na exposição a vulnerabilidades de segurança.

Uma vulnerabilidade de segurança em um componente pode receber pontuações de gravidade diferentes em cada distribuição. Um componente comum a várias distribuições pode ser considerado seguro em uma delas e receber uma pontuação CVE alta em outra — tudo por causa das diferenças na forma como cada distribuição é empacotada.

Algumas distribuições também costumam ser mais seguras do que outras graças aos mecanismos incorporados pelos responsáveis em seus processos de manutenção. Distribuições comerciais e consolidadas (Debian, Ubuntu, CentOS e Oracle) contam com equipes de segurança dedicadas. Essas equipes verificam as pontuações CVE, priorizam e implementam correções de segurança e mantêm a segurança geral da distribuição.

Ainda assim, existem diferenças entre as opções. Confira a tabela, que mostra as diferenças na forma como essas principais distribuições são gerenciadas — um fator que também afeta seu nível de segurança:

*O Alpine adota uma abordagem diferente para manter as imagens: atualiza os pacotes regularmente e inclui correções de segurança em um pequeno subconjunto dos principais pacotes (curl, …).

Qual é a diferença entre uma distribuição Linux e um ecossistema de linguagens?

Os ecossistemas de linguagens armazenam pacotes em registros, e gerenciadores de pacotes (como npm e pip) são responsáveis por mantê-los atualizados. Da mesma forma, as distribuições ficam armazenadas em repositórios de pacotes para serem reutilizadas como dependências em diferentes projetos. No entanto, elas são empacotadas como imagens e armazenadas separadamente em repositórios de imagens, de onde podem ser baixadas e usadas imediatamente em outros projetos. Depois de empacotadas para download e uso imediato, as imagens ficam em seus próprios registros de pacotes e são atualizadas por seus gerenciadores de pacotes, independentemente das bibliotecas de origem.

Nos dois casos, cabe ao gerenciador de pacotes baixar os pacotes regularmente, atualizá-los e, em seguida, enviá-los de volta ao local de armazenamento.

Mas é aí que as semelhanças terminam.

Manutenção de pacotes em ecossistemas de linguagens

Nos ecossistemas de linguagens, tudo é bem simples: há um registro de pacotes, pelo menos um gerenciador de pacotes e uma relação exclusiva e direta entre os dois — o gerenciador baixa e envia os pacotes de e para o registro.

Isso pode ser representado pelo diagrama a seguir: um exemplo geral de qualquer repositório de pacotes à esquerda e um exemplo específico do npm à direita.

Manutenção de pacotes em repositórios de distribuições

Já no caso das distribuições em repositórios de imagens, as coisas são um pouco mais complicadas. Uma distribuição pode usar vários repositórios, gerenciadores de pacotes e ferramentas de envio. A escolha do repositório, do gerenciador e da ferramenta depende da versão da distribuição, do escopo dela (main, contribuições, non-free, comunidade) e de outros fatores.

Isso pode ser representado pelo exemplo a seguir: um repositório de pacotes genérico para qualquer distribuição e versão à esquerda, e várias versões do Debian à direita.

Cada versão do Debian usa o repositório adequado à versão especificada.

Nem todos os pacotes e suas versões estão disponíveis em todos os repositórios. Algumas distribuições permitem backport de pacotes (instalar em uma versão um pacote disponível apenas para outro tipo de versão), e alguns pacotes podem ser adicionados diretamente a uma versão da distribuição por meio de um repositório externo — como um arquivo pessoal de pacotes (PPA) no Ubuntu — em vez de usar o gerenciador de pacotes nativo. Essa relação complexa entre pacotes e distribuições contrasta com a relação simples entre registros e gerenciadores de pacotes, bem menos sujeita aos problemas de versionamento descritos.

As complexidades da correção de problemas de segurança em contêineres

As equipes de segurança da maioria das distribuições mantêm correções de segurança apenas para alguns componentes. Por exemplo, o Debian fornece correções de segurança oficialmente apenas para seus componentes principais, conforme descrito na documentação. Isso acontece porque é complicado fazer a triagem das diferentes imagens ao longo do tempo.

Como mencionamos, as imagens são empacotadas a partir do código-fonte, geralmente armazenado separadamente em bibliotecas de código aberto. Depois de empacotada, armazenada e mantida em seu próprio repositório, a imagem segue um ciclo de versões independente da biblioteca de origem, que também continua evoluindo em seu próprio ritmo. Isso significa que uma vulnerabilidade pode existir na biblioteca, mas não na imagem. A vulnerabilidade pode ter surgido em uma versão posterior da biblioteca e, nesse caso, nunca afetaria a imagem já empacotada. O inverso também pode acontecer.

Quando uma vulnerabilidade de segurança é descoberta em uma biblioteca usada para criar uma imagem, cabe às equipes de segurança fazer a triagem adequada: verificar se a vulnerabilidade realmente existe e se a composição da própria imagem faz com que ela seja considerada vulnerável.

As versões da maioria das distribuições mais antigas e consolidadas não costumam passar por grandes atualizações; em geral, recebem pequenas atualizações e correções de segurança para novas vulnerabilidades. 

Distribuições muito antigas e fora de suporte (EOL), assim como distribuições recém-lançadas (versões edge que talvez ainda não estejam sob a responsabilidade da equipe de segurança), muitas vezes são consideradas sem manutenção pela maioria das distribuições (o Debian 7, por exemplo, está fora de suporte). Quando uma vulnerabilidade afeta a versão X de um pacote disponível apenas em versões EOL ou muito recentes, ela pode não aparecer nos avisos de segurança da distribuição. Por isso, o nível de suporte de segurança da distribuição para versões EOL e de ponta não necessariamente reflete seu estado real de segurança. Nesses casos, as informações disponíveis não são suficientes para a Snyk detectar todas as vulnerabilidades, e algumas vulnerabilidades críticas podem passar despercebidas.

Por que minha distribuição Linux não é compatível?

Cada imagem baseada em uma distribuição compatível é verificada em nossa base de dados de vulnerabilidades de acordo com a distribuição e a versão. Depois da verificação, listamos as vulnerabilidades com detalhes sobre cada uma e sua origem, se há uma correção disponível, quais distribuições e versões são afetadas e a partir de qual versão o problema foi corrigido.

Durante o processo de coleta de vulnerabilidades, fazemos o possível para acompanhar cada novo lançamento e preparar nosso roadmap. Também monitoramos de perto as atividades e necessidades dos nossos usuários para enriquecer nossa base de dados e estamos sempre disponíveis para conversar pelo endereço support@snyk.io e pela nossa conta no Twitter. Além disso, nos empenhamos especialmente para oferecer suporte às versões LTS dos provedores analisados neste post. Ainda assim, não damos suporte a todas as distribuições existentes. Por exemplo, se sua imagem for baseada em uma distribuição muito antiga ou muito recente, é provável que ela não seja compatível com a Snyk.

Como a Snyk sabe quais alternativas seguras de imagem base recomendar?

Também coletamos dados regularmente de uma ampla variedade de repositórios, buscando várias vezes ao dia todas as tags de cada repositório no Docker Hub para manter as informações atualizadas. Com esses dados, também podemos recomendar correções para a imagem base (ou pai), desde que você tenha vinculado seus projetos da Snyk ao Dockerfile correspondente.

Se você já conhece a análise de aplicações da Snyk, talvez esteja acostumado a encontrar de algumas até dezenas de vulnerabilidades por repositório monitorado ou testado. No ecossistema Linux, porém, os números são diferentes: algumas centenas de vulnerabilidades é algo bastante comum.

Isso pode parecer muita coisa. Por isso, buscamos oferecer recomendações práticas e informações mais úteis sobre a imagem e suas vulnerabilidades. Para isso, pedimos que você forneça o Dockerfile, que costuma fazer parte de um projeto de contêiner.

Ao usar o Snyk para verificar suas imagens, você pode adicionar um link para o código-fonte onde o Dockerfile está armazenado. Depois de verificar o repositório, podemos recomendar medidas de correção com base nos resultados. Saiba mais sobre como vincular seu Dockerfile em nossa documentação.

Com o Dockerfile em mãos, identificamos a imagem base e descobrimos quantas vulnerabilidades vêm dela e quantas foram introduzidas por outras camadas no Dockerfile. Isso ajuda a decidir se você deve ajustar as outras camadas ou substituir a imagem base por outra mais segura.

Para recomendar atualizações relevantes, buscamos e verificamos continuamente dezenas de repositórios e centenas de tags. Em seguida, consultamos nosso banco de dados de imagens em relação ao banco de dados de vulnerabilidades de segurança para encontrar a imagem mais segura disponível com resultados atualizados. Depois, sugerimos tags do repositório para sua imagem base, incluindo:

• uma atualização de versão secundária — como o nome sugere, uma tag de versão secundária mais recente que a atual. Às vezes, uma simples atualização secundária elimina dezenas ou até centenas de vulnerabilidades. Vale a pena conferir, não?

• uma opção de atualização de versão principal — avançar para a próxima versão principal

• uma solução alternativa — recomendamos outras imagens sem relação direta que podem ser adequadas para seu contêiner

Consideramos uma tag alternativa uma candidata à atualização quando atende às seguintes condições:

• Ela tem menos vulnerabilidades de alta gravidade ou a mesma quantidade de vulnerabilidades de alta gravidade, mas menos vulnerabilidades de gravidade média, e a mesma quantidade ou menos vulnerabilidades de baixa gravidade.

• A distribuição do sistema operacional da tag da imagem candidata não pode ser antiga demais, de ponta, sem suporte de longo prazo (LTS) nem instável.

• Como os avisos de segurança das distribuições Alpine estão disponíveis apenas para um pequeno subconjunto de pacotes corrigidos, consideramos que as imagens baseadas em Alpine oferecem pouca visibilidade de segurança. Por isso, não recomendamos tags baseadas em Alpine.

Atualizações alternativas podem usar tags de distribuições diferentes e, por isso, geralmente envolvem mudanças muito mais arriscadas. Ainda assim, queremos fornecer o máximo de informações possível sobre as opções para proteger sua imagem.

Conclusões

Os contêineres são diferentes das bibliotecas, o que torna a segurança e a triagem inegavelmente mais desafiadoras. Ao mesmo tempo, eles estão por toda parte, graças aos seus benefícios evidentes e importantes. Mas isso não significa que você precise lançar contêineres vulneráveis! Com um pouco de planejamento e boas ferramentas de segurança, como o Snyk, você pode simplificar bastante o processo de proteção dos seus contêineres.

De qualquer forma, é importante fazer a triagem dos seus contêineres regularmente para mantê-los o mais seguros possível. Ao descobrir uma vulnerabilidade que exige a substituição da imagem base, considere estes pontos para manter seu contêiner seguro sem comprometer seu funcionamento:

• Verifique se há alguma dependência de um pacote do sistema operacional. Se houver, confirme que a atualização não vai afetá-la.

• Considere o tamanho da imagem.

• Se você optar por uma atualização alternativa, verifique também os comandos ou recursos específicos da distribuição que está usando e atualize-os conforme necessário.

Experimente verificar suas imagens com o Snyk hoje mesmo.