Três etapas para proteger imagens de contêiner

Segurança de imagens de contêiner com Docker

Se você já analisou uma imagem de contêiner em busca de vulnerabilidades, provavelmente encontrou mais do que algumas — talvez centenas ou até milhares. Este guia Segurança de contêineres para equipes de desenvolvimento, escrito em parceria pela Snyk e pela Docker, concentra-se na imagem de contêiner e no software empacotado nela. Você pode baixar aqui a versão em PDF deste guia de segurança de contêineres.

O guia começa explicando por que a segurança de contêineres é importante.  Os contêineres estão cada vez mais populares, mas apresentam riscos de segurança que podem expor empresas a perdas de produtividade, redução nas vendas e até milhões de dólares em multas. Este artigo apresenta nosso processo de três etapas para criar imagens de contêiner seguras. Crie uma conta gratuita da Snyk para encontrar e corrigir facilmente vulnerabilidades em imagens Docker e bibliotecas de código aberto.

Três etapas para proteger imagens de contêiner

Como observamos anteriormente, a segurança de imagens de contêiner não é uma preocupação isolada: ela envolve as equipes de desenvolvimento, segurança e operações. Há várias questões de segurança relacionadas aos contêineres

• A própria imagem de contêiner e o software nela incluído

• A interação entre um contêiner, o sistema operacional do host e outros contêineres no mesmo host

• O próprio sistema operacional do host

• Questões de rede e armazenamento de contêineres

• Segurança em tempo de execução, geralmente em clusters do Kubernetes

Cada um desses tópicos merece um guia próprio para ser abordado como merece, e todos, exceto o primeiro, já contam com um ou mais guias. Este guia se concentra na imagem de contêiner e no software empacotado nela.

Em linhas gerais, há três etapas essenciais para criar uma imagem de contêiner segura:

1. Proteja seu código e suas dependências

2. Comece com uma imagem base mínima de uma fonte confiável

3. Gerencie as ferramentas e os pacotes adicionados às imagens durante todo o ciclo de desenvolvimento

Vamos analisar cada uma dessas etapas com um pouco mais de detalhe para entender como essa abordagem pode criar imagens de contêiner seguras.

1. Proteja seu código e suas dependências

Entregar seus aplicativos nativos da nuvem com mais rapidez provavelmente é um dos principais motivos para criar um contêiner, e seus aplicativos são essenciais para a organização. Até pouco tempo atrás, a segurança de aplicações começava e terminava no código. Embora os contêineres e outras práticas modernas de desenvolvimento tenham ampliado o significado de “código da aplicação”, essa continua sendo uma área de preocupação.

Felizmente, essa é a parte das imagens de contêiner que os desenvolvedores conseguem controlar mais diretamente e, esperamos, que entendem melhor. Ainda assim, rastrear todas as dependências do código e descobrir como corrigir problemas de segurança não é uma tarefa simples. Se você tem acesso ao próprio código-fonte, use ferramentas específicas, como Snyk Open Source, para realizar análise de composição de software (SCA) e testes estáticos de segurança de aplicações (SAST) e analisar seu código e suas dependências. Em aplicações modernas, é comum que as dependências de código aberto de terceiros representem a maior parte das linhas de código.

Figura 2: A quantidade de código-fonte aberto em um aplicativo pode facilmente superar a quantidade de código proprietário.

Identificar problemas no início do desenvolvimento e integrar ferramentas de segurança ao código-fonte abre caminho para automatizar esse processo, independentemente da etapa de conteinerização. É possível analisar um contêiner e alguns tipos de código, mas detectar esses problemas diretamente nos commits do Git, nos pipelines e nos repositórios provavelmente se encaixa melhor no fluxo de trabalho dos desenvolvedores.

2. Comece com uma imagem base mínima de uma fonte confiável

Por que imagens pequenas são importantes?

A imagem base — a linha FROM no Dockerfile — é uma das considerações mais importantes quando o assunto é segurança. Felizmente, muitos fornecedores confiáveis oferecem conteúdo fácil de usar. O Docker Hub é, de longe, o ponto de partida mais popular para encontrar imagens base de contêiner.

