Skip to main content

80% dos desenvolvedores não estão cuidando da segurança do Docker

Escrito por

William Henry

Docker report DARK

17 de abril de 2019

0 minutos de leitura

Boas-vindas ao relatório sobre segurança do Docker: Antecipe a segurança do Docker.Este relatório está dividido em várias publicações:

Ou baixe nosso belo relatório em PDF, feito com todo o cuidado, que reúne todas essas informações e muito mais em um só lugar.

Responsabilidade pela segurança de contêineres

Quando o Docker é parte integrante do seu ecossistema, alguém precisa assumir a responsabilidade por ele. A maioria concorda que essa responsabilidade é compartilhada. Quando perguntamos quem é responsável pela segurança de contêineres (com a possibilidade de selecionar mais de uma resposta), a maioria dos participantes afirmou que os desenvolvedores devem cuidar da segurança dos contêineres (68%), seguidos pelas equipes de operações (39%).

Gráfico de barras perguntando quem é responsável pela segurança de imagens de contêiner: desenvolvedores, 68%; operações, 39%; equipe de segurança, 27%; outros, 3%; ninguém, 12%.

Embora a responsabilidade pela segurança seja compartilhada em DevOps — ou, melhor ainda, em DevSecOps —, vemos que a maioria acredita que os desenvolvedores têm um papel fundamental. Isso é semelhante ao que observamos em relação à responsabilidade pela segurança do código de aplicações. De acordo com O panorama da segurança do código aberto, 81% dos participantes acreditam que os desenvolvedores devem ser responsáveis pela segurança de suas aplicações.

As organizações também podem considerar trabalhar com o fornecedor de confiança das imagens base para gerenciar parte dos riscos de segurança ao usar pipelines de CI/CD. Fornecedores como a Red Hat disponibilizam imagens verificadas e assinadas. Eles também respondem rapidamente a CVEs em imagens base, o que pode acionar a recriação de imagens de aplicações nos pipelines de CI/CD. Isso não elimina a necessidade de fazer varreduras ao longo do ciclo de vida de DevOps, mas reduz o intervalo entre imagens vulneráveis em produção e imagens seguras. Compartilhar o risco com terceiros pode ajudar a reduzi-lo como um todo.

Testes de segurança na camada do sistema operacional

Infelizmente, apenas 19% dos desenvolvedores afirmam testar suas imagens Docker durante o desenvolvimento para detectar vulnerabilidades na camada do sistema operacional. Isso significa que mais de 80% dos desenvolvedores não antecipam a segurança para testar suas imagens durante o desenvolvimento — e descobrir vulnerabilidades mais tarde custa mais caro.

Além disso, metade dos usuários (50%) não faz nenhum tipo de varredura na camada do sistema operacional de suas imagens Docker. É importante saber o que há nessa camada. Usar imagens Docker às cegas é muito perigoso, pois sem dúvida você acabará incorporando inúmeras vulnerabilidades. Você pode reduzir esse risco facilmente fazendo uma varredura e identificando primeiro as vulnerabilidades conhecidas em cada imagem que pretende usar.

Gráfico de barras horizontal que pergunta quando as imagens Docker são verificadas em busca de vulnerabilidades no sistema operacional: 50% dizem que não fazem isso, 31% verificam no momento da compilação e 19%, durante o desenvolvimento.

Com uma ferramenta de varredura de imagens Docker, como a oferecida pela Snyk, é possível detectar imagens vulneráveis durante todo o ciclo de desenvolvimento. O processo começa localmente: quando um desenvolvedor seleciona uma imagem Docker, a varredura impede que imagens vulneráveis entrem no seu ambiente. Repita a varredura em todas as etapas, até o fim do pipeline de CI/CD, para impedir que uma imagem com vulnerabilidades conhecidas chegue à produção.

É natural que novas vulnerabilidades em imagens sejam descobertas com o tempo, por isso é fundamental acompanhar suas imagens em produção. O tempo mediano entre a descoberta e a divulgação de uma vulnerabilidade é de 2,5 anos. Atualmente, 9% dos usuários afirmam fazer varreduras nas imagens em produção. Uma imagem pode estar segura quando é implantada em produção, mas, a partir daí, mais de 90% dos desenvolvedores não saberiam qual é o estado atual de segurança dessas imagens.

Como descobrir vulnerabilidades

Também perguntamos como as pessoas descobrem que um contêiner em execução contém vulnerabilidades divulgadas. Provavelmente, 45% nunca verificam. Uma parcela considerável dos participantes (15%) consulta bancos de dados públicos, como o banco de dados de CVEs. Mas lembre-se de que esse banco é apenas a ponta do iceberg. O processo de registro de uma CVE pode levar várias semanas, e muitas vulnerabilidades talvez nem cheguem a ser registradas como CVE, embora ainda representem um grande risco para o seu sistema.

Gráfico de barras pergunta como as pessoas descobrem novas vulnerabilidades em contêineres em produção: ferramentas de varredura 33%, equipe de segurança 22%, bancos de dados 15%, outros 3%, provavelmente não vão descobrir 45%.

Continue lendo:

Baixe o relatório agora!

Leia mais

feature customer snowflake
Article

Segurança desde o início: conheça a integração do Snyk Studio com o Snowflake Cortex Code

O Snyk Studio se integra ao Snowflake Cortex Code para detectar vulnerabilidades em código gerado por IA, dependências e contêineres durante o desenvolvimento.

blog feature pypi spoof
Article

A Snyk AI Security Platform completa, grátis para mantenedores de projetos open source

Mantenedores de projetos open source estão sobrecarregados com relatórios reais de vulnerabilidades e precisam de ajuda para priorizar, corrigir e lançar correções mais rápido. O Secure Developer Program da Snyk dá aos projetos qualificados acesso gratuito à Snyk AI Security Platform.

feature insights announcement
Blog

Comprometimento da cadeia de suprimentos do node-gyp: um worm npm que se autopropaga e se esconde em binding.gyp

Um novo worm do npm está explorando binding.gyp para acionar o node-gyp durante a instalação, permitindo que pacotes maliciosos executem código sem scripts de ciclo de vida. Ele rouba credenciais, mantém persistência no GitHub e se propaga entre contas de mantenedores.