Dicas para fortalecer sua estratégia de segurança de imagens de contêiner

Na primeira parte desta série de artigos, vimos as práticas recomendadas de segurança para as imagens base que você pode estar usando. Mas o que acontece com a segurança das imagens de contêiner quando adicionamos outros elementos a elas? Talvez instalemos software adicional de fontes upstream e tenhamos aplicações próprias, com dependências que também precisam ser instaladas. Esses elementos que adicionamos estão sob nosso controle, por isso precisamos assumir a responsabilidade por corrigir as vulnerabilidades que introduzimos.

Crie uma linha de base

Ao criar imagens de contêiner, é uma boa ideia analisar apenas a imagem base antes de fazer qualquer modificação. Assim, você estabelece uma linha de base de segurança para a imagem de contêiner e consegue identificar facilmente quais vulnerabilidades estavam na imagem base e quais foram adicionadas nas camadas seguintes. Se você cria imagens com várias camadas adicionais — talvez uma camada de middleware personalizada e também a aplicação —, também é uma boa prática definir uma linha de base em cada etapa e manter essas imagens separadas. Isso ajuda a identificar claramente a origem das vulnerabilidades.

Defina prioridades

Provavelmente não é realista esperar segurança completa das imagens de contêiner — ou seja, nenhuma vulnerabilidade —, exceto em aplicações muito simples. Como não temos recursos ilimitados para corrigir tudo, precisamos priorizar e decidir quais vulnerabilidades corrigir e quais podemos aceitar.

No entanto, pode ser muito difícil tomar essas decisões quando o scanner aponta um grande número de vulnerabilidades nas imagens. Uma ferramenta de segurança pode gerar tanta informação que acaba sobrecarregando quem a analisa e levando à desconsideração dos resultados ou até à desativação da análise.

Além disso, vulnerabilidades não são uma questão de tudo ou nada. Uma vulnerabilidade específica pode ser um problema apenas em circunstâncias muito particulares ou em uma arquitetura ou plataforma específica. Sem ler os detalhes de cada vulnerabilidade, como podemos decidir quais representam um risco no nosso ambiente?

A priorização não é uma ciência exata e pode se basear em vários fatores. A gravidade, por si só, não informa muito além do impacto potencial. A pontuação CVSS, que considera fatores como a possibilidade de exploração e o impacto, oferece mais contexto. Também podemos considerar a maturidade do código de exploração disponível e, principalmente, a existência de uma correção. Vulnerabilidades de alta gravidade que têm uma exploração disponível e uma correção provavelmente devem ser corrigidas primeiro. As pontuações de priorização da Snyk consideram todos esses fatores ao apresentar vulnerabilidades, para que os desenvolvedores tenham informações claras para embasar suas decisões.

Defina uma estratégia de segurança para imagens de contêiner

Segurança quase sempre envolve uma série de concessões, especialmente entre esforço e risco. Quanto esforço é necessário para corrigir algo, em comparação com o risco de isso se tornar um problema no meu ambiente? Ao decidir como priorizar a correção de vulnerabilidades de segurança, definir uma estratégia costuma ser o primeiro passo. Um exemplo bem simples seria:

• Nenhum CVE de alta gravidade em produção

• Nada com exploração madura

• Aplique as correções disponíveis

Seguindo esses critérios, você provavelmente reduziria bastante o número total de vulnerabilidades na maioria dos casos.

Mitigação de riscos: cada ambiente é diferente

Embora as pontuações ajudem a entender a gravidade, alguns aspectos são, obviamente, subjetivos. Por exemplo, você pode decidir que uma vulnerabilidade de alta gravidade que exige acesso ao shell local representa menos risco no seu ambiente, porque há outros controles para proteger esse acesso. Talvez você use contêineres distroless, que não incluem um shell, e esses controles reduzam o risco.

Entenda seus limites de segurança

Em alguns ambientes, você pode considerar a rede confiável e, por isso, entender que qualquer vulnerabilidade exposta a ela representa menos risco. Esse cenário é problemático na maioria dos ambientes de computação modernos, pois a conectividade é tão complexa que é muito difícil definir limites — a menos que o ambiente seja totalmente isolado, sem conexão externa. Isso é especialmente problemático em ambientes de nuvem. Essa abordagem também não protege contra agentes mal-intencionados internos, que podem representar um risco significativo, sobretudo em organizações maiores. Em geral, é mais seguro considerar todas as redes não confiáveis.

Conheça suas ferramentas

É aí que entra o conhecimento das ferramentas usadas para detectar esses problemas. A maioria das ferramentas de análise de imagens permite filtrar os resultados para configurar quais informações são mais relevantes para você. Isso é especialmente importante ao integrar a análise de segurança aos pipelines de entrega de software. Você não quer que compilações ou implantações falhem continuamente por causa de informações irrelevantes ou de riscos que decidiu mitigar de outras formas. A Snyk oferece a opção --fail-on flag para controlar o status de saída da análise pela CLI, fazendo com que ela retorne uma falha apenas em determinadas circunstâncias. Por exemplo:

1snyk container test purpledobie/mattj-goof --fail-on upgradable

Esse comando só retornará uma falha se encontrar pelo menos uma vulnerabilidade corrigível por atualização na imagem. Ele não falhará se encontrar vulnerabilidades que não podem ser corrigidas ou que podem ser corrigidas com patches.

A Snyk CLI também oferece resultados em JSON para filtragem posterior. Com essa saída, é possível criar filtros complexos usando ferramentas como jq:

1snyk container test purpledobie/mattj-goof --json | jq '.vulnerabilities[] | select(.CVSSv3 | test("AV:N"))'

Este exemplo simples retorna apenas as vulnerabilidades que podem ser exploradas pela rede, filtrando a lista com base no vetor de ataque da pontuação CVSS, que deve estar definido como Network. Com filtros desse tipo, você pode implementar decisões complexas baseadas em políticas no processo de análise.

Automatize a correção

Depois de definir sua estratégia e configurar as ferramentas, automatizar a correção pode reduzir a carga cognitiva dos desenvolvedores — exigindo menos decisões — e também diminuir os recursos necessários. Pull requests automatizados para problemas que se encaixam claramente na estratégia geral e têm correções disponíveis facilitam a correção contínua pelas equipes de desenvolvimento, reservando o trabalho manual para casos excepcionais mais complexos.

Segurança abrangente para imagens de contêiner

A análise de contêineres pode não detectar itens como binários que não fazem parte dos pacotes adicionados durante o processo de compilação. Por isso, ela não deve ser sua única proteção. Também é importante analisar sua base de código e seus Dockerfiles. Em cargas de trabalho de produção, quase certamente você deve adotar o princípio de defesa em profundidade e incluir outras verificações de segurança, como detecção de anomalias em tempo de execução e análise de endpoints.

Mantenha seus contêineres seguros

Há vários aspectos a considerar na segurança de imagens de contêiner, mas esperamos que este artigo tenha ajudado a esclarecer alguns dos primeiros passos. Para verificar a segurança das suas imagens de contêiner, crie uma conta gratuita da Snyk e faça uma análise.