Skip to main content

Definindo a segurança de contêineres com foco em desenvolvedores

Escrito por
Container security

16 de março de 2021

0 minutos de leitura

Você já adotou a abordagem shift left? Essa é a grande tendência, não é? A ideia é transferir as responsabilidades de segurança das equipes centrais de TI para os desenvolvedores, mas isso é mais complicado do que parece. Simplesmente pegar ferramentas criadas para especialistas em segurança e fazê-las atuar mais cedo na cadeia de suprimentos não fornece informações úteis aos desenvolvedores. É justamente essa capacitação das organizações para transferir a responsabilidade que nos empenhamos em viabilizar na Snyk. E é por isso, em parte, que estamos tão animados com o anúncio de hoje: agora automatizamos PRs de correção para contêineres, dando continuidade ao nosso anúncio recente de que estamos elevando os Dockerfiles ao status de primeira classe nos seus repositórios Git.

Painel que compara imagens-base atuais e alternativas pelo número e pela gravidade das vulnerabilidades, com botões para abrir uma solicitação de pull request de correção.

Ajudar desenvolvedores a criar contêineres mais seguros sempre foi a nossa prioridade na Snyk Container, desde o lançamento do produto, em 2019. Temos orgulho de dizer que já ajudamos clientes e usuários da Snyk a eliminar 5,8 milhões de vulnerabilidades dos contêineres. E o ritmo está acelerando desde que adicionamos os novos recursos de Dockerfile e pull requests de correção.

Por que os desenvolvedores não usam a segurança de contêineres em tempo de execução

Nas conversas com clientes e usuários da Snyk Container sobre o tema, percebemos que a maioria tem boas ideias sobre o que “deveria” fazer para criar contêineres seguros: as equipes de segurança definem políticas, e há muitas listas de “10 práticas recomendadas para contêineres” na internet, que são extremamente populares entre os desenvolvedores. (Nossa própria lista das 10 principais práticas para contêineres é uma das publicações mais populares do nosso blog!) Mas, na hora de colocar essas políticas em prática, apenas 45% dos responsáveis por decisões de segurança no mundo todo afirmam contar com ferramentas suficientes para apoiá-las, segundo o relatório Práticas recomendadas para a segurança de contêineres da Forrester. Por isso, talvez não surpreenda que as organizações não imponham práticas recomendadas, como o uso de imagens leves.

Gráfico de rosca mostrando 45%, com um segmento em degradê do vermelho ao roxo e o restante em branco

Isso revela um problema com a ideia de simplesmente adotar a abordagem shift left usando as ferramentas existentes. O Docker está prestes a completar 8 anos, e as ferramentas de segurança de contêineres em tempo de execução existem há cerca de 5 anos. Mesmo assim, segundo um estudo da ESG, os quatro principais desafios que impedem a aplicação das políticas com as ferramentas de segurança existentes são:

  • Os desenvolvedores não usam com eficiência as ferramentas em que investimos

  • Os desenvolvedores não têm o conhecimento necessário para corrigir os problemas identificados

  • As ferramentas criam atrito e desaceleram nossos ciclos de desenvolvimento

  • É difícil integrar as ferramentas de diferentes fornecedores de segurança de aplicações, ou elas não se integram

Isso não é uma crítica à segurança em tempo de execução: ela é absolutamente necessária. Para proteger praticamente todas as aplicações, a maioria das empresas investe tanto em ferramentas de segurança de código quanto em ferramentas de segurança operacional, cada uma voltada a um público diferente. Os contêineres são interessantes porque reúnem aspectos dos dois em um pacote conveniente, mas os dois públicos continuam existindo.

Como a Snyk ajuda você a adotar de verdade a abordagem shift left para proteger contêineres

A Snyk Container é a única solução criada desde o início para incorporar a segurança ao dia a dia e aos processos de desenvolvimento. Percebemos o problema de simplesmente apresentar uma longa lista de vulnerabilidades, algo comum nas ferramentas voltadas à segurança. Em vez disso, a Snyk Container orienta diretamente os desenvolvedores sobre como corrigir problemas em contêineres, começando pelas recomendações de imagens base:

Janelas de terminal estilizadas mostram a saída da Snyk CLI identificando vulnerabilidades em contêineres e recomendando a atualização da imagem-base.

As orientações ajudam os desenvolvedores a escolher imagens base atualizadas e mais enxutas, reduzindo a “superfície de ataque” de vulnerabilidades. Agora, com a análise de Dockerfiles e os PRs de correção, vamos além e automatizamos essas recomendações. E o melhor: a Snyk Container é compatível com a forma como você preferir executar seus contêineres. Não é preciso usar sidecars, agentes ou pods com privilégios especiais no Kubernetes para que a Snyk Container funcione.

Como escalar a segurança à medida que o uso de contêineres cresce

É claro que a Snyk Container funciona onde os desenvolvedores trabalham. Eles podem usá-la diretamente no desktop por meio da nossa CLI. Além disso, ela está disponível em integrações com os gerenciadores de código-fonte de sua preferência (incluindo a análise de código do GitHub), qualquer ferramenta de CI/CD e registros de contêineres. Também pode ser integrada ao Kubernetes para analisar cargas de trabalho à medida que são implantadas ou atualizadas nos clusters.

À medida que aumenta o número de cargas de trabalho em contêineres, fica ainda mais importante ajudar os desenvolvedores a priorizar quais problemas corrigir, além dos relacionados à imagem base. Os contêineres são criados assim que o código é enviado e podem ser implantados com a mesma rapidez. Por isso, nosso objetivo é garantir que já sejam seguros desde o início. Os recursos de priorização da Snyk ajudam os desenvolvedores a se concentrar nos problemas mais importantes, considerando detalhes das vulnerabilidades, como gravidade, maturidade da exploração e se o contêiner está em execução, além de filtros que facilitam decidir o que e como corrigir.

Painel de priorização de vulnerabilidades com problemas de alta gravidade e uma explicação da pontuação, que lista fatores de risco de exploração e do contêiner

Veja como os clientes da Snyk Container protegem aplicações nativas da nuvem

A Red Ventures sabia que precisava oferecer aos desenvolvedores uma experiência sem atritos para melhorar a segurança dos contêineres. Por isso, integrou a Snyk às suas ferramentas, dando visibilidade a problemas de segurança que podem ser resolvidos e tornando a correção mais eficiente. Como ferramenta de segurança criada para desenvolvedores, a Snyk se encaixa naturalmente nos fluxos de trabalho de engenharia da empresa.

A Lunar precisava de uma solução pronta para uso, sem exigir treinamentos especiais nem uma aplicação web separada para facilitar a adoção pelos desenvolvedores. Ao implementar a Snyk no pipeline, a equipe passou a ter uma visão mais clara das vulnerabilidades em todo o ambiente. Assim, mesmo com a rotina corrida, consegue identificar os riscos mais importantes e corrigir o que é mais urgente.

Segurança de contêineres que prioriza os desenvolvedores

O Snyk encontra e corrige automaticamente vulnerabilidades em imagens de contêiner e workloads do Kubernetes.

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.