Relatório sobre riscos de segurança de soluções da Red Hat de 2024: CVEs, XZ Backdoor, SSCAs e IA

Pegue um chá ou uma xícara de café e leia o 2024 Product Security Risk Report da equipe Red Hat Product Security. Como alguém que se esforça para se manter informado sobre o ecossistema open source e seus desafios em segurança, achei o relatório deste ano visivelmente mais longo, mas a profundidade e os detalhes não decepcionaram. Na verdade, uma adição notável ao relatório deste ano é a discussão sobre IA. 

O jogo de números: para cima, para cima e... espere, o quê?

Primeiro, vamos detalhar os números brutos. Red Hat Security Advisories (RHSA) atingiu um novo pico em 2024, chegando a 2.975 comunicados de segurança. Houve um aumento constante nos últimos anos. Curiosamente, enquanto os comunicados do tipo Importante e Moderado tiveram um salto significativo, os comunicados do tipo Crítico diminuíram um pouco, inclinando-se para práticas de segurança mais proativas e detecção mais rápida.

A contagem de vulnerabilidades e exposições comuns (CVE) disparou para 4.272, um aumento significativo em relação aos anos anteriores, quando estavam relativamente estáveis. O que causou isso? O relatório destaca o fato de a Linux Kernel Organization tornar-se uma CVE Numbering Authority (CNA) em fevereiro de 2024. Eles começaram a atribuir CVEs a vários problemas de kernel, muitos dos quais não teriam sido atribuídos anteriormente. Se você filtrar esses novos CVEs do kernel.org, a linha de tendência parecerá mais familiar, com um leve aumento, refletindo provavelmente o crescente portfólio da Red Hat, mas nada alarmante. 

Indo mais fundo, a maioria dos novos CVEs de kernel são classificados como Moderado e Baixo, e somente 45% dos CVEs atribuídos pelo kernel.org em 2024 afetaram Red Hat Enterprise Linux (RHEL). Além disso, o foco deve permanecer diretamente nas vulnerabilidades Críticas e Importantes que se alinham com os locais onde as tentativas reais de exploração são vistas. Essa abordagem é validada pela rápida recuperação da Red Hat em mais da metade dos CVEs Críticos, fornecendo as primeiras correções em 7 dias ou menos, e 3 correções no Dia 0.

Sem o contexto acima, ao analisar essas métricas, você pode pensar: o que a Red Hat está fazendo? A contagem bruta de CVEs aumentou significativamente, mas o perfil de risco subjacente das soluções Red Hat não mudou paralelamente. Esses números reforçam que confiar somente na contagem de CVE não é suficiente. Você também deve considerar a gravidade, a capacidade de exploração e a relevância. O foco da Red Hat em aplicar patches aos problemas Críticos e Importantes é validado pelos dados, evidenciando ser onde a maior parte da exploração no mundo real ocorre, provando que uma abordagem baseada em risco faz mais sentido.

XZ Backdoor: o elefante na sala

Quem pode falar sobre segurança em 2024 sem mencionar o incidente XZ Backdoor? Foi um ataque bem planejado à cadeia de suprimentos que ainda hoje assombra a comunidade open source. Um mantenedor de confiança que passou mais de dois anos criando afinidade na comunidade introduziu um backdoor sofisticado na biblioteca XZ. Se Andres Freund não tivesse notado o atraso no desempenho que isso causava, ele poderia ter comprometido o acesso ao Secure Shell (SSH) em inúmeros sistemas.

Neste relatório, a Red Hat reflete sobre a resposta do open source, destacando os riscos inerentes e mostrando os pontos fortes do modelo open source. A análise rápida e colaborativa e o compartilhamento de informações foram possíveis porque o código-fonte e as interações eram públicos. O relatório também discute as barreiras no próprio pipeline, como os testes do Fedora e a engenharia de qualidade do RHEL, que poderiam ter detectado o problema, embora seja impossível afirmar com certeza.

O incidente do XZ Backdoor foi um alerta. Esse incidente terá efeitos duradouros nos processos de confiança e contribuição no open source. Os ataques à cadeia de suprimentos estão crescendo em número e sofisticação. Os invasores estão encontrando maneiras de atacar ferramentas comuns e códigos compartilhados que os desenvolvedores usam diariamente, na esperança de causar problemas generalizados. Esses tipos de ataques mostram que os fornecedores de software precisam de várias camadas de proteção: verificação automática da segurança de qualquer parte do código pré-compilado usado, ter uma linha de montagem segura para compilar software e inspecionar cuidadosamente todas as novas peças antes de adicioná-las. É bom saber que a Red Hat realizou várias verificações que poderiam e teriam detectado o recente problema de segurança do XZ, enfatizando que essas camadas de segurança realmente ajudam. A segurança nunca será uma atividade pronta.

Problemas na cadeia de suprimentos

O número crescente de ataques à cadeia de suprimentos de software (Software Supply Chain Attacks - SSCAs) e a dependência de componentes open source são quase inacreditáveis, mas estatisticamente verdadeiros. Análise da Black Duck apresenta um quadro preocupante: 97% das bases de código comerciais dependem de componentes open source. Embora isso aumente a velocidade da inovação e do desenvolvimento, pode se tornar um alvo extremamente atraente para agentes mal-intencionados, pois os dados evidenciam que eles não estão perdendo nenhuma chance. O rastreamento da Red Hat de SSCAs divulgado publicamente revelou 89 incidentes em 2024, um aumento impressionante de 68% em relação ao ano anterior. Relatório da Sonatype ecoa essa tendência inquietante. As cadeias de suprimentos de software estão cada vez mais ameaçadas.

O comprometimento do XZ Util e os agentes de ameaças norte-coreanos que usaram esquemas elaborados de fraude trabalhista para obter acesso interno foram apenas dois exemplos das táticas em evolução usadas por agentes mal-intencionados. O problema com isso é que, para a maioria desses ataques, o motivo é amplamente desconhecido, e uma grande quantidade permanece não reclamada. É difícil se defender com eficiência quando você não entende totalmente quem está atacando ou por quê. Sabemos que alguns invasores querem dinheiro ou estão tentando espionar, mas não sabemos o objetivo de muitos ataques. Isso complica toda a situação com ameaças cibernéticas e é difícil de prever ou modelar. Atingir os desenvolvedores e seus pontos de acesso faz todo o sentido do ponto de vista de um invasor, já que eles têm as chaves do reino, mas também significa que o elemento humano da construção de nosso mundo digital é o alvo principal.

Esses SSCAs demonstram a crescente exploração de dependências open source críticas por invasores habilidosos e anônimos. Não podemos simplesmente parar de usar o open source, já que ele fundamenta o software moderno. Portanto, precisamos de uma mudança fundamental no futuro. Precisamos de mais protocolos de segurança proativos incorporados em todo o ciclo de vida de desenvolvimento, não somente quando estamos reagindo a violações. Isso inclui uma melhor verificação de dependências, práticas de segurança robustas para desenvolvedores e, como destacado pela resposta da XZ, um modelo de responsabilidade compartilhada em que fornecedores, comunidades e usuários investem na proteção do ecossistema. A escala de nossa dependência exige um investimento proporcional em sua segurança. Ainda estamos tentando alcançar adversários que claramente estão muitos passos à frente.

Ode à IA

Caso você tenha perdido, no último ano, a IA generativa (gen AI) explodiu, incluindo chatbots, assistentes de codificação e ferramentas criativas. O ritmo não está diminuindo, com a previsão de que a IA generativa cresça a uma taxa de 37% ao ano até 2030. Isso é, no mínimo, incompreensível. 

Mas, como acontece com qualquer tecnologia nova, há uma fase de lua de mel em que todos estão focados no que ela pode fazer. Em que velocidade isso funciona? Quanto ele pode gerar? Como isso pode mudar a maneira como fazemos quase tudo?

Mas agora que vemos o valor real, especialmente em setores altamente regulamentados, como saúde, finanças e governo, onde os erros podem ter grandes implicações, temos que começar a pensar sobre as coisas sérias. Como mantemos o uso da IA seguro e confiável? Podemos confiar que ele não vai bagunçar as coisas ou vazar informações privadas? Os tomadores de decisão dizem que manter os dados seguros já é a maior preocupação das pessoas em relação à IA este ano. Isso faz todo o sentido. Você não quer que suas informações pessoais sejam divulgadas ou que a IA tome decisões erradas porque não foram criadas com segurança. Como você viu acima, já temos algumas metas de alta visibilidade no open source. 

O que aprecio é que não estamos somente entrando na onda da IA; na verdade, estamos trabalhando para descobrir como tornar a IA mais segura. No entanto, essa não é uma tarefa fácil. 

Uma das primeiras coisas que a Red Hat destaca no documento Building Trust: Foundations of Security, Safety and Transparency in AI é a necessidade de separar uma vulnerabilidade de segurança de IA de um problema de segurança de IA:

• Vulnerabilidade de segurança: um hacker encontrando uma maneira de  no sistema de IA.
• Problema de segurança: a própria IA dizendo algo impreciso, tendencioso ou até mesmo prejudicial, mesmo que ninguém tenha "hackeado".

Esses problemas precisam ser abordados de maneira diferente, pois corrigir um bug não é o mesmo que ensinar a IA a não ser tóxica ou inventar coisas. Eles precisam de diferentes rulebooks.

É reconfortante ver que empresas como a Red Hat, governos como os da UE e dos EUA e vários grupos do setor estão trabalhando arduamente para descobrir isso. Eles estão tentando criar diretrizes, padrões e maneiras de rastrear esses diferentes riscos de IA. Eles querem criar essa tecnologia com responsabilidade desde o início, treinando seus engenheiros e criando designs seguros. O mais importante é que a Red Hat não está apenas falando, estamos criando.

Então, o que tudo isso significa? O boom da IA é empolgante e pode mudar muitas coisas. No entanto, tudo se resume à confiança. Como em qualquer bom relacionamento, a confiança é fundamental. Nosso relacionamento com a IA deve ser baseado na confiança para podermos obter todos os benefícios dela, e isso é mais do que demonstrações chamativas. Isso vem do trabalho árduo nos bastidores para garantir que a tecnologia esteja segura, protegida e se comporte conforme o esperado. Parece que as pessoas certas estão focadas nisso, o que é uma boa notícia. Precisamos ter cuidado e construir grades de proteção agora, em vez de tentar corrigir grandes problemas mais tarde. Precisamos de pessoas que confiem na IA para fazer isso!  

Nos bastidores, a agitação do SDLC

Em 2024, a Red Hat provou que, por trás de cada solução confiável, há muito esforço para garantir que nada seja desperdiçado.  Nossa abordagem vai além de simplesmente seguir os padrões de segurança do NIST. A Red Hat está desenvolvendo seus próprios métodos exclusivos para verificar se tudo o que criamos, incluindo tecnologias de IA, é confiável desde o início.

O Red Hat Secure Software Development Lifecycle (RHSDLC), que oferece nosso plano de criação de software com foco em segurança, agora está mais inteligente e ainda mais alinhado com os desafios de segurança atuais do mundo real. Mas não estamos apenas verificando as caixas. Estamos criando nossos próprios padrões, como o RHSDLC, para garantir que a cadeia de suprimentos de software tenha segurança reforçada do início ao fim, amadurecendo o procedimento de Aprovações Operacionais de Segurança (SOA). Isso inclui a verificação de ferramentas de terceiros, a automação de verificações e a sinalização de riscos antes que eles se tornem problemas. É como encontrar o vazamento enquanto ele continua pingando, em vez de esperar pela enchente. Dedicamo-nos a fortalecer a confiança dos clientes em nossas soluções, explorando minuciosamente os detalhes de segurança e priorizando a confiança, a transparência e a resiliência.

Adorei ver a padronização das análises de arquitetura de segurança (SARs) no RHSDLC. Essas análises oferecem suporte aos princípios de segurança clássicos e testados em batalha, como "dê acesso apenas ao que é absolutamente necessário", "crie suas defesas" e garantir que a segurança esteja integrada ao design da solução desde o primeiro dia. 

Por fim, temos o RapiDAST. Se você gosta de open source ou até mesmo de desenvolvimento de aplicações, essa ferramenta é uma joia escondida. É a ferramenta dinâmica de testes de segurança de aplicações da Red Hat e, em 2024, ela passou por grandes upgrades. Além de ficar mais poderoso, o RapiDASTS ficou mais fácil de usar. Por exemplo, ele oferece suporte para testes de operador do Kubernetes, melhor automação e uma interface muito mais simples. Agora, ela pode exportar os resultados diretamente para o Google Cloud Storage, tornando a colaboração mais eficiente.

A Red Hat está incorporando tudo isso diretamente em nossos pipelines de CI/CD, os mesmos sistemas que os desenvolvedores usam diariamente para criar e lançar soluções. E para aqueles que dependem de ferramentas, sejam eles desenvolvedores, profissionais de TI ou usuários finais tentando manter os sistemas seguros, um compromisso com o desenvolvimento com foco na segurança é realmente importante. Em um mundo com constantes ameaças cibernéticas, saber que seu fornecedor de software é extremamente focado na segurança, desde a fase de design até os testes e rastreamento de componentes, é reconfortante. A Red Hat trata a segurança como uma parte essencial da qualidade, e não apenas uma reflexão tardia.

Nos encontramos novamente em 2025

O relatório deste ano é um lembrete de que a segurança está sempre em movimento. Com as mudanças na forma como os CVEs são relatados, os riscos contínuos da cadeia de suprimentos, o crescente impacto da IA e a priorização das vulnerabilidades, há muitas coisas que os usuários devem considerar.

Ter relatórios transparentes como este é muito importante. Eles ajudam todos nós, de desenvolvedores a equipes de TI e leitores curiosos como eu, a ver o que está acontecendo, entender os desafios e fazer escolhas mais informadas. Do meu ponto de vista, não se trata apenas de prevenir problemas; como respondemos a eles, também é crítica. A maneira como a comunidade open source se uniu durante incidentes como o XZ Backdoor? Esse é o poder da colaboração em ação!

Leia o relatório Red Hat Product Security Risk Report 2024 na íntegra.