CVE (Vulnerabilidades e Exposições Comuns) as verificações são essenciais para proteger seus aplicativos de software. No entanto, com a crescente complexidade das pilhas de software, identificar e abordar todos os CVEs pode ser um desafio. Um dos maiores problemas atuais com as verificações CVE é a prevalência de falsos positivos, onde uma vulnerabilidade é identificada em um pacote que não está em uso no aplicativo de produção.
É importante lembrar que mesmo depois de obter uma lista completa de todos os seus pacotes de software e uma lista completa de todos os CVEs encontrados nesses pacotes, é quase certo que nem todos eles são relevantes para a sua aplicação. O CVE pode estar em uma função que não está em uso no seu código ou em uma parte da biblioteca que você nem chama. Pode estar em uma dependência transitória que só é chamada devido a uma lista de dependências não corrigida e não está em uso no seu código. Mesmo quando você sabe que um CVE está em uma parte de uma biblioteca que você usa, não há garantia de que o CVE seja realmente explorável em seu aplicativo. Algumas explorações exigem condições extremas para serem utilizáveis por hackers, incluindo a combinação de 3 ou mais CVEs em sequência, a pilha certa e a infraestrutura certa. Como você ainda precisa examinar mais de perto cada CVE obtido na varredura, você pode ver como é importante reduzir o número de CVEs obtidos para não sentir fadiga de alerta ou esgotamento de CVE antes de poder voltar para realmente construir os próximos recursos do seu aplicativo.
Neste artigo, oferecerei algumas soluções possíveis para mitigar falsos positivos em varreduras de CVE, com o objetivo de reduzir o número total de CVEs com os quais você precisa lidar. Começarei discutindo os desafios da identificação de pacotes e depois passarei para a introdução de um banco de dados que mapeia arquivos de pacotes para nomes de pacotes. Também discutirei problemas de escopo e caminho de código que podem causar falsos positivos.
Vamos começar examinando como os CVEs são identificados.
O pacote misterioso e o CVE ausente
A Mitre Corporation é uma organização americana sem fins lucrativos responsável pelo Programa CVE®. Os programas A missão é identificar, definir e catalogar vulnerabilidades de segurança cibernética divulgadas publicamente. A forma como isso funciona é que, ao encontrar uma vulnerabilidade, você preenche um formulário e, se a descoberta puder ser corroborada, um novo identificador CVE é fornecido à vulnerabilidade e adicionado ao banco de dados público de CVE.
Considerando a forma como os CVEs são listados, um dos principais desafios das varreduras de CVE é identificar corretamente os pacotes e bibliotecas. Quando alguém identifica uma vulnerabilidade em um pacote ou biblioteca, ele a lista com o nome do pacote e a versão com a qual está familiarizado. É claro que nem todas as ferramentas usam as mesmas convenções de nomenclatura e os nomes dos pacotes não possuem um padrão global existente. O 'Problema de Nomenclatura', como ficou conhecido, é tão grave que vários fóruns e grupos de reflexão vêm tentando há muito tempo encontrar uma solução comum. Como exemplo, aqui está Solução proposta pela OWASP para o problema no que se refere à criação de SBOMs. Freqüentemente, as ferramentas de varredura dependem das fontes que são alimentadas, como artefatos construídos ou compilados, para os nomes dos pacotes que entregam no resultado da varredura e essas fontes nem sempre são confiáveis. Por exemplo, invólucros e adaptações podem dificultar a identificação da embalagem real. Além disso, alguns arquivos de pacote podem não deixar rastros de seu pacote de instalação, como os comandos Docker COPY.
Para resolver essas questões, nós, em Segurança do escriba, sugira a criação de um banco de dados para seu aplicativo que mapeie arquivos de pacotes para nomes de pacotes. Mesmo que o nome do pacote seja diferente, se for o mesmo pacote, os arquivos e os hashes dos arquivos seriam idênticos. Ao fazer isso, você pode ignorar problemas envolvendo wrappers e adaptações e identificar o pacote real que precisa ser resolvido. Esta abordagem pode poupar tempo e esforço no processo de remediação de CVE. Desde o Plataforma de escriba já estiver identificando os arquivos associados a cada pacote incluído em sua imagem final, criar tal banco de dados é o próximo passo lógico. Pretendemos que nossa varredura CVE não dependa do nome e da versão listados pelo CVE, mas dos arquivos reais que o pacote inclui.
Você é minha mamãe?
Ao lidar com uma construção final que é uma imagem Docker, é prática comum hoje em dia não começar do zero. Ter um ponto de partida sólido, como uma imagem base estabelecida, permite que os desenvolvedores se concentrem na parte da construção que é seu aplicativo, em vez de começarem a planejar o ambiente no qual ele precisa ser executado. Um dos desafios no uso de imagens Docker é compreender sua origem e dependências, principalmente quando se trata da imagem pai (além da imagem base) sobre a qual a imagem final é construída.
A imagem pai é um conceito que pensamos para explicar o “parente vivo” mais próximo de uma imagem Docker. As imagens são construídas em camadas distintas, então, digamos que eu use uma imagem base conhecida, como Alpine, Debian ou Ubuntu, e construa minha camada de aplicativo diretamente sobre ela. Nesse caso, meu 'pai' mais próximo seria a imagem base. Mas e se a empresa para a qual trabalho tiver um ponto de partida diferente, que inclua uma imagem base e mais algumas camadas além das ferramentas de segurança obrigatórias para todas as imagens da empresa? Nesse caso, minha imagem pai seria esse modelo de empresa e eu também seria capaz de identificar a imagem base na qual esse modelo foi construído.
A imagem pai é uma parte crucial da cadeia de fornecimento de software, pois fornece a base para o aplicativo e suas dependências. Nativamente, as imagens do Docker não incluem muitas informações sobre a origem de suas imagens pai ou base, dificultando a verificação de sua integridade, a compreensão de suas vulnerabilidades e a verificação de sua licença.
Para resolver esse problema, a Scribe desenvolveu uma ferramenta e serviço de código aberto chamado Imagem Parental para detectar o pai digitalizado mais próximo de uma imagem Docker. Esta ferramenta pode ser usada para identificar a imagem pai de uma imagem Docker, que é um facilitador chave de redução de risco:
Primeiro, ao identificar a imagem base, pode-se verificar a sua integridade e garantir que não foi adulterada ou comprometida. Isso é importante para manter a segurança e a estabilidade do aplicativo.
Em segundo lugar, ao compreender quais vulnerabilidades se originam da imagem pai e quais se originam da própria camada de aplicação, é possível priorizar e gerenciar vulnerabilidades de forma mais eficaz. Isso significa que os CVEs vinculados à sua imagem base ou à sua imagem pai são menos urgentes (e nem sempre é sua responsabilidade remediar) quando comparados aos CVEs na camada de aplicativo.
Além disso, ao identificar a imagem pai, é possível verificar sua licença e garantir a conformidade com os requisitos legais e de política interna.
A ferramenta de código aberto ParentImage inclui um banco de dados atualizável de varreduras de imagens Docker. Você pode bifurcá-lo e usá-lo totalmente internamente, mas esperamos que as pessoas digitalizem suas imagens Docker e nos enviem essas informações para serem incluídas no banco de dados. Quanto mais varreduras de imagens o banco de dados incluir, mais 'Pais' a ferramenta será capaz de identificar. Atualmente, o banco de dados incluído possui uma lista completa de todas as imagens base estabelecidas como prova de conceito. Como uma ferramenta de código aberto, não custa nada experimentá-la. Se você estiver usando imagens do Docker, recomendo que você considere essa ferramenta como uma possível solução para um motivo de CVEs não relacionados.
Devo digitalizar ou devo ignorar?
Outro desafio das varreduras CVE são as questões de escopo. O escopo refere-se à localização dos arquivos e pacotes verificados – o que deve ser incluído na verificação e o que pode ser ignorado com segurança. Às vezes, um CVE é encontrado em um pacote que não está em uso na versão de produção do aplicativo. Por exemplo, um pacote pode ser instalado como resultado de uma dependência indireta de alguma estrutura de teste. Para resolver isso, os scanners precisam avaliar o escopo dos arquivos do aplicativo e identificar as dependências indiretas em uso.
Os plug-ins OWASP (The Open Worldwide Application Security Project) têm alguns bons exemplos de ferramentas que podem ajudar com problemas de escopo. Verificação de dependência do OWASP, por exemplo, pode analisar as dependências de um aplicativo e identificar CVEs no contexto do gráfico de dependências do aplicativo. Ao fazer isso, ele pode identificar quais CVEs estão em uso na aplicação de produção e quais não estão.
Seja qual for o número, você ainda precisa resolver seus CVEs
Na ausência de alguma outra ferramenta que possa informar onde seu aplicativo está vulnerável a possíveis hacks, backdoors e outros problemas semelhantes, uma verificação CVE ainda é uma opção bastante básica para resolver possíveis problemas. A questão é que, até que você verifique se um CVE apresentado na verificação é um problema real, ele representa uma ameaça que pode ser usada contra você por reguladores, terceiros e usuários.
Em nome da segurança e da transparência, você precisa examinar cada problema potencial e provar que não é um problema, não é relevante para o seu aplicativo, ou é um problema potencial e você está trabalhando para corrigi-lo. O fato de muitos desses CVEs estarem chegando ao seu aplicativo a partir de pacotes externos, geralmente de código aberto, significa que mesmo que você o identifique como uma exploração em potencial, provavelmente ainda precisará da ajuda dos mantenedores do pacote para corrigi-lo.
Com todo esse trabalho associado a cada CVE, não é de admirar que você prefira obter o menor número possível em sua próxima varredura de CVE. Usar algumas das sugestões descritas neste artigo pode ajudar a tornar a tarefa monumental de lidar com suas vulnerabilidades um pouco mais gerenciável.
Se você tiver outras ferramentas de código aberto ou gratuitas para lidar com o problema, adoraríamos saber mais sobre isso. Conte-nos nos comentários e compartilhe com a comunidade como você lida com sua montanha de vulnerabilidades.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
