As dez imagens Docker mais populares têm pelo menos 30 vulnerabilidades cada

Boas-vindas ao relatório anual da Snyk, State of Open Source Security 2019. Este relatório está dividido em várias publicações:

• Aumento de 88% nas vulnerabilidades de bibliotecas de aplicações em dois anos

• 81% acreditam que os desenvolvedores devem ser responsáveis pela segurança, mas não têm os recursos necessários

• Quem mantém projetos de código aberto quer garantir a segurança, mas 70% não têm as habilidades necessárias

• As dez imagens Docker mais populares têm pelo menos 30 vulnerabilidades cada

• Vulnerabilidades ReDoS em npm aumentam 143%, e os ataques XSS continuam crescendo

• 78% das vulnerabilidades são encontradas em dependências indiretas, o que torna a correção complexa

Ou baixe nosso PDF caprichado, feito à mão, que reúne todas essas informações e muito mais em um só lugar.

Baixe o Relatório de Segurança de Código Aberto de 2019

Vulnerabilidades conhecidas em imagens Docker

A adoção de contêineres de aplicações está crescendo em ritmo acelerado e deve aumentar mais 40% em 2020, segundo a 451 Research. É comum encontrar bibliotecas de sistema em muitas imagens Docker, pois elas dependem de uma imagem-pai que geralmente usa uma distribuição Linux como base.

As imagens Docker quase sempre trazem vulnerabilidades conhecidas junto com seus muitos benefícios

Analisamos dez das imagens mais populares com os recursos de análise de Docker lançados recentemente pela Snyk.

Os resultados mostram que encontramos versões vulneráveis de bibliotecas de sistema em todas as imagens Docker analisadas. A imagem oficial do Node.js inclui 580 bibliotecas de sistema vulneráveis. Cada uma das demais inclui pelo menos 30 vulnerabilidades conhecidas publicamente.

A Snyk lançou recentemente sua solução de gerenciamento de vulnerabilidades em contêineres para ajudar os desenvolvedores a assumir total responsabilidade pela segurança de suas aplicações em contêineres Docker. Com esse novo recurso, os desenvolvedores podem encontrar vulnerabilidades conhecidas nas imagens-base Docker e corrigi-las com as recomendações de correção da Snyk. A Snyk sugere uma atualização mínima ou imagens-base alternativas com menos vulnerabilidades — ou até mesmo nenhuma.

A correção pode ser simples quando você sabe o que fazer. É possível corrigir vulnerabilidades em 20% das imagens simplesmente recriando a imagem Docker e em 44% delas trocando a imagem-base.

Com base nas análises realizadas por usuários da Snyk, descobrimos que 44% das imagens Docker analisadas tinham vulnerabilidades conhecidas e que havia imagens-base mais recentes e seguras disponíveis. Essa recomendação de correção é exclusiva da Snyk. Os desenvolvedores podem agir para atualizar suas imagens Docker.

A Snyk também informou que 20% das imagens Docker analisadas tinham vulnerabilidades conhecidas que podiam ser reduzidas simplesmente recriando a imagem.

Diferenças nas vulnerabilidades conforme a tag da imagem

A versão atual do runtime Node.js com suporte de longo prazo (LTS) é a versão 10. A imagem com a tag 10 (ou seja, node:10) é, essencialmente, um alias para node:10.14.2- jessie (na época em que fizemos os testes), em que jessie indica uma versão obsoleta do Debian que não recebe mais manutenção ativa.

Se você escolhesse essa imagem como imagem-base no seu Dockerfile, ficaria exposto a 582 bibliotecas de sistema vulneráveis incluídas nela. Outra opção é usar a tag de imagem node:10-slim, que oferece imagens menores, sem dependências desnecessárias (por exemplo, ela não inclui páginas de manual nem outros recursos). No entanto, a node:10-slim ainda incluiria 71 bibliotecas de sistema vulneráveis.

A maioria das vulnerabilidades tem origem na imagem-base selecionada. Por isso, a correção deve se concentrar em atualizar a imagem-base.

