Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
A IA está prestes a ultrapassar a capacidade de detecção de vulnerabilidades de software – mas não a de corrigi-las.
Em abril de 2026, a Anthropic anunciou o Projeto Glasswing juntamente com onze grandes parceiros, incluindo AWS, Apple, Cisco, Google, JPMorgan Chase, a Linux Foundation, Microsoft e Palo Alto Networks.
A iniciativa gira em torno do Claude Mythos Preview, um modelo de ponta que já identificou milhares de vulnerabilidades de alta gravidade, incluindo falhas em todos os principais sistemas operacionais e navegadores da web. Algumas dessas falhas haviam passado despercebidas por décadas de auditorias realizadas por humanos — o que mudou completamente o panorama para quem desenvolve software com componentes de código aberto.
Embora o acesso seja limitado no momento, a tendência é clara: a detecção de vulnerabilidades está se tornando mais rápida, mais barata e cada vez mais automatizada — e não permanecerá restrita a um pequeno grupo de defensores.
A segurança da cadeia de suprimentos de código aberto sempre se resumiu a uma questão: quem é responsável por corrigir o quê – e com que rapidez isso é feito. Após o caso da Glasswing, a detecção de vulnerabilidades por IA está ocorrendo na velocidade das máquinas, enquanto a aplicação de correções ainda segue no ritmo do calendário.
Essa pressão se estende por duas fases distintas do risco associado ao código aberto: o que você instala e o que acontece depois. Uma delas diz respeito à confiança no próprio pacote. A outra diz respeito à possibilidade de as vulnerabilidades serem corrigidas. Ambas estão prestes a ser colocadas à prova de maneiras diferentes.
E os órgãos reguladores foram claros: se você distribuir o arquivo binário, a responsabilidade pelo bug é sua.
O Projeto Glasswing e a enxurrada de vulnerabilidades de exploração de código (CVE) que está chegando às suas dependências
O Mythos Preview não é um scanner mais rápido. Ele analisa bases de código complexas e produz exploits funcionais, não descobertas teóricas. A Anthropic restringiu o acesso aos parceiros do Glasswing justamente porque essa mesma capacidade acabará nas mãos de adversários. A janela de oportunidade para os defensores é estreita, e a maioria das equipes ainda não ajustou suas premissas.
Há duas consequências específicas que são importantes para as organizações que dependem de pacotes de código aberto.
Em primeiro lugar, o volume de CVEs vai aumentar. O Mythos já identificou milhares de bugs em códigos que passaram por auditorias rigorosas. As bibliotecas de código aberto de nível de produção que nunca receberam esse nível de análise passarão pelo mesmo tratamento à medida que modelos comparáveis chegarem ao mercado em geral. A maioria das equipes de segurança já está atrasada no processamento do acúmulo de CVEs existente.
Em segundo lugar, o intervalo entre a divulgação e a exploração é reduzido drasticamente. Um SLA de 30 dias para a aplicação de patches foi definido com base no intervalo entre a divulgação pública de um CVE e a existência de um exploit funcional para ele. O Mythos elimina esse intervalo em uma única sessão.
Se a sua estratégia de correção parte do pressuposto de um fluxo constante e controlável de CVEs em pacotes mantidos ativamente, ambas as partes dessa suposição estão prestes a se desmoronar.
Resumindo:
- A descoberta de vulnerabilidades está se acelerando
- A criação de exploits está se acelerando
- A velocidade de aplicação de patches não é
É nessa lacuna que o risco se agrava.
Você é responsável por todas as dependências que você distribui
A mudança regulatória passou mais despercebida do que o anúncio sobre IA, mas tem o mesmo peso.
Nos termos da Lei de Resiliência Cibernética da UE, os fabricantes são responsáveis pela segurança dos produtos com elementos digitais durante todo o período de suporte, incluindo todos os componentes de código aberto integrados. As multas podem chegar a € 15 milhões ou 2,5% do faturamento anual global. O fabricante é a entidade que coloca o produto no mercado. Não importa quem escreveu a dependência, se o mantenedor é remunerado ou se o projeto de origem foi abandonado. Se você comercializa o produto, você assume a responsabilidade.
FedRAMP seguiu a mesma linha. Espera-se que os provedores de serviços em nuvem mantenham a segurança de todos os componentes dentro de seus limites de autorização, com processos de aplicação de patches documentados e softwares em fim de vida (EOL) sinalizados como um problema conhecido de autorização. De acordo com FedRAMP 20x, as SBOMs que correspondem ao que está realmente em execução estão se tornando um requisito básico.
Os contratos com os clientes também acompanharam essa tendência. As equipes de compras agora solicitam SBOMs, documentos VEX e SLAs de patches como itens padrão. “Usamos uma biblioteca de terceiros” não é uma resposta válida quando uma vulnerabilidade atinge o ambiente de produção.
O modelo jurídico é simples de resumir. A responsabilidade acompanha o binário, e não a licença do código-fonte. A defesa baseada no princípio dos “muitos olhos” nunca teve validade jurídica e, após o caso Glasswing, também não tem validade técnica.
O código aberto apresenta dois riscos distintos
O código aberto é integrado à sua pilha de tecnologia com dois riscos distintos associados. O primeiro é a integridade da cadeia de suprimentos: o que realmente está contido no pacote no dia em que você o instala. O segundo é a aplicação de patches: a rapidez com que uma vulnerabilidade conhecida é corrigida e o que acontece quando não há correção à vista.
Esses são problemas distintos, com modelos de ameaça diferentes. Os ataques à cadeia de suprimentos são uma questão de credenciais e confiança. O Glasswing não tem nada a ver com eles, e esses ataques vêm se intensificando por conta própria há anos. É na aplicação de patches que o Glasswing muda o cenário, tanto durante a manutenção ativa quanto após o fim da vida útil (EOL). A combinação é que é a novidade. A mesma equipe de segurança que já lidava com uma taxa constante de ataques à cadeia de suprimentos agora está lidando com uma enxurrada de CVEs mais rápida e mais intensa em toda a árvore de dependências.
A responsabilidade não se importa com o tipo de problema que você enfrentou. Agora, vamos analisar cada um deles, um por um.
A ameaça desde o primeiro dia: pacotes comprometidos
O primeiro risco em qualquer dependência é o que ela contém no dia em que é instalada. Artefatos adulterados, contas de mantenedores invadidas e domínios falsos criados para se aproveitar de erros ortográficos vêm chegando ao ambiente de produção há anos por meio de instalações de registros que parecem confiáveis.
Março de 2026 o ataque à Axios é o exemplo mais notável dos últimos tempos: credenciais roubadas do principal mantenedor do projeto, um gancho malicioso pós-instalação distribuído a cerca de 100 milhões de usuários que baixavam o software semanalmente durante três horas.
Outros casos recentes incluem o worm Shai-Hulud e o incidente com a CLI do Bitwarden que teve como alvo as credenciais de uma ferramenta de programação de IA.
Essa categoria segue seu próprio caminho. O Glasswing não torna os ataques à cadeia de suprimentos do npm nem mais fáceis nem mais difíceis, e o Mythos não pode ajudar um invasor a comprometer a conta de um mantenedor. Mas a ameaça vem se intensificando há anos, impulsionada apenas pelos incentivos dos invasores, e, de acordo com a CRA, ela se enquadra na mesma categoria de responsabilidade que qualquer outro produto que você forneça. A detecção ocorre horas após o fato.
A prevenção exige que a fonte do pacote seja verificada, assinada e recompilada a partir de código-fonte auditável, em vez de ser obtida diretamente de um repositório público.
A ameaça da lacuna de atualizações: ativas e em fim de vida útil (EOL)
Os ataques à cadeia de suprimentos dizem respeito a quem controla o artefato. A lacuna de atualização diz respeito a algo diferente: a rapidez com que um bug conhecido em um pacote legítimo e não adulterado é corrigido no código que você executa.
Isso se manifesta de duas formas: patches lentos em bibliotecas mantidas e a ausência total de patches nas bibliotecas em fim de vida (EOL). O Glasswing agrava ambas as situações.
Quando as correções são lançadas após a descoberta de vulnerabilidades
O tempo necessário para a aplicação de correções varia bastante em todo o ecossistema. Projetos de primeira linha, com divulgação coordenada, lançam a correção assim que o CVE é divulgado publicamente. A “cauda longa” avança mais lentamente: levam horas para correções triviais, semanas ou mais quando o mantenedor precisa fazer um backport, preservar a compatibilidade da API ou conciliar isso com seu trabalho diário.
A implantação no seu ambiente, então, acrescenta tempo ao tempo previsto inicialmente.
Aquela janela costumava ser aceitável. O desenvolvimento de exploits era lento o suficiente para que os defensores tivessem uma vantagem significativa sobre os invasores.
O Mythos elimina essa vantagem inicial. A descoberta e a exploração agora ocorrem em uma única sessão, e essa capacidade não ficará restrita aos defensores. Assim que modelos semelhantes chegarem às mãos dos adversários, o período de aplicação de patches se tornará um período de exposição. Quando o patch for lançado, a exploração já estará em circulação há dias.
O pacote está ativo e o mantenedor responde prontamente. Nada disso ajuda um sistema que foi comprometido no terceiro dia de um ciclo de atualizações de quatorze dias.
Bibliotecas EOL após o Glasswing
O período após a data de fim de vida útil (EOL) é o intervalo sem atualizações, durante o qual não haverá mais nenhuma atualização, nunca mais.
O Log4Shell (CVE-2021-44228) ainda está entre as 10 vulnerabilidades mais visadas, mais de quatro anos após sua divulgação, porque o Log4j continua incorporado em aplicativos legados que ninguém quer migrar. O mesmo padrão se repete em toda a longa lista de bibliotecas sem manutenção: bugs conhecidos, exploits públicos e uma base instalada cuja atualização causaria transtornos excessivos. O relatório “State of DevSecOps 2026” da Datadog revelou que serviços executados em versões de linguagem em fim de vida (EOL) apresentam uma taxa de vulnerabilidades exploráveis de 50%, em comparação com 31% para as versões com suporte, com a mediana das dependências apresentando um atraso de 278 dias em relação à versão mais recente.
Agora, aplique a descoberta da classe Glasswing a essa população.
Um patch para uma biblioteca mantida acaba sendo lançado, mesmo que lentamente. Quando o Mythos detecta uma vulnerabilidade de dia zero em algo como o Python 3.7, uma versão do Spring Framework em fim de vida útil (EOL) ou qualquer um dos milhares de pacotes npm cujo mantenedor fez seu último comentário há dois anos, o bug se torna de conhecimento público e fica para sempre sem correção. As atualizações forçadas são a solução que todos buscam em primeiro lugar. Na prática, elas exigem migrações com mudanças radicais em códigos de aplicativos que não são alterados há anos, com risco de regressão e custos de engenharia que as equipes de conformidade não conseguem arcar.
É nesse ponto que o EOL deixa de ser uma questão de manutenção e passa a ser uma condição permanente de segurança.
Em um mundo pós-Glasswing, o software sem manutenção não é apenas arriscado — ele é previsivelmente e repetidamente vulnerável a explorações, sem que jamais seja lançada uma correção.
Como o SecureChain para software de código aberto preenche essa lacuna
SecureChain para software de código aberto substitui seus registros públicos de pacotes por uma fonte controlada e continuamente protegida. Seus desenvolvedores continuam trabalhando da mesma forma que já fazem.
Três coisas mudam por trás de uma única URL de registro:
- Cada pacote é recompilado a partir do código-fonte verificado
Cada pacote é reconstruído em um ambiente seguro e isolado a partir de código-fonte auditável. Sem binários herdados, sem artefatos opacos do desenvolvedor original.
- O malware é bloqueado antes de chegar à sua pilha
Cada pacote é analisado no nível do código-fonte em busca de código malicioso, ganchos de instalação suspeitos e assinaturas de ameaças conhecidas antes de chegar ao registro.
- As atualizações são fornecidas continuamente – mesmo após o fim do ciclo de vida
A SecureChain fornece patches de acordo com o SLA à medida que surgem novos CVEs, incluindo aqueles para os quais nossa equipe contribui quando o desenvolvimento original não atende às necessidades. A cobertura continua após o término da manutenção, na versão que você já está utilizando, sem atualizações forçadas nem reescritas de código.
Pronto para auditoria desde o primeiro dia
A vertente de conformidade desse problema tem seus próprios resultados esperados. Cada pacote enviado pela SecureChain contém proveniência de compilação SLSA Nível 3 de proveniência da compilação, uma SBOM assinada que corresponde ao binário que você recebe e documentos VEX que indicam se cada CVE sinalizado no pacote foi corrigido na versão que você está executando ou se não se aplica a ela.
Esses três artefatos são exatamente o que as equipes de auditoria e aquisição solicitam. A proveniência SLSA Nível 3 comprova que o pacote foi compilado a partir do código-fonte que você pode inspecionar, em um ambiente de compilação fortificado, e que não sofreu alterações indevidas durante o transporte. A SBOM informa ao seu auditor exatamente o que está em produção. O documento VEX indica ao seu scanner o que já recebeu correções e o que não se aplica a esta versão, para que sua equipe não precise classificar CVEs que já foram corrigidos.
Acrescente a isso um compromisso de correção respaldado por um SLA, e o aumento no volume de CVEs não se traduz em um aumento nas constatações de auditoria. A documentação de que sua equipe de conformidade precisa é gerada como um efeito colateral das próprias correções.
O que suas equipes ganham com isso
O código aberto continua sendo a melhor maneira de desenvolver software. A suposição, sob pressão, é que a adoção de um pacote é uma decisão única, sem custos contínuos com segurança.
SecureChain oferece a você a velocidade e a flexibilidade do código aberto sem os riscos.
Sua equipe se concentra no desenvolvimento de produtos, em vez de ficar correndo atrás de problemas de segurança. Seus desenvolvedores continuam instalando os pacotes que já utilizam. Seu pipeline de compilação aponta para o SecureChain, em vez do registro público. Os patches continuam sendo disponibilizados para os componentes que realmente importam, inclusive aqueles que a comunidade de código aberto já deixou para trás. A proveniência e as SBOMs são geradas automaticamente. Quando surgir a próxima divulgação do tipo Glasswing, a resposta será um aumento de versão, e não um incidente que se prolongue por seis semanas.
Você não precisa substituir sua pilha para reduzir esse risco — mas precisa mudar a forma como ela é mantida.
A responsabilidade pelo que você envia não muda. O trabalho de transportá-lo é que muda.
