Elimine as lacunas de correção com o Lightwell

Resumo executivo

Em abril de 2026, o Claude Mythos Preview da Anthropic se tornou o primeiro modelo de IA a descobrir, validar e desenvolver, de forma autônoma, exploits para vulnerabilidades de software de dia zero. Em menos de sete semanas de testes, o Mythos revelou mais de 2.000 vulnerabilidades até então desconhecidas nos principais sistemas operacionais (SO) e navegadores web. No kernel do Linux®, o software que executa a maioria dos servidores do mundo, incluindo redes centrais de provedores de serviços de telecomunicações e infraestrutura 5G nativa em nuvem, o modelo encontrou e encadeou várias vulnerabilidades de forma autônoma, e concluiu a escalada de privilégios: de acesso de usuário comum ao controle completo da máquina, sem qualquer intervenção humana.¹

Para os provedores de serviços de telecomunicações, esse não é um risco distante. É uma ameaça estrutural imediata que agrava os desafios que os Chief Information Security Officers (CISOs) e equipes de segurança já enfrentam: infraestrutura massiva, superfícies de ataque em expansão e um pipeline de correções que já não acompanhava o ritmo da descoberta convencional de vulnerabilidades.

O setor reagiu. O Project Glasswing leva o poder de varredura da inteligência artificial para organizações de infraestrutura crítica. O Communications Cybersecurity Information Sharing and Analysis Center (C2 ISAC) coordena a inteligência sobre ameaças em tempo real entre as operadoras dos EUA. Iniciativas regionais, como o GSMA Telecommunications Information Sharing and Analysis Centre (T-ISAC) e o European Telecommunications Information Sharing and Analysis Centre (ET-ISAC), fortalecem a conscientização transfronteiriça. Esses passos são importantes, mas compartilham uma limitação fundamental. Eles aceleram como o setor encontra e comunica vulnerabilidades, mas não resolvem o problema mais difícil: a velocidade com que essas vulnerabilidades são corrigidas nos ambientes de produção.

O Lightwell soluciona essa lacuna diretamente. Como uma subscrição de segurança gerenciada, apoiada pela engenharia da IBM e da Red Hat, o Lightwell fornece correções assinadas e com backporting para dependências open source de terceiros qualificadas, nas versões que os provedores de serviços já executam em produção. Combinado aos recursos de segurança da camada de infraestrutura da Red Hat, o Lightwell oferece aos provedores de serviços um caminho para a correção de vulnerabilidades em toda a arquitetura, do kernel à aplicação.

A escala da descoberta de vulnerabilidades com tecnologia de IA não tem precedentes. Em seu primeiro mês de operação, o Project Glasswing — consórcio da Anthropic de parceiros de segurança defensiva que usa o modelo Mythos — revelou 6.202 vulnerabilidades de gravidade alta ou crítica em mais de 1.000 projetos open source. Uma verificação independente realizada em um subconjunto dessas descobertas confirmou uma taxa de 90,6% de verdadeiros positivos.²

Esses números por si só já seriam significativos. O que os torna urgentes é a realidade da remediação. Das aproximadamente 23.000 vulnerabilidades descobertas, cerca de apenas 75 foram corrigidas e documentadas nos primeiros meses, segundo o CSO da Deutsche Telekom, Thomas Tschersich. Ele também observou que alguns fornecedores e mantenedores de software pediram à Anthropic para reduzir o ritmo dos relatórios, pois não conseguem absorver as correções com a agilidade necessária.³

O Data Breach Investigations Report (DBIR) de 2026 da Verizon confirma esse padrão no nível do setor. Pela primeira vez em seus 19 anos de história, o DBIR constatou que a exploração de vulnerabilidades superou o roubo de credenciais e o phishing como o principal vetor de acesso inicial para violações, correspondendo a 31% de todos os incidentes. O volume de instâncias de vulnerabilidade alcançou 527,3 milhões em 2025: um aumento de oito vezes em relação a 2022. Enquanto isso, o tempo médio até a aplicação total de patches piorou, atingindo 43 dias, e a proporção de vulnerabilidades exploradas conhecidas pela Cybersecurity and Infrastructure Security Agency (CISA) totalmente corrigidas caiu de 38% para 26%.⁴