A imagem node:10-alpine é uma opção melhor se você quiser uma imagem-base bem pequena, com o mínimo de bibliotecas de sistema. No entanto, embora não tenhamos detectado vulnerabilidades na versão da imagem Alpine que testamos, isso não significa necessariamente que ela esteja livre de problemas de segurança.

O Alpine Linux lida com vulnerabilidades de forma diferente de outras distribuições importantes, que preferem fazer backport de conjuntos de patches. No Alpine, a preferência é por ciclos rápidos de lançamento das imagens, e cada versão inclui uma atualização das bibliotecas de sistema.

Além disso, o Alpine Linux não mantém um programa de avisos de segurança. Isso significa que, se uma biblioteca de sistema tiver vulnerabilidades, o Alpine Linux não emitirá um aviso oficial sobre elas. Em vez disso, se houver uma versão corrigida disponível, o Alpine Linux vai mitigar a vulnerabilidade criando uma nova versão da imagem-base que inclui uma versão atualizada da biblioteca — ao contrário do backport mencionado anteriormente.

Não há garantia de que uma versão corrigida mais recente de uma biblioteca vulnerável ficará disponível imediatamente no Alpine Linux, embora isso aconteça com frequência. Ainda assim, se você puder migrar com segurança para a versão do Alpine Linux sem comprometer sua aplicação, poderá reduzir a superfície de ataque do seu ambiente usando menos bibliotecas.

Na prática, usar uma tag de imagem como node:10 é usar um alias para outra imagem, que muda constantemente à medida que novas versões secundárias e corrigidas da versão 10 são lançadas.

Uma prática adotada por algumas equipes é usar uma tag de versão específica em vez de um alias, para que a imagem-base seja, por exemplo, node:10.8.0-jessie. No entanto, com o lançamento de novas versões do Node 10, há uma boa chance de que essas imagens mais recentes tenham menos vulnerabilidades nas bibliotecas de sistema.

Com os recursos de análise de Docker da Snyk, descobrimos que, quando um projeto usa uma tag de versão específica, como node:10.8.0-jessie, podemos recomendar imagens mais recentes com menos vulnerabilidades.

Vulnerabilidades conhecidas em bibliotecas de sistema

O número de vulnerabilidades relatadas em bibliotecas de sistema está aumentando, afetando algumas das distribuições Linux mais populares, como Debian, Red Hat Enterprise Linux e Ubuntu. Somente em 2018, rastreamos 1.597 vulnerabilidades em bibliotecas de sistema dessas distribuições com CVEs conhecidos atribuídos — mais de quatro vezes o número registrado em 2017.

Ao analisar a distribuição das vulnerabilidades de alta e crítica gravidade, fica claro que esse nível de gravidade continuou aumentando em 2017 e 2018.

Continue lendo:

• Confira o DevSecOps Hub da Snyk para acessar recursos e dicas que você pode colocar em prática.

• Os pacotes do Maven Central dobram; um quarto de milhão de novos pacotes indexados no npm

• Aumento de 88% nas vulnerabilidades de bibliotecas de aplicações em dois anos

• 81% acreditam que os desenvolvedores devem ser responsáveis pela segurança, mas não têm os recursos necessários

• Quem mantém projetos de código aberto quer garantir a segurança, mas 70% não têm as habilidades necessárias

• Vulnerabilidades ReDoS em npm aumentam 143%, e os ataques XSS continuam crescendo

• 78% das vulnerabilidades são encontradas em dependências indiretas, o que torna a correção complexa

• 10 práticas recomendadas de segurança para Docker - conheça as práticas de segurança que você deve seguir ao criar e baixar imagens-base Docker, além de entender como funciona o Docker Content Trust.

• Você é desenvolvedor Java? Este recurso pode ser muito útil: Docker para desenvolvedores Java: 5 coisas que você precisa saber para não comprometer sua segurança

• 10 práticas recomendadas para colocar aplicações web Node.js em contêineres com Docker. Se você desenvolve com Node.js, vai gostar deste passo a passo para criar imagens-base Docker seguras e eficientes para suas aplicações.