A taxa de divulgação de novas vulnerabilidades aumenta constantemente. Atualmente está em uma média de 15,000 CVEs por ano. 2022 se destaca com mais de 26,000 novos CVEs relatados. Obviamente, nem todas as vulnerabilidades são relevantes para o seu software. Para descobrir se uma vulnerabilidade específica é um problema, primeiro você precisa descobrir se está usando a biblioteca ou produto que contém a vulnerabilidade e, em seguida, descobrir se está usando a versão e o módulo problemáticos dessa biblioteca. Por fim, você precisa consultar sua equipe de desenvolvimento para ver se essa vulnerabilidade é relevante para seu produto específico e para a maneira como você usou essa biblioteca ou produto vulnerável.
O processo de descobrir tudo isso não é simples e pode levar bastante tempo. Tom Alrich, um conhecido especialista em segurança cibernética, estima que cerca de 95% de todos os CVEs presentes em um determinado produto de software não são exploráveis. Mas, se você é um usuário final ou uma empresa prestes a integrar software de terceiros em seu sistema, como pode identificar os 5% problemáticos para poder solicitar a correção ou correção adequada?
É aqui que surge a ideia de O Vulnerability Exploitability Exchange (VEX) chega. O objetivo da VEX, conforme definido pela orientações da Administração Nacional de Telecomunicações e Informações dos EUA (NTIA) em 2021, é “fornecer aos usuários (por exemplo, operadoras, desenvolvedores e provedores de serviços) informações adicionais sobre se um produto é afetado por uma vulnerabilidade específica em um componente incluído e, se afetado , se há ações recomendadas para remediar.”
Neste momento você provavelmente está pensando – então como posso obter esses documentos VEX e começar a verificar meus componentes? Bem, a realidade do uso do VEX é, como sempre, complicada.
Descubra o propósito da VEX
Simplificando, o VEX deve responder de forma rápida e fácil à pergunta 'minha versão deste software é explorável para este vulnerabilidade?'.
A resposta a essa pergunta deve ser uma das quatro opções principais:
- Não afetado: Nenhuma correção é necessária em relação a esta vulnerabilidade.
- Afetado: São recomendadas ações para remediar ou resolver esta vulnerabilidade.
- Fixo: Estas versões do produto contêm uma correção para a vulnerabilidade.
- Sob investigação: Ainda não se sabe se essas versões de produtos são afetadas pela vulnerabilidade. Uma atualização será fornecida em uma versão posterior.
Como o VEX deve ser tanto legível quanto gerado por máquina, a ideia é ter um banco de dados pesquisável desses documentos em algum lugar para que qualquer parte interessada possa consultá-lo e obter a resposta necessária.
Como a suposição é que 95% das vulnerabilidades não são exploráveis em qualquer produto de software, este sistema destina-se a reduzir as enormes listas de vulnerabilidades encontradas para cada produto apenas àquelas que o usuário deve ficar de olho ou solicitar remediação ou patch. para.
Há uma série de fatos interessantes sobre a história da VEX
Em 2020, NTIA (a Administração Nacional de Telecomunicações e Informação dos EUA) começou a discutir a ideia do VEX como uma ferramenta de acompanhamento ao SBOM (Lista de materiais de software). Em setembro de 2021, a NTIA lançou uma introdução de uma página e uma explicação sobre o que o VEX deveria fazer.
Mais tarde, o esforço para refinar os requisitos do novo formato de consultoria ficou sob os auspícios da CISA – a Agência de Segurança Cibernética e de Infraestrutura dos EUA, que lançou seu próprio documento no início de 2022 entrando em mais detalhes, bem como alguns casos de uso que o documento VEX deveria ajudar. O documento, uma minuta, definiu os campos mínimos obrigatórios do documento VEX da mesma forma que a NTIA definiu os campos mínimos obrigatórios do SBOM.
Desde então, houve duas tentativas principais de criar um formato de documentação VEX legível por máquina:
- A Estrutura Comum de Aconselhamento de Segurança (CSAF) foi o primeiro formato disponível. Este formato foi lançado no final de 2022 pela OASIS Open, uma organização internacional sem fins lucrativos dedicada à produção de padrões de código aberto para segurança cibernética, blockchain, IoT e outras áreas.
- Ciclone DX, formato padronizado para SBOMs lançado pelo OWASP (Open Web Application Security Project), que foi adaptado para criar também documentos VEX.
CSAF é um formato abrangente, mas para realmente usá-lo com sucesso, você precisa incluir vários campos e muitas metainformações, tornando improvável uma adoção real. A iniciativa CyclonDX VEX é muito mais estreita, portanto, ao considerar qual padrão VEX usar, provavelmente seria com o formato CyclonDX.
Por que a VEX encontrou um obstáculo – Descobrindo os problemas que sabotam seu sucesso
VEX é uma boa ideia e pode fornecer a valiosa capacidade de verificar rapidamente se uma vulnerabilidade específica é de fato explorável em um produto de software específico.
Existem vários problemas, no entanto, que até agora estão a sufocar a sua implementação:
- Responsabilidade de arquivamento – quem deve ser responsável pelo arquivamento dos documentos VEX exigidos? São os produtores de software? Empresas de segurança terceirizadas ou organizações sem fins lucrativos? Uma agência governamental? O que aconteceria se múltiplas fontes apresentassem informações contraditórias?
- Banco de dados VEX – quem ou o que deve salvar e categorizar as informações VEX? Supondo que alguns dos documentos descrevam problemas exploráveis em software, não existe o perigo de que as informações caiam em mãos erradas (maliciosos)?
- Os formatos atuais não cobrem adequadamente a questão das versões e muito menos o problema do versionamento combinado.
Versões combinadas de software/pacote referem-se à prática de agrupar vários pacotes ou componentes de software em uma única versão ou pacote de instalação.
Quando se trata de correção de vulnerabilidades, versões combinadas de software/pacote podem ajudar e atrapalhar o processo. Por um lado, ter um único pacote de instalação que inclua todos os componentes necessários pode simplificar o processo de identificação e correção de vulnerabilidades. Em vez de precisar identificar e corrigir manualmente cada componente individual, você pode simplesmente aplicar o patch ao pacote inteiro.
No entanto, o outro lado disso é que, se um componente do pacote estiver vulnerável, todo o software estará vulnerável. Isso significa que mesmo que alguns dos componentes do pacote tenham sido corrigidos, o pacote geral ainda poderá estar em risco se um único componente não corrigido estiver presente.
Digamos que a versão 1 da biblioteca A do seu software tenha uma vulnerabilidade. Esse problema só se manifesta quando a biblioteca A está presente com a versão 2 da biblioteca B. Existe um patch de segurança, mas nem todos o teriam instalado. Isso significa que o documento VEX para essa vulnerabilidade em seu software precisa cobrir todas as combinações possíveis do produto, suas versões, suas bibliotecas contidas, suas versões e os possíveis patches lançados. São muitas informações complexas que não são fáceis de expressar de forma simples.
- Como a VEX cobriria o software incorporado ao hardware com todas as versões e patches possíveis disponíveis lá? De quem seria a responsabilidade de corrigir este software, considerando que você não pode abrir facilmente o hardware e corrigir as coisas sozinho?
Esses são apenas alguns dos problemas que qualquer ferramenta automática para lidar com VEX precisaria compreender e levar em consideração.
Não seria mais fácil se você pudesse solicitar e obter informações para qualquer versão?
A suposição de que a melhor maneira de compartilhar essas informações importantes é por meio de um documento é possivelmente errônea. Produzir documentos VEX suficientes para cobrir todas as combinações de versão, patch e vulnerabilidade é uma tarefa importante que, compreensivelmente, ninguém deseja empreender.
Escriba construiu uma plataforma para rastrear e compartilhar informações relacionadas à segurança para cada versão de um projeto ou produto de software específico. Como parte disso, cada build gera um SBOM preciso e uma lista de vulnerabilidades que foram descobertas no produto.
O Scribe permite que o produtor de software adicione avisos em formato VEX a cada uma dessas vulnerabilidades para observar se elas não são exploráveis, estão sob investigação, etc. Depois que uma versão é lançada, todas as informações de segurança sobre essa versão podem ser compartilhadas com terceiros interessados, usuários , reguladores e assim por diante. Incluir a lista de vulnerabilidades, bem como a lista consultiva VEX, significa que o destinatário deve ser capaz de analisar apenas as vulnerabilidades que são um problema potencial neste produto específico. Isso alivia muito o fardo tanto do produtor de software, que pode “colocar seu produto na lista de permissões”, quanto do consumidor de software, que entende exatamente qual nível de risco está envolvido em um produto de software específico.
Como o produtor de software é o único que pode dizer com certeza se uma determinada vulnerabilidade é, de facto, relevante para uma determinada versão do produto, ele é o único que pode adicionar e modificar avisos nos seus próprios produtos. A decisão do produtor de software a este respeito é final e incontestável. A decisão sobre com quem compartilhar essas informações também é prerrogativa do produtor de software.
Como o histórico completo de compilações do produto, SBOMs e informações de segurança são salvos pelo Scribe, os usuários podem facilmente solicitar e obter essas informações para qualquer versão que estejam usando durante todo o ciclo de vida do software.
Conclusão
Lembre-se de que qualquer verificação decente de um produto de software hoje em dia produziria centenas, senão milhares de vulnerabilidades possíveis. A maioria das pessoas não consegue lidar com esse número. A fadiga dos alertas se instala e o número de vulnerabilidades se torna apenas isso – um número.
A possibilidade de reduzir o número de problemas detectados a uma quantidade administrável seria uma vantagem para os produtores e usuários de software. O objetivo é focar apenas nos problemas reais para que o produtor de software possa corrigi-los e remediá-los o mais rápido possível.
Ferramentas automatizadas, como Escriba oferecem uma maneira fácil de ver apenas as vulnerabilidades relevantes para cada um dos seus projetos e construções, informações que você pode compartilhar facilmente, tornando a montanha de vulnerabilidades significativamente menor e muito mais gerenciável.
Uma advertência importante, porém, é que este futuro, onde podemos ver facilmente e responder apenas às vulnerabilidades relevantes, não seria possível sem a participação ativa da comunidade de código aberto. A maior parte do código hoje em dia é composta por quantidades significativas de software de código aberto, por isso precisamos que os mantenedores e desenvolvedores de tais bibliotecas participem da descoberta e correção das vulnerabilidades exploráveis que assolam seu código.
O problema das vulnerabilidades relevantes e exploráveis não vai desaparecer, por isso cabe a todos nós encontrar a forma mais eficiente e económica de obter a resposta à pergunta: 'a minha versão deste software é explorável para este vulnerabilidade'.
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