A Anthropic alertou em junho de 2026 que outras empresas e desenvolvedores de IA criariam recursos ofensivos equivalentes entre seis a 12 meses. A janela de preparação dos provedores de serviços é estreita e está se fechando.⁵

Por que provedores de serviços estão particularmente expostos a riscos

As redes de telecomunicações estão entre os ambientes tecnológicos mais complexos do planeta. Elas também estão entre os alvos mais frequentes de ataques e enfrentam diversos desafios únicos.

Infraestrutura legada anterior aos modelos de segurança modernos. Como Dave Harcourt, Chief Security Authority da BT, observou em 2024, grande parte da infraestrutura de telecomunicações em operação hoje foi projetada em uma época que jamais poderia prever o cenário de ameaças atual.⁶ Os provedores de serviços gerenciam vastos ambientes brownfield: décadas de elementos de rede, sistemas operacionais e protocolos sobrepostos ao longo de anos de expansão, fusões e transições tecnológicas. Mais de 45% das vulnerabilidades descobertas nesses ambientes continuam sem patches de correção após 12 meses.⁴

Uma superfície de ataque quase sem precedentes em qualquer setor. O ambiente dos provedores de serviços abrange sistemas de faturamento e CRM, protocolos de rede principal como SIP e Diameter, APIs de arquitetura baseada em serviços 5G, infraestrutura de transporte e roteamento, sistemas de interceptação legal e milhões de dispositivos de rede. Grande parte disso executa software proprietário de fornecedores que os provedores de serviços não conseguem auditar nem aplicar patches de forma independente.

Alvo sistemático de agentes de ameaça sofisticados. A campanha Salt Typhoon comprometeu pelo menos nove provedores de serviços nos Estados Unidos, acessando sistemas de interceptação legal e registros detalhados de chamadas de mais de 1 milhão de usuários.⁷ Tempos de permanência de até dois anos passaram despercebidos. Em Cingapura, a campanha UNC3886 comprometeu todos os quatro provedores de serviços nacionais, exigindo uma contraoperação coordenada que durou 11 meses.⁹ No Canadá, um invasor roubou pelo menos 700 TB de dados de um grande provedor de serviços.¹⁰ Esses não são incidentes isolados: refletem campanhas contínuas e estruturadas voltadas especificamente à infraestrutura de telecomunicações.

A dependência compartilhada de fornecedores cria riscos correlacionados. Os provedores de serviços do mundo todo dependem de um grupo restrito de fornecedores de equipamentos para redes de acesso via rádio (RAN), bem como de infraestrutura central e de transporte. Uma vulnerabilidade no software de um único fornecedor afeta vários provedores de serviços simultaneamente. A interconexão entre operadoras adiciona uma segunda dimensão de risco correlacionado: ao explicar por que o setor formou o C2 ISAC, o líder de cibersegurança da T-Mobile, Mark Clancy, observou que, em casos como fraude de SIM box, uma operadora pode identificar o dispositivo na rede enquanto o servidor de comando e controle reside na infraestrutura de outra operadora, exigindo investigação conjunta de ambos os lados.¹¹

Defesas atuais: Grande progresso, mas com uma lacuna crítica

O setor não está parado. Três grandes iniciativas surgiram em resposta direta ao cenário de ameaças em constante evolução. Cada uma oferece valor real, mas deixa uma lacuna específica sem solução.

