O paradoxo do open source: análise de risco, equidade e aceitação

O open source sempre foi um paradoxo: trata-se de um software feito por desenvolvedores apaixonados e oferecido gratuitamente, mas monetizado e financiado por algumas das maiores empresas do mundo.  Já foi chamado de "câncer" e foi desacreditado, mas segue como a maior força por trás da inovação e do progresso tecnológico que testemunhamos. No mundo do open source, sempre haverá paradoxos, ainda mais na compreensão das vulnerabilidades de segurança.

Há 25 anos, o programa Common Vulnerabilities and Exposures (CVE) foi criado para padronizar a nomenclatura e o rastreamento de falhas de software. Em uma época em que identificar uma vulnerabilidade específica era muitas vezes ambíguo, com vários problemas em softwares amplamente utilizados, como o Sendmail, o CVE surgiu para trazer clareza e organização. Esforços iniciais como o Security Focus e o Bugtraq já existiam, mas o CVE da MITRE forneceu um sistema global muito necessário. Em seu primeiro ano, 1999, foram catalogadas 894 vulnerabilidades, o que evidenciou a necessidade inicial de uma identificação consistente, mesmo com um volume relativamente menor. Esse contexto histórico é crucial para entender os desafios que enfrentamos com CVEs hoje.

O cenário de vulnerabilidades de software mudou drasticamente ao longo desse tempo. Nos primeiros seis anos do programa, o número de CVEs atribuídas aumentou em mais de 450%, impulsionado pela adoção mais ampla. Esse crescimento continuou exponencial, chegando a quase 15 mil CVEs em 2017, um aumento de 125% em apenas dois anos. Em 2023, o volume aumentou mais 50%, para mais de 29 mil. Esse crescimento explosivo ressalta a crescente complexidade dos softwares, a maior disponibilidade dos softwares e o fato de mais fornecedores estarem adotando o CVE.

O cenário de vulnerabilidade continua a se expandir significativamente. Em 2024, as CVEs atribuídas aumentaram 39%, para mais de 40 mil, em parte devido ao status de CVE Numbering Authority (CNA) do kernel Linux. Essa trajetória de crescimento pode acelerar significativamente se outros setores de software, como o de desenvolvimento de jogos ou aplicativos mobile, começarem a rastrear formalmente as CVEs. Esse volume exige uma reavaliação crítica da nossa estratégia de gerenciamento de vulnerabilidades.

Tentar "corrigir tudo" é insustentável

 Há muito tempo defendemos que o antigo mantra de "corrigir tudo" fazia sentido em tempos mais simples, mas é insustentável e estrategicamente inadequado nos ambientes complexos de hoje. Essa abordagem é adotada sem uma avaliação real dos riscos. Nem toda vulnerabilidade exige uma correção imediata e com uso intensivo de recursos. Fatores como potencial de exploração e impacto são fundamentais. Tratar todas as falhas identificadas de maneira idêntica é o mesmo que recomendar uma cirurgia agressiva tanto para tumores benignos quanto para malignos. Isso ignora o nível real de ameaça e o risco inerente ao tratamento em si.

A exploração real deve ser o principal critério na hora de priorizar ações. A análise de dados, usando fontes como o catálogo de vulnerabilidades exploradas conhecidas (KEV) da Agência de Segurança Cibernética e de Infraestrutura (CISA), mostra consistentemente que as taxas de exploração continuam extraordinariamente baixas, historicamente bem abaixo de 0,5% ao ano. Isso significa que cerca de 1 em 200 vulnerabilidades é utilizada para fins maliciosos. Sabendo disso, devemos nos concentrar em abordagens mais pragmáticas e baseadas em riscos.

Nosso foco deve mudar para as vulnerabilidades com maior probabilidade de serem exploradas e que também possam causar danos significativos, normalmente aquelas que permitem acesso remoto e não autenticado com alto escalonamento de privilégios, o que chamamos de Crítica ou Importante. Ao concentrar os esforços de correção nessas vulnerabilidades de alto risco e impacto, maximizamos a redução de risco com os recursos disponíveis. Isso significa, inevitavelmente, aceitar estrategicamente os menores riscos residuais, representados por vulnerabilidades que provavelmente não serão direcionadas e nem terão um impacto material se exploradas. Essas vulnerabilidades são classificadas como problemas Baixos e Moderados. 

O gerenciamento de riscos eficaz não significa eliminar todas as vulnerabilidades. Mas trata-se de priorizar as que representam uma ameaça real e provável, assumindo conscientemente os riscos que podem ser gerenciados em outros pontos.

O que isso tem a ver com o open source?

As preocupações com vulnerabilidades sem patches geralmente se concentram no open source, principalmente devido à sua transparência. Todos podemos ver o código e as CVEs. Por outro lado, os fornecedores proprietários frequentemente não divulgam falhas de baixo impacto que consideram inúteis, criando um cenário de risco obscuro. Uma falha pequena resultante de uma CVE pública no open source pode acabar não sendo reportada, corrigida ou sequer receber um patch no software proprietário.

Essa diferença de visibilidade cria um padrão de via dupla. As políticas que exigem "nenhuma vulnerabilidade conhecida" visam inerentemente a transparência do open source, não necessariamente seu maior risco. Sua organização já aceita implicitamente o risco de pequenas falhas não divulgadas no software proprietário que você usa diariamente. O verdadeiro gerenciamento de riscos exige reconhecimento disso. Em vez de prejudicar a visibilidade inerente ao open source, devemos fazer uma avaliação de risco explícita e consistente com foco em potencial de exploração e impacto prováveis em todo o software.

A verdadeira equidade no espaço de gerenciamento de vulnerabilidades exige que reconheçamos que o open source é diferente: ele é infinitamente mais transparente por padrão (o que é bom!) e parece ter mais vulnerabilidades. O open source requer a aceitação explícita dos riscos que aceitamos implicitamente no software proprietário.

E há alguns dados interessantes que comprovam isso. Ao comparar a Red Hat e os dados do nosso Relatório de Riscos de 2024 com um fornecedor de software proprietário de grande porte e conhecido, temos insights muito interessantes que comprovam a hipótese mencionada. A menos que o fornecedor proprietário criasse apenas bugs de alto impacto (leia-se: facilmente exploráveis), veríamos uma distribuição semelhante de problemas Críticos e Importantes a Moderados e Baixos. Em outras palavras, se os bugs de segurança causados por eles não fossem sempre grandes e graves, haveria um número maior de falhas menos impactantes. No entanto, as métricas mostram um número quase insignificante de problemas de baixa gravidade. A propósito, esse fornecedor usa a mesma escala de classificação de gravidade de quatro pontos que a Red Hat usa.

As métricas de geração de relatórios de vulnerabilidade podem passar uma ideia enganosa. O maior volume de CVEs de menor gravidade relatadas de forma transparente por projetos open source (92% das vulnerabilidades da Red Hat sendo Moderadas e Baixas em 2024) em comparação com esse fornecedor proprietário (com 5,5% classificadas como Moderadas e Baixas em 2024) não ilustra risco. Isso reflete principalmente filosofias de divulgação diferentes.

Em vez de buscar classificações de volume ou gravidade, é melhor se concentrar no fator crítico: a exploração real. Em 2024, apenas 0,26% das vulnerabilidades open source (11 entre mais de 4.200 que afetaram o software da Red Hat) tiveram exploração confirmada em plataformas reais. Quando a priorização se baseia somente em números, muitos recursos acabam sendo direcionados a problemas com impacto prático mínimo.

Tanto os fornecedores open source quanto os proprietários priorizam corrigir o que é mais importante. A principal diferença costuma ser a transparência em relação às vulnerabilidades não corrigidas e de menor impacto. Já aceitamos implicitamente esse risco remanescente do software de código fechado. Chegou a hora de aplicarmos essa mesma avaliação pragmática e baseada em riscos explicitamente em todos os softwares, incluindo os open source. Filosoficamente, todos concordamos: corrija o que é importante e não priorize o que não é.

Como líderes de segurança, acreditamos que seu programa deve evitar a simples contagem de vulnerabilidades. Defender uma estratégia centrada na inteligência de capacidade de exploração e no possível impacto nos negócios. Implemente processos que priorizem rigorosamente a fração de ameaças que provavelmente serão utilizadas para fins maliciosos, e promova uma cultura que entenda e aceite conscientemente os riscos residuais gerenciáveis. Direcione seus recursos para mitigar as ameaças que realmente colocam sua organização em risco.

Se quiser se aprofundar mais nesse assunto, falei na conferência SOSS Fusion da OpenSSF no ano passado sobre esse assunto usando dados de 2023 e este ano na VulnCon 2025 usei os dados de 2024.