No projeto em que atuo na Lambda3, eu estava realizando algumas pesquisas para ver se encontrava algo que ajudasse a reduzir o tempo de build das imagens docker do projeto. Encontrei um post falando sobre algumas técnicas, as quais já estavam sendo utilizadas em nosso pipeline atual, e no fim o autor do post rodava o comando “docker scan” na imagem para mostrar as vulnerabilidades da imagem gerada.

Fiz um teste na imagem que estamos utilizando que usa a imagem mcr.microsoft.com/dotnet/runtime-deps:3.1-alpine como base e para minha surpresa o resultado foi o seguinte:

Testing mcr.microsoft.com/dotnet/runtime-deps:3.1-alpine...

✗ High severity vulnerability found in apk-tools/apk-tools
  Description: Out-of-bounds Read
  Info: https://snyk.io/vuln/SNYK-ALPINE313-APKTOOLS-1533754
  Introduced through: apk-tools/[email protected]
  From: apk-tools/[email protected]
  Image layer: Introduced by your base image (alpine:3.13)
  Fixed in: 2.12.6-r0

Package manager:   apk
Project name:      docker-image|mcr.microsoft.com/dotnet/runtime-deps
Docker image:      mcr.microsoft.com/dotnet/runtime-deps:3.1-alpine
Platform:          linux/amd64
Base image:        alpine:3.13

Tested 23 dependencies for known vulnerabilities, found 1 vulnerability.

Base Image   Vulnerabilities  Severity
alpine:3.13  1                1 high, 0 medium, 0 low

Recommendations for base image upgrade:

Minor upgrades
Base Image     Vulnerabilities  Severity
alpine:latest  0                0 high, 0 medium, 0 low

No link da descrição da vulnerabilidade tem mais detalhes sobre o que ela representa, mas trata-se de uma vulnerabilidade considerada crítica na imagem do alpine que é utilizada como base na imagem da Microsoft. Abrimos uma issue no GitHub e no mesmo dia a Microsoft atualizou a imagem corrigindo a vulnerabilidade. Depois disso, comecei a pesquisar mais sobre vulnerabilidades em imagens docker e encontrei o trivy que de acordo com o GitHub deles “é um scanner simples e abrangente para vulnerabilidades em imagens de contêiner, sistemas de arquivos e repositórios Git, bem como para problemas de configuração”.

Achei interessante a ideia, até por que o docker scan tem um limite de 10 execuções mensais a não ser que você se cadastre no site da snyk que embora o cadastro seja gratuito, seria mais uma credencial para gerenciar caso eu queira colocar essa rotina em um pipeline de build.

O trivy funciona de duas formas:

  • Com servidor: Rodar um servidor de trivy evita que toda vez que você precise rodá-lo em diferentes hosts, você precise baixar o banco de dados dele que tem aproximadamente 30MB.
  • Sem servidor: Rodando local por exemplo, ele vai baixar o banco de dados uma vez e só irá baixar novamente caso tenha atualizações.

Como a imagem que eu estava testando já teve seu problema corrigido, escaneei a imagem node:latest e o relatório ficou bem grande 😱, tirei um print de uma parte pra facilitar:

trivy image --exit-code 1 --severity LOW,MEDIUM,HIGH,CRITICAL node:latest

Veja que o relatório sai bem organizado para visualização e fácil de entender. Não sei por que a imagem de node em sua última versão tem tantas vulnerabilidades, vou dar uma pesquisada depois se alguém fala algo sobre esse assunto.

Mas é isso, para garantir que não sejam adicionadas vulnerabilidades nas imagens, é interessante ou ter essa verificação no processo logo após o build da imagem ou de forma recorrente, afinal não queremos problemas em nossas aplicações não é mesmo?

Referências:

Tem um post da Microsoft explicando sobre porque imagens com vulnerabilidades não são corrigidas imediatamente, vale a leitura para entender quando devemos ficar “preocupados” com relação às vulnerabilidades das imagens.

tags

DockerMicrosoftmicrosserviços

Sergio Prates