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...
Image layer: Introduced by your base image (alpine:3.13)
Project name:      docker-image|mcr.microsoft.com/dotnet/runtime-deps
Docker image:      mcr.microsoft.com/dotnet/runtime-deps:3.1-alpine
Base image:        alpine:3.13
Tested 23 dependencies for known vulnerabilities, found 1 vulnerability.
alpine:3.13  1                1 high, 0 medium, 0 low
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?
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.