O Docker Hub tem mais de 3,8 milhões de imagens disponíveis e mais de 7 milhões de repositórios. É bastante movimentado e recebe cerca de 11 bilhões de downloads por mês. Algumas dessas imagens são Official Images, publicadas pela Docker como uma seleção curada de repositórios de código aberto da Docker e soluções “drop-in”.

A Docker também oferece imagens publicadas por Verified Publishers. Essas imagens de alta qualidade são publicadas e mantidas diretamente por empresas que a Docker verifica como Verified Publishers. As diretrizes que a Docker estabelece para esses editores verificados são um ótimo ponto de partida para definir suas próprias práticas recomendadas internas para imagens de contêiner.

Figura 3: Imagens oficiais no Docker Hub. Observe o selo “Official” e as atualizações recentes.

É fácil acessar o Docker Hub e encontrar uma imagem disponível publicamente que atenda ao seu caso de uso, mas você precisa prestar atenção à procedência das imagens escolhidas. Assim como você não baixaria nem instalaria software de um site não confiável, provavelmente não gostaria de usar imagens enviadas ao Docker Hub por usuários que não conhece e em quem não confia.

Ao usar imagens que fazem parte do programa Official da Docker, ou se você conhece e consegue verificar a origem e o conteúdo de imagens de terceiros — talvez usando algo como o Notary para verificar assinaturas digitais —, terá algum nível de garantia de qualidade. Mas, para reduzir ainda mais o número de vulnerabilidades e ter mais controle sobre o que é empacotado nos contêineres, vá além e escolha imagens base mínimas adequadas às suas necessidades.

Como exemplo, na figura 3 acima, há um repositório Python. Você certamente pode criar seu aplicativo Python com ele, e quase certamente vai funcionar. Isso porque a imagem no Docker Hub foi projetada para facilitar o uso em diversos casos e é bem mantida. Mas há mais de 1.000 outras imagens Python nesse repositório.

Você deve simplesmente usar o que vem com a _python, fácil de lembrar, ou há imagens menores que atendam às suas necessidades e também reduzam sua superfície de ataque_? Como você deve imaginar, do ponto de vista da segurança, quase certamente há opções melhores.

O tamanho da imagem de contêiner importa, e não apenas para facilitar a portabilidade e agilizar os downloads. A imagem identificada pela tag python é simples de usar porque inclui muitas bibliotecas de sistema operacional e pacotes de desenvolvimento pré-instalados. Isso significa que provavelmente funcionará muito bem em diversos projetos e terá tudo o que você precisa para compilar código e dependências. Porém, os scanners de vulnerabilidades também podem apontar uma longa lista de problemas a investigar.

Figura 4: Uma comparação entre duas imagens baseadas em Debian para Python 3.x.

Talvez você esteja se perguntando por que ambas as imagens ainda têm vulnerabilidades, especialmente vulnerabilidades de alta gravidade. Ao analisar essas vulnerabilidades específicas, porém, você verá que fazem parte dos pacotes do sistema operacional subjacente; nenhuma tem correção disponível e não há exploits conhecidos em circulação. Além disso, como parte do processo de verificação de editores da Docker, as duas imagens foram atualizadas com as versões mais recentes de todos os pacotes nos últimos dias. Portanto, são bem mantidas.

Também precisamos considerar o contexto: muitas vezes, as vulnerabilidades que aparecem estão em ferramentas de desenvolvimento que você provavelmente removeria da versão de produção da imagem, como curl, bibliotecas de desenvolvimento, shells ou gerenciadores de pacotes. Mas, com o tempo, é muito mais provável que novas vulnerabilidades afetem a imagem Python maior do que a versão mais enxuta.

Como colocar em prática a segurança de imagens de contêiner: escolha da imagem base

Como dissemos antes, “comece com imagens enxutas” é um conselho que você encontra em todo lugar. Mas uma das razões pelas quais Docker e Snyk se uniram é ajudar você a transformar esse conselho em ação. O recurso integrado de análise de vulnerabilidades do Docker Desktop pode até fazer parte do trabalho de seleção da imagem base para você!

