Skip to main content

A abordagem da Snyk à pesquisa de segurança de contêineres e à importância relativa

Escrito por

14 de dezembro de 2020

0 minutos de leitura

Vulnerabilidades em contêineres são complexas e exigem conhecimento tanto de segurança Linux quanto da arquitetura de imagens de contêineres. Deixando de lado as vulnerabilidades que podem surgir no seu código, a maioria das que você encontra em contêineres está relacionada a pacotes do sistema operacional Linux e suas dependências. Ainda assim, os contêineres geralmente ficam sob a responsabilidade de desenvolvedores, que normalmente não são especialistas em manutenção de sistemas operacionais. Além disso, esses pacotes não recebem atualizações da mesma forma que um sistema operacional completo em execução em servidores. Temos o prazer de anunciar um novo recurso que ajuda a esclarecer como priorizar e corrigir vulnerabilidades em contêineres: importância relativa.

Importância relativa e integridade dos dados na segurança de contêineres

Importância relativa é um método usado pela nossa equipe de segurança para avaliar a gravidade das vulnerabilidades em pacotes de contêineres. Se você já analisou imagens de contêiner baseadas em Debian ou Ubuntu com o Snyk Container, já pode ver essas informações. Em breve, adicionaremos dados de mais distribuições. Em resumo, a importância relativa incorpora à avaliação de vulnerabilidades do Snyk Container as orientações dos responsáveis pela manutenção de cada distribuição e dos pesquisadores de segurança. Isso é importante porque os pacotes Linux geralmente recebem uma classificação de vulnerabilidade da NVD, mas, como cada distribuição cria e mantém seus lançamentos de maneiras um pouco diferentes, seus mantenedores podem avaliar de outra forma o risco de um pacote vulnerável. É isso que chamamos de importância relativa.

No exemplo abaixo, você pode ver uma vulnerabilidade em um contêiner cuja classificação original da NVD é de gravidade ALTA. No entanto, o contêiner em questão usa pacotes Debian e, devido à maneira como o Debian lida com esse pacote, o _bash_shell, na distribuição, os mantenedores do Debian classificam a vulnerabilidade como SEM IMPORTÂNCIA, ou de baixa gravidade nas classificações da Snyk. Isso aparece na nossa classificação de gravidade (canto superior esquerdo) e também é usado no cálculo da pontuação de prioridade (321), exibida à direita.

Detalhes da vulnerabilidade em contêiner causada pela verificação incorreta de privilégios removidos, indicando baixa severidade, exploração madura e fatores de pontuação de segurança.

Você não precisa fazer nada para ativar esse novo recurso. Ele já está disponível na interface e na CLI da Snyk, e o Snyk Container seleciona automaticamente a classificação mais adequada para a vulnerabilidade. Abaixo está uma versão resumida da saída JSON da CLI, com os campos severity, nvdSeverity, e relativeImportance.

Se você quiser entender como esses campos funcionam:

  • relativeImportance - É a classificação de gravidade atribuída pelos mantenedores da distribuição, caso tenham analisado a vulnerabilidade e definido uma classificação. A Snyk considera as distribuições a fonte mais precisa; por isso, essa é a gravidade exibida quando há dados disponíveis. No entanto, as distribuições variam quanto ao número e aos tipos de vulnerabilidades que analisam. Se esses dados não estiverem disponíveis, usamos nvdSeverity.

  • nvdSeverity - É a classificação de gravidade original da NVD para a vulnerabilidade. Este é o campo menos preciso quando uma distribuição já analisou a vulnerabilidade. Em geral, ele só é útil para organizações com SLAs muito rigorosos baseados especificamente na NVD ou para aquelas que precisam que a pontuação e a gravidade do CVSS correspondam. Exibimos esses dados no relatório de vulnerabilidade para que você entenda o contexto da classificação de gravidade apresentada. Se não houver uma classificação específica da distribuição, essa será a gravidade exibida.

  • severity - É a gravidade exibida pela Snyk. Se a distribuição tiver analisado a vulnerabilidade e houver uma classificação de relativeImportance, usaremos esse valor, e severity será equivalente a relativeImportance. Se a distribuição não tiver analisado a vulnerabilidade, a Snyk usará nvdSeverity, para que você não deixe passar problemas de gravidade alta ou crítica só porque a distribuição ainda não publicou seus próprios dados.

Em geral, recomendamos usar o campo padrão severity nas APIs ou na saída JSON, pois fazemos o trabalho necessário para fornecer a classificação de gravidade mais precisa para a imagem do seu contêiner. Os campos adicionais oferecem mais contexto para você entender por que determinada gravidade e pontuação são diferentes. Mas sabemos que alguns clientes têm outras necessidades e usam esses campos de outras maneiras.

{
      "title": "Improper Check for Dropped Privileges",
      "credit": [
        ""
      ],
      "packageName": "bash",
      "language": "linux",
      "packageManager": "debian:9",
.
.
.
      "severity": "low",
      "cvssScore": 7.8,
      "CVSSv3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:F",
      "nvdSeverity": "high",
      "relativeImportance": "unimportant",
      "from": [
        "docker-image|purpledobie/blog@demo",
        "bash@4.4-5"
      ],
      "name": "bash",
      "version": "4.4-5"
}

Um olhar mais aprofundado sobre o processo de pesquisa da Snyk para vulnerabilidades em contêineres

Esses novos dados de relativeImportance são um exemplo do trabalho minucioso da equipe de pesquisa de segurança da Snyk, para que você não precise fazê-lo. Na pesquisa de vulnerabilidades e na criação de informações de segurança úteis para nossos clientes, avaliamos nosso trabalho com base em quatro fatores:

  • Completude: ir além de uma única fonte de dados sobre vulnerabilidades, reunindo informações de várias fontes e complementando-as com nossa própria pesquisa primária

  • Agilidade: reunir rapidamente todos os dados relevantes e disponibilizá-los para os usuários finais

  • Precisão: reduzir falsos positivos e falsos negativos é essencial para evitar perda de tempo e não deixar passar fatores de risco importantes

  • Aplicabilidade: a Snyk é uma solução usada por equipes de segurança e por desenvolvedores, mas, em geral, são os desenvolvedores que acabam responsáveis por corrigir os problemas que identificamos. Isso é sempre levado em conta na hora de decidir como apresentar nossas descobertas.

Lidar com vulnerabilidades em contêineres exige conhecer a fundo o universo do Linux e dos contêineres, destacar as informações relevantes para os usuários finais (geralmente desenvolvedores) e torná-las úteis no processo de criação e manutenção de contêineres. Na Snyk, nossa equipe de pesquisa de segurança cuida desse trabalho para que você não precise fazê-lo. Cadastre-se gratuitamente na Snyk e comece a proteger seus contêineres!

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.