O Project Glasswing oferece às organizações participantes acesso ao Mythos para varredura proativa de vulnerabilidades. Mais de 200 organizações em 15 países aderiram, incluindo provedores de serviços como Verizon, AT&T e BT. O Glasswing já revelou milhares de vulnerabilidades críticas em projetos open source essenciais para a infraestrutura dos provedores de serviços. Mas o seu alcance tem limites. Nokia, Ericsson e outros grandes fornecedores de equipamentos de rede (NEPs) não fazem parte da iniciativa. O software proprietário executado em equipamentos de RAN, núcleo e transporte, que formam a espinha dorsal das redes dos provedores de serviços, não passa por varredura. Os provedores de serviços não conseguem auditar nem aplicar patches nesse código de maneira independente. O ciclo de correção continua totalmente dependente dos prazos dos fornecedores.

O C2 ISAC reúne os CISOs de oito grandes provedores de serviços dos EUA para compartilhamento de informações em tempo real exclusivo do setor privado. Ele preenche uma lacuna crítica de coordenação, permitindo compartilhar indicadores de comprometimento, técnicas de ataque e playbooks de mitigação em velocidade operacional. Os primeiros resultados incluem técnicas de detecção de fraudes com caixas de módulo de identidade do assinante (SIM) entre operadoras e respostas coordenadas a redes proxy residenciais. Mas o C2 ISAC atualmente tem foco nos EUA, sem membros de provedores de serviços internacionais, nem participação de fornecedores de NEP ou sistemas de suporte operacional/sistemas de suporte de negócios (OSS/BSS). Trata-se de um mecanismo de compartilhamento de inteligência, não de um motor de correção.

ISACs e frameworks regionais, incluindo GSMA T-ISAC (global), ET-ISAC (Europa), ICT-ISAC (Japão) e outros, agregam camadas de conscientização, alinhamento regulatório e cooperação transfronteiriça. O ET-ISAC da Europa realiza chamadas quinzenais sobre inteligência de ameaças entre equipes de resposta a emergências computacionais e centros de operações de segurança (CERT-SOC), além de um benchmark anual de segurança. O GSMA T-ISAC inclui fornecedores ao lado de provedores de serviços, algo que o C2 ISAC não faz no momento. Essas são estruturas valiosas para visibilidade e prontidão. Mas nenhuma delas fornece patches.

O ponto em comum entre as três é a melhoria na agilidade com que o setor identifica e compartilha dados de ameaças. Contudo, essas iniciativas não aceleram a correção prática das vulnerabilidades.

Tschersich, da Deutsche Telekom, resumiu a questão central em resposta direta às constatações do Glasswing: "A IA encontra vulnerabilidades mais rápido do que nunca. Mas encontrar com mais rapidez não significa corrigir com mais rapidez. Cada dia economizado na aplicação de patches faz a diferença."³ 

A crise da remediação: Onde reside o verdadeiro risco

Os dados são claros. O principal desafio de segurança do setor migrou da detecção para a correção.

90% do código das aplicações corporativas consiste em dependências open source ou de terceiros. A base de código open source média auditada pela Black Duck agora carrega 581 vulnerabilidades conhecidas — número que dobrou em um único ano.¹² O tempo médio até a exploração caiu para 7 dias negativos, o que significa que invasores exploram vulnerabilidades rotineiramente por uma semana inteira antes dos patches estarem disponíveis.¹³

As abordagens atuais de correção não conseguem acompanhar esse ritmo. Quando uma ferramenta de varredura sinaliza uma CVE (vulnerabilidade e exposição comum) crítica em uma dependência open source transitiva, a resposta típica exige que os desenvolvedores investiguem, obtenham uma nova versão do pacote, recompilem a aplicação, testem possíveis quebras e reescrevam código para acomodar a nova versão. Em ambientes regulamentados, onde os provedores de serviços devem manter configurações de software testadas e certificadas, upgrades de versão forçados podem disparar ciclos completos de recertificação.

As ferramentas de varredura realizam um trabalho importante. Elas mostram às equipes de segurança onde estão os problemas. Mas não os corrigem. O resultado de um scanner é painel de informações com os dados obtidos. O risco se acumula na lacuna entre esse dashboard e um artefato corrigido, assinado e pronto para produção.

Soluções paliativas internas — como bifurcação de pacotes para aplicação manual de patches, acúmulo de risco pendente e adiamento de upgrades para preservar a estabilidade — criam seus próprios problemas. Cada bifurcação interna que diverge do upstream, gera encargos de manutenção permanentes. Pendências de risco culminam em falhas de auditoria. Adiar os upgrades aumenta a dívida técnica. Nenhuma dessas abordagens possui escalabilidade quando a IA gera milhares de novas vulnerabilidades a cada mês.

O Lightwell é uma subscrição de segurança gerenciada da Red Hat e da IBM que ajuda as organizações a resolver o problema mais complexo da segurança open source: Corrigir vulnerabilidades sem interromper a produção. O Lightwell ajuda a superar esse desafio de diversas formas:

Patches com backporting em versões fixadas. Quando uma vulnerabilidade é encontrada em uma determinada dependência open source de terceiros, o Lightwell disponibiliza um artefato corrigido na versão exata que o provedor de serviços já executa. Não há upgrades forçados, alterações no código da aplicação nem riscos de regressão. Para organizações de setores regulamentados e que precisam manter configurações testadas e certificadas, essa abordagem elimina o dilema entre conformidade de segurança e estabilidade operacional.

Do acesso à rede a uma colaboração mais profunda. O Lightwell está disponível em dois caminhos. A Lightwell Network, com disponibilidade geral desde 8 de julho de 2026, fornece acesso a fluxos de correção disponíveis e artefatos de segurança para dependências qualificadas. Para os provedores de serviços que exigem uma coordenação mais aprofundada, o modelo Lightwell Clearinghouse Premier — disponível de forma limitada — oferece suporte à priorização de vulnerabilidades sob medida, divulgação antecipada coordenada e prazos de correção definidos. O objetivo do modelo de clearinghouse é reduzir o retrabalho que surge quando cada organização faz a varredura, triagem e aplicação de patches para as mesmas vulnerabilidades, mas de forma independente. Em vez disso, a clearinghouse coordena correções que beneficiam todos os participantes.

Documentação para conformidade. Os artefatos do Lightwell acompanham metadados de segurança, incluindo SBOM (lista de materiais de software) CycloneDX, notificações VEX (Vulnerability Exploitability eXchange), integridade de compilação SLSA nível 3 e assinatura criptográfica quando aplicável. Para provedores de serviços que cumprem a NIS2, a Lei de Resiliência Cibernética (CRA), a DORA e outras exigências regulatórias, esses artefatos auxiliam na documentação de conformidade gerada junto com o pacote, e não compilada manualmente após a entrega.

Integração simples. O Lightwell se integra à infraestrutura de compilação existente por meio de uma única alteração de configuração. Os provedores de serviços direcionam seus repositórios de artefatos existentes, como Artifactory, Nexus e Maven, ao registro da Red Hat. Com essa abordagem, não há necessidade de substituições completas nem novas ferramentas de CI/CD.

Profundidade de engenharia em escala. A Red Hat e a IBM contam com engenheiros dedicados que mantêm, em conjunto, diversos projetos open source upstream relevantes para o Lightwell. As correções não passam apenas por backporting: elas também são integradas ao upstream para beneficiar toda a comunidade. Os provedores de serviços podem fazer upgrade sem reintroduzir as mesmas vulnerabilidades. A triagem baseada em IA amplia o alcance do conhecimento humano frente ao grande volume de descobertas automatizadas.

Segurança full-stack: Do kernel à aplicação

O Lightwell expande um serviço que a Red Hat já entrega na camada de infraestrutura.

A atuação da Red Hat frente à descoberta acelerada de vulnerabilidades opera em dois níveis distintos que os provedores de serviços precisam usar em conjunto.

Camada de infraestrutura (disponível para todos os clientes Red Hat). O Red Hat Lightspeed identifica vulnerabilidades no Red Hat® Enterprise Linux, no Red Hat OpenShift® e em pacotes no nível do sistema. O Red Hat Satellite gerencia conteúdos, erratas e ambientes de ciclo de vida. O Red Hat Ansible® Automation Platform oferece suporte à correção orientada a eventos em grande escala e aplica patches automaticamente, impondo configurações e fechando o ciclo da detecção à correção no sistema operacional e na plataforma.

Camada de dependências da aplicação (Lightwell). As bibliotecas open source incorporadas às aplicações dos provedores de serviços operam acima do SO. Um provedor de serviços que aplica patches com perfeição no Red Hat Enterprise Linux ainda pode ser atacado por meio de uma vulnerabilidade sem patch no Spring Framework, Log4j ou em qualquer uma das milhares de dependências em uma aplicação de OSS/BSS. O Lightwell elimina essa lacuna fornecendo correção para aplicações em Java, Python, JavaScript e .NET, com suporte a mais linguagens e plataformas previsto em expansão futura.

Juntas, essas duas camadas oferecem aos provedores de serviços uma cobertura consistente de correção que vai do kernel às dependências de aplicações qualificadas. Essa abordagem se conecta diretamente à plataforma nativa em nuvem e aos recursos de automação que muitos provedores de serviços já utilizam com a Red Hat, levando o mesmo modelo operacional a um domínio historicamente não gerenciado.

A transição de uma segurança orientada à detecção para uma segurança orientada à correção não é opcional. Os dados mostram por que ela é indispensável: O volume de vulnerabilidades cresce de forma exponencial, os índices de correção caem e a janela de exploração ficou negativa. Cada dia economizado na aplicação de patches reduz a exposição às vulnerabilidades. O CISO de um provedor de serviços deve:

Avaliar a velocidade de correção. Medir o tempo real entre a detecção da vulnerabilidade e o artefato corrigido em produção, tanto na camada de infraestrutura quanto na camada de dependências da aplicação. Se esses prazos são medidos em semanas ou meses, a lacuna está crescendo mais rápido do que a média do setor.

Mapear a exposição a dependências open source. Compreender quantos componentes open source estão integrados à sua cadeia de suprimentos de aplicações e quais deles estão fora da cobertura atual de patches da plataforma. Se a resposta for "não sabemos", isso em si já é um sinal de alerta.

Avaliar a maturidade de CI/CD para correção automatizada. O valor do Lightwell depende da capacidade do provedor de serviços de adotar artefatos corrigidos, recompilar, testar e reimplantar em um intervalo adequado. Provedores de serviços com pipelines consolidados de DevSecOps e CI/CD obterão o retorno mais rápido. Quem ainda não tem essa estrutura deve priorizar sua construção. À medida que o programa Lightwell expande disponibilidade e cobertura, a preparação antecipada posiciona os provedores de serviços para agir rapidamente quando o serviço estiver disponível em sua região.

Fortalecer toda a arquitetura. Conecte a correção na camada de infraestrutura (Red Hat Enterprise Linux, Satellite, Ansible Automation Platform) à estratégia da camada de aplicação para eliminar a lacuna entre um sistema operacional com patches aplicados e dependências desatualizadas.

Comece a usar o Red Hat Consulting Secured Platform and Pipeline Velocity Assessment. Esse serviço foi desenhado para ajudar você a avaliar, mapear e analisar seu ambiente, garantindo uma transição de arquiteturas eficiente e sem interrupções. O Red Hat Services Accelerator para Lightwell oferece flexibilidade para alocar especialistas onde forem mais necessários, acelerando correções, ampliando a automação de segurança e padronizando plataformas resilientes em todo o seu ambiente.

Entre em contato com seu representante Red Hat para agendar uma reunião com especialistas.