Vamos continuar com o exemplo de Python para ver como podemos trocar a imagem Python pela python:3-slim-buster usando o recurso de análise de vulnerabilidades da Docker, desenvolvido com a tecnologia da Snyk. Se quiser, você pode seguir estas etapas.

Primeiro, vamos começar com um caso simples e usar a imagem python para criar uma imagem de contêiner bem básica. Este é o Dockerfile que vamos usar:

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Não dá para ser muito mais simples do que isso. O arquivo hello.py é uma linha bem simples com uma instrução print (“Hello, World!”).

Em seguida, vamos criar a imagem e analisá-la:

$> docker build -t hello-python .

[+] Building 67.4s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.4s => => transferring dockerfile: 36B 0.1s => [internal] load .dockerignore 0.4s => => transferring context: 2B 0.1s => [internal] load metadata for docker.io/library/python:latest 1.6s => FROM [1/1] FROM docker.io/library/python 65.1s
...
=> exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:3a92e9... 0.0s => => naming to docker.io/library/hello-python 0.0s

$> docker run hello-python
Hello, World!

$> docker scan hello-python -f Dockerfile
/ Analyzing docker dependencies for hello-python/Dockerfile

Organization: snyk-pmm Package manager: deb
 Target file: Project name: Docker image: Base image:
Dockerfile docker-image|hello-python hello-python
python

Tested 431 dependencies for known issues, found 268 issues. Base Image Vulnerabilities Severity
python:latest 268 6 high, 34 medium, 228 low

Recommendations for base image upgrade:
Alternative image types
Vulnerabilities Severity
75 1 high, 10 medium, 64 low
Base Image
python:3-slim-buster
python:3.9-rc-slim-buster 75 1 high, 10 medium, 64 low

Observe primeiro que o resultado aponta 431 dependências e 268 problemas na imagem. Omitimos as vulnerabilidades individuais para resumir — vamos analisá-las daqui a pouco. Não acrescentamos nada de interessante à imagem base python, então as 268 vulnerabilidades vêm da imagem base, como também é possível ver no resultado.

No fim do resultado, porém, recebemos recomendações de imagens base que podem melhorar nossa postura de segurança. Mais especificamente, aparece a imagem python:3-slim-buster mostrada anteriormente. Foi exatamente assim que chegamos à comparação original. Já podemos ver que essa nova imagem elimina mais de 70% das vulnerabilidades da imagem python inicial e reduz o total a uma vulnerabilidade de alta gravidade. Mesmo assim, vamos criar e analisar a imagem novamente para confirmar.

A alteração no Dockerfile é simples: basta mudar a linha FROM. Vamos salvar uma cópia separada chamada Dockerfile.slim.

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Depois, podemos criar e analisar a imagem novamente com uma tag slim para manter nossas imagens separadas:

```
$> docker build -t hello-python:slim . -f Dockerfile.slim

[+] Building 21.0s (8/8) FINISHED
=> [internal] load .dockerignore                                        0.1s
=> => transferring context: 2B                                          0.0s
=> [internal] load build definition from Dockerfile.slim                0.1s
=> => transferring dockerfile: 135B                                     0.0s
=> [internal] load metadata for docker.io/library/python:3-slim-buster  11.5s                                                                            
...
=> exporting to image                                                   0.0s                           
=> => exporting layers                                                  0.0s                            
=> => writing image sha256:63768699.                                    0.0s                                          
=> => naming to docker.io/library/hello-python:slim                     0.0s                                                         

$> docker run hello-python:slim
Hello, World!

$> docker scan hello-python:slim -f Dockerfile.slim

Package manager:  deb
Target file:      Dockerfile.slim
Project name:     docker-image hello-python
Docker image:     hello-python:slim
Base image:       python:3-slim-buster
Licenses:         enabled

Tested 94 dependencies for known issues, found 75 issues.

According to our scan, you are currently using the most secure version of the selected base image
```

Desta vez, você pode ver que a análise completa encontrou apenas 94 dependências e uma única vulnerabilidade de alta gravidade. É assim que Docker e Snyk ajudam você a encontrar imagens base melhores. Como você pode imaginar, não cobrimos todas as imagens do Docker Hub, mas cobrimos a maioria das imagens base oficiais mais populares.

3. Gerencie todas as camadas entre a imagem base e seu código

Analisamos as imagens base em detalhe porque elas exigem atenção especial. Ao criar suas próprias camadas sobre a imagem base, você herda tudo o que vem nela, e uma imagem enxuta geralmente reduz o esforço necessário para proteger o ambiente. Mas e todas as camadas que você adiciona ao contêiner? Se começar com uma imagem enxuta, provavelmente precisará adicionar ferramentas e bibliotecas, além do seu código e de vários componentes necessários para tudo funcionar. É preciso monitorar vulnerabilidades em todos eles.

A boa notícia é que você controla diretamente essas camadas intermediárias, ou seja, tudo o que vem depois da primeira linha FROM e antes das linhas finais do Dockerfile, nas quais você configura a execução do código. Mais especificamente, estamos interessados nos comandos RUN, COPY e ADD dos Dockerfiles, pois são eles que instalam componentes. Tecnicamente, seu código também pode estar em alguma dessas camadas intermediárias, mas, por uma questão de conceito, vamos chamar seu código de camada final, principalmente porque já tratamos dele na etapa 1.

Figura 5: As camadas intermediárias de uma imagem de contêiner

Um dos maiores desafios para gerenciar vulnerabilidades nessas camadas intermediárias é decidir o que priorizar em cada etapa do ciclo de vida.

Em cada etapa, talvez você precise de conjuntos diferentes de ferramentas. Mas, à medida que as imagens avançam para produção, remova tudo o que não for absolutamente necessário para executar sua aplicação. Personalizar as imagens começando com uma imagem base mínima e adicionando as ferramentas necessárias facilita muito a remoção dessas ferramentas depois: basta excluí-las do Dockerfile e recriar a imagem. Melhor ainda, use compilações em várias etapas para reunir todas essas etapas em um único processo de compilação automatizado.

Como priorizar a correção de vulnerabilidades de segurança em contêineres

Dito isso, você ainda vai encontrar vulnerabilidades de segurança e precisará decidir como lidar com elas. Zerar as vulnerabilidades é ótimo na teoria, mas, na prática, provavelmente não é viável nem compensa o tempo investido.

Veja uma sugestão de ponto de partida para as etapas tradicionais de desenvolvimento, testes e produção. Seus processos de produção de software provavelmente são mais complexos, mas você pode adaptá-los conforme necessário.

• Comece pelas imagens de desenvolvimento
  Imagens de desenvolvimento provavelmente terão mais vulnerabilidades nas camadas intermediárias, pois costumam precisar de mais ferramentas e pacotes de suporte. A boa notícia é que, SE você criar imagens em etapas e as imagens de produção não incluírem todos esses extras, talvez seja seguro ignorar muitas das vulnerabilidades nessa fase. Parte dessa decisão depende de conseguir rastrear as dependências instaladas no contêiner e comparar essas informações com o que você sabe ser necessário no ciclo interno de desenvolvimento. É bastante comum encontrar uma vulnerabilidade em uma biblioteca instalada como dependência de outra dependência, que por sua vez é dependência de outra… você precisa conseguir determinar se basta remover um dos pacotes de desenvolvimento para eliminar a vulnerabilidade.
  
  

  No exemplo abaixo, temos uma aplicação Ruby. É comum incluir o SQLite com o Ruby para simplificar o desenvolvimento, mas provavelmente você não usaria esse mesmo banco de dados SQLite em produção. Sabendo disso e tendo em mãos os detalhes certos da verificação de vulnerabilidades do contêiner, você pode decidir ignorar as vulnerabilidades nas bibliotecas instaladas com o SQLite durante o desenvolvimento. Vamos ver como a verificação do Docker fornece essas informações e outros detalhes que simplificam bastante essa tarefa.
  

  

• Enxugue as imagens de teste
  Imagens de teste: na prática, não são muito diferentes das imagens de desenvolvimento, pelo menos quando se trata de avaliar vulnerabilidades. Se você sabe que uma vulnerabilidade está em um pacote de teste que não estará na imagem de produção, pode optar por ignorá-la. Este é um bom momento para comparar os resultados da verificação com os da etapa de desenvolvimento, especialmente se você optou por ignorar vulnerabilidades graves nessa etapa. As vulnerabilidades das imagens de desenvolvimento realmente desapareceram nos testes? Se sim, seu processo está funcionando. Caso contrário, talvez seja hora de voltar e ajustar sua imagem de desenvolvimento ou as etapas de compilação.

• Garanta a qualidade das imagens de produção
  Imagens de produção: são as imagens críticas, pois estarão em execução em algum ambiente e possivelmente expostas ao mundo externo. Mesmo assim, chegar a zero vulnerabilidades pode ser um desafio, ainda que você enxugue a imagem e remova tudo o que for possível. Em muitos casos, o objetivo é automatizar o processo de lançamento. Sem dúvida, você deve corrigir vulnerabilidades de alto risco, especialmente as que têm exploits conhecidos. Mas um dos motivos para verificar também as imagens das etapas de desenvolvimento e teste é reduzir as surpresas na hora do lançamento. Se você mitigou os riscos desde o início, a principal função da verificação em produção será encontrar vulnerabilidades novas que surgiram recentemente.

Vamos ver outro exemplo para entender como você pode usar o Docker e a Snyk para ajudar com as camadas intermediárias.

Exemplo prático: priorizar correções de vulnerabilidades introduzidas pelo usuário

Neste exemplo, vamos apresentar algumas técnicas práticas de “camadas intermediárias” que você pode usar com os recursos de verificação de vulnerabilidades do Docker, baseados na Snyk. Primeiro, desta vez vamos usar uma aplicação um pouco mais interessante. É um app Ruby, mas isso não é tão importante para estes exercícios.

Aqui está nosso Dockerfile:

```
FROM ruby:2.5.1

RUN apt-get update && \
  apt-get install -y git vim && \
  rm -rf/var/lib/apt/lists/*

RUN gem update --system 3.0.4 && \
  gem install bundler -V '2.0.2'

WORKDIR /usr/src/app/alpha-blog

COPY . .

ENV BUNDLER VERSION 2.0.2

RUN bundle update && \
  bundle install && \
  rails db:setup && \
  rails db:migrate

EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]
```

Ainda é um Dockerfile bem simples, no qual adicionamos várias camadas sobre a imagem principal do Ruby:

• A primeira linha RUN adiciona alguns utilitários para fazer desenvolvimento local dentro da imagem

• Em seguida, atualizamos e preparamos os principais componentes do Ruby

• Nosso código é copiado com o comando COPY . .

• Nosso projeto Rails é configurado com os comandos RUN bundle…

Se você está pensando “Instalar git e vim em uma imagem parece uma escolha estranha”, você tem razão. Não faça isso. O laboratório completo mencionado na nota anterior conta o histórico desta imagem e explica por que esses itens estão aqui.

Embora não seja muito complicado entender o que está acontecendo, como você pode imaginar, cada uma dessas linhas do Dockerfile acaba instalando bastante coisa e pode adicionar novas vulnerabilidades à imagem.

Podemos compilar esta imagem e testá-la da mesma forma que antes:

```
$> docker build -t blog .

[+] Building 111.5s (11/11) FINISHED
.
.
.
=> [6/6] RUN bundle update && bundle install && 
  rails db:setup && rails db:migrate 108.8s
=> exporting to image                                           1.6s
=> => exporting layers                                          1.6s 
=> => writing image sha256:0b7c017032e301429...433c23a5         0.0s                                  
=> => naming to docker.io/library/blog                          0.0s                 

$> docker scan blog -f Dockerfile

Testing blog...
.
.
.
X High severity vulnerability found in bzip2
  Description: Out-of-bounds Write
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-BZIP2-450801
  Introduced through: bzip2@1.0.6-8.1, bzip2/libbz2-dev@1.0.6-8.l, imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-11+deb9u6,meta-common-packages@meta
  From: bzip2@1.0.6-8.1
  From: bzip2/libbz2-dev@1.0.6-8.1
  From: imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-ll+deb9u6>imagemagick/libmagickcore-6.q16-dev@8:6.9.7.4+dfsg-1l+deb9u6 › bzip2/libbz2-devel.0.6-8.1
  and 1 more..
  Introduced by your base image (ruby:2.5.1)

X High severity vulnerability found in apt/libapt-pkg5.0
  Description: Arbitrary Code Injection
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-APT-407402
  Introduced through: apt/libapt-pkg5.0@1.4.8, apt@l.4.8
  From: apt/libapt-pkg5.001.4.8
  From: apt@l.4.8 > apt/libapt-pkg5.001.4.8
  From: apt@l.4.8
  Introduced by your base image (ruby:2.5.1)
  Fixed in: 1.4.9

Organization:      snyk-pmm
Package manager:   deb
Target file:       Dockerfile
Project name:      docker-image|blog
Docker image:      blog
Base image:        ruby:2.5.1
Licenses:          enabled

Tested 413 dependencies for known issues, found 871 issues.

Base Image     Vulnerabilities   Severity
ruby:2.5.1     867               48 high, 237 medium, 582 low

Recommendations for base image upgrade:

Minor upgrades
Base Image     Vulnerabilities   Severity
ruby:2.5       257               6 high, 34 medium, 217 low

Alternative image types
Base Image                       Vulnerabilities   Severity
ruby:2.5-slim                    53                0 high, 5 medium, 48 low
ruby:2.7.0-slim-buster           61                1 high, 8 medium, 52 low
ruby:2.7.0-preview3-slim-buster  63                1 high, 9 medium, 53 low
ruby:2.7.0-preview2-slim         63                1 high, 9 medium, 53 low

Está claro que quem criou este Dockerfile não seguiu os conselhos da seção anterior: são 871 vulnerabilidades, e nossa imagem principal já começa com 867! Vamos ter que encontrar essa pessoa e dar a ela uma cópia deste guia. Mas, por enquanto, nosso foco é descobrir se algum dos nossos comandos do Dockerfile adicionou vulnerabilidades. A diferença entre o total de problemas e os problemas da imagem base indica que há pelo menos quatro vulnerabilidades que precisamos corrigir.

O comando docker scan pode nos ajudar a restringir a busca rapidamente, ignorando todas as vulnerabilidades da imagem base com a opção –exclude-base. Veja outra verificação e um trecho da saída ao excluir as vulnerabilidades da imagem base:

A opção —exclude-base exige que o Dockerfile seja incluído na verificação (com a opção -f Dockerfile que estamos usando)

X High severity vulnerability found in curl/libcurl3
  Description: Buffer Overflow
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-CURL-466505
  Introduced through: curl@7.52.1-5+deb9u7, curl/libcurl4-openssl-dev@7.52.1-5+deb9u7, gitel:2.11.0-3+deb9u7
  From: curl@7.52.1-5+deb9u7 > curl/libcurl3@7.52.1-5+deb9u7
  From: curl/libcurl4-openssl-dev@7.52.1-5+deb9u7 › curl/libcurl3@7.52.1-5+deb9u7
  From: curl@7.52.1-5+deb9u7
  and 2 more..
  Introduced in your Dockerfile by `RUN apt-get update && apt-get install -y git vim && rm -rf/var/lib/apt/lists/*`
  Fixed in: 7.52.1-5+deb9u10

Organization:     snyk-pmm
Package manager:  deb
Target file:      Dockerfile
Project name:     docker-image|blog
Docker image:     blog
Base image:       ruby:2.5.1
Licenses:         enabled

Tested 413 dependencies for known issues, found 70 issues.

Assim fica bem mais fácil de gerenciar: 70 problemas em vez de 871. Se você percorrer a lista de vulnerabilidades detectadas, também verá uma linha que começa com “Introduced in your Dockerfile by”. Também temos o caminho da dependência, que permite rastrear uma vulnerabilidade específica até sua origem. Mas ver o comando exato do Dockerfile, em vez de uma interpretação enigmática dele, nos leva direto ao ponto em que a vulnerabilidade foi introduzida.

Ainda assim, 70 vulnerabilidades são muitas para resolver de uma só vez.

Com frequência, as equipes de segurança e desenvolvimento querem começar pelas vulnerabilidades corrigíveis de alta severidade.

Também é muito fácil obter esse nível de detalhe aproveitando a opção de saída JSON e aplicando alguns filtros com o utilitário de linha de comando para JSON, jq (observe que o jq aceita linhas em branco dentro do comando):

```
$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

[
  {
    "packageName": "curl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "7.52.1-5+deb9u7",
    "nearestFixedInVersion": "7.52.1-5+deb9u13"
  },
...  
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Integer Overflow or Wraparound",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Buffer Overflow",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  }
]
```

Pronto! Na visualização final, temos 36 vulnerabilidades listadas, todas de alta severidade e com correção disponível, além do comando do Dockerfile e da versão corrigida. A partir daqui, devemos conseguir corrigir essas vulnerabilidades. Se você não conhece o comando jq, isso pode parecer complexo. Veja um breve resumo do que fizemos. Mas o jq é uma ferramenta bastante poderosa e vale a pena dedicar um tempo para aprendê-la:

Para começar, adicionamos a opção de saída --json ao comando docker scan e, em seguida, usamos o jq para:

• Selecionamos apenas as vulnerabilidades da saída.

• Selecionar apenas as vulnerabilidades que têm correção e, da mesma forma, as que têm severidade “alta”

• Simplificar um pouco a saída, mostrando apenas alguns campos da vulnerabilidade

Conclusões

A segurança de contêineres é um tema amplo. Mesmo ao limitar o escopo à segurança de imagens, há vários vetores de segurança que precisam ser analisados. Mas, na hora de proteger suas imagens, estes são os principais pontos a considerar:

• Comece com imagens base de um provedor confiável. Use assinaturas digitais para verificar a autenticidade.

• Sempre que possível, escolha imagens base mínimas, com apenas os pacotes básicos do sistema operacional e a versão desejada do seu framework, e adicione o restante a partir daí.

• Verifique suas imagens em busca de vulnerabilidades desde o início e com frequência. Crie suas próprias imagens base aprovadas, mantidas ativamente e aprovadas em todas as verificações de segurança, mas verifique-as novamente sempre que novas imagens forem criadas.

• Faça verificações em vários pontos do ciclo de vida do software: nas estações de trabalho, no CI, nas imagens armazenadas em registros e nos contêineres/pods em execução nos clusters.

• Ao escolher ferramentas de verificação, vá além da lista de vulnerabilidades que elas apresentam:

  • A ferramenta vai além de apenas relatar vulnerabilidades e avisa se há uma imagem base mais nova ou melhor para usar?

  • Se uma compilação falhar por causa de vulnerabilidades detectadas, a ferramenta fornecerá informações suficientes para que desenvolvedores e equipes de DevOps corrijam os problemas?

  • A ferramenta oferece a flexibilidade necessária para configurar seus controles de segurança?

  • Uma solução única nem sempre atende a todos: provavelmente, seus desenvolvedores precisarão de mais ferramentas na imagem do que você permitiria em produção. Por isso, talvez você precise de imagens diferentes em cada etapa do ciclo de vida do desenvolvimento. Automação, CI e Dockerfiles que dão suporte a essas etapas permitem estabelecer controles de segurança adequados e encontrar o equilíbrio certo entre segurança e produtividade, gerando os maiores benefícios.

Comece a proteger suas imagens de contêiner com Docker e Snyk: inscreva-se agora!