- Com a descoberta de vulnerabilidades baseada em IA superando a velocidade de resposta dos mantenedores, a Akrites nasce como uma colaboração da indústria para reforçar em conjunto softwares open source essenciais
- A descoberta de vulnerabilidades graves antes levava semanas para especialistas, mas agora modelos de IA conseguem encontrar várias vulnerabilidades em minutos, aumentando rapidamente a carga de resposta
- AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft e GitHub, NVIDIA, OpenAI, Red Hat, Rust Foundation, entre outros, decidiram coordenar correções upstream e divulgações responsáveis
- Para reduzir relatos duplicados e patches conflitantes, a Akrites oferecerá um ponto confidencial de coordenação e uma Security Incident Response Team dedicada; para pacotes essenciais sem mantenedores, também atuará como mantenedora de último recurso
- Como, após a divulgação de um patch, atacantes podem usar IA para fazer engenharia reversa da vulnerabilidade, o critério de sucesso não é a divulgação em si, mas a distribuição do patch até os sistemas reais
A velocidade da segurança open source transformada pela IA
- O open source é a base da infraestrutura e dos serviços essenciais dos quais as pessoas dependem todos os dias, como bancos, telecomunicações e utilities
- Como os mesmos componentes open source são amplamente usados em toda a pilha tecnológica, muitos sistemas passam a compartilhar as mesmas falhas potenciais
- A IA altera o equilíbrio entre atacantes e defensores e reduz a estrutura de custos para descobrir e reutilizar vulnerabilidades
- Antes, encontrar uma vulnerabilidade grave levava semanas para especialistas, mas agora máquinas podem fazer isso em minutos
- Em alguns casos, um modelo de IA retorna várias vulnerabilidades em uma única execução
- A mesma capacidade pode ser usada na defesa, mas, se abusada, a descoberta de vulnerabilidades pode ser transformada em pipeline
A estrutura em que relatos duplicados pressionam mantenedores
- Os processos tradicionais de resposta e divulgação de segurança funcionavam com várias organizações e equipes atuando de forma frouxamente separada, o que podia levar ao tratamento simultâneo do mesmo problema ou à geração de patches conflitantes e múltiplos relatórios
- Se dezenas de empresas escaneiam a mesma biblioteca de forma independente e enviam seus próprios relatórios, os mantenedores acabam soterrados pelo ruído
- Quanto mais partes souberem de uma vulnerabilidade ainda não corrigida, maior também será a possibilidade de vazamento antes da correção, e esse risco se espalha por todo o ecossistema
- Mesmo respostas bem-intencionadas, sem coordenação, podem piorar o problema e desperdiçar tempo
A abordagem de resposta conjunta da Akrites
- A Akrites nasce como um esforço para distribuir sistemas e ferramentas conjuntos para encontrar, corrigir e divulgar de forma responsável vulnerabilidades em softwares open source essenciais
- Entre os participantes estão Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft e GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler, entre outros
- O centro da resposta é o upstream, onde estão os mantenedores
- Oferece um único local confidencial e baseado em confiança para coordenar a descoberta, a correção e a divulgação de vulnerabilidades
- Uma Security Incident Response Team dedicada se torna, para os mantenedores, um parceiro único e previsível em vez de inúmeros relatos não coordenados
- As correções devem voltar aos repositórios originais de cada projeto e aos fluxos dos mantenedores
- Quando um pacote essencial não tiver mantenedor, a Akrites afirma que atuará como mantenedora de último recurso para que as correções possam ser entregues a tempo
Por que a distribuição é mais importante que a divulgação do patch
- Quando um patch é divulgado, atacantes podem usar IA para fazer rapidamente engenharia reversa da vulnerabilidade real, desenvolver exploits e iniciar ataques
- Portanto, o sucesso da Akrites deve ser medido não por saber se o patch foi divulgado, mas se ele foi distribuído aos sistemas reais
- A Akrites pretende elevar o nível de coordenação trabalhando com proprietários e operadores de infraestrutura essencial, iniciativas da sociedade civil e governos
- A confidencialidade não é negociável; como falhas não divulgadas em pacotes amplamente distribuídos são, na prática, armas, a prioridade é evitar vazamentos
O peso e os compromissos destacados pelas organizações participantes
- A Endor Labs afirmou que, entre milhares de vulnerabilidades open source identificadas nos últimos meses, a parcela corrigida foi de menos de 5%
- A OpenInfra afirmou que a comunidade OpenStack emitiu 20 avisos de segurança apenas neste trimestre, enquanto em todo o ano de 2025 foram 2
- A JPMorganChase avalia que, como a IA comprimiu o tempo entre descoberta e exploração de vulnerabilidades para algo próximo do tempo real, também é preciso reduzir o tempo da correção à distribuição
- Chainguard, Sonatype, RapidFort, Red Hat e outras defenderam que a correção de vulnerabilidades deve ocorrer por meio de coordenação upstream, dentro do software original e do fluxo dos mantenedores, em vez de ficar dispersa em forks ou atrás de muros proprietários
- As organizações participantes se comprometeram a dedicar equipes de engenharia, expertise em segurança, financiamento e tecnologia de IA para fortalecer o software compartilhado
1 comentários
Opiniões do Hacker News
Muitos envolvidos com open source inevitavelmente vão olhar para a lista de empresas participantes com ceticismo, e com razão
A questão central é como colocar em prática “encontrar, corrigir e divulgar com responsabilidade vulnerabilidades em softwares open source críticos”. Se contribuírem pelos canais existentes e com pull requests, podem caminhar junto com a comunidade; mas, se fizerem fork sob o pretexto de “segurança”, podem excluir a comunidade, dividir recursos e, no longo prazo, matar muitos projetos. Bug bounty tem potencial, mas para falhas críticas talvez a velocidade e o timing da divulgação não se alinhem, e apoio financeiro também tem efeito limitado se não vier combinado com apoio aos mantenedores
A PQCA dá acesso a hardware com créditos da AWS para rodar provas e CI, e também mantém mentorias pagas. A OWF também oferece créditos da AWS e hospedagem de serviços para testes. A LFDT tem oferecido mentorias pagas, custos de revisão da Trail of Bits, organização de eventos, o summit de mantenedores em Nova York, suporte a grandes runners de CI no GitHub etc. Nossa equipe, pelos padrões de relações com desenvolvedores da OWF/PQCA/LFDT, tem só 3 funcionários em tempo integral, 1 contratado e 1 gerente, mas trabalhamos bastante para ajudar os desenvolvedores
LFDT: https://www.lfdecentralizedtrust.org/
OWF: https://openwallet.foundation/
PQCA: https://pqca.org/
Exemplo de benchmark da PQCA: https://pq-code-package.github.io/mldsa-native/dev/bench/
Seja qual for o formato, isso precisa ser distribuído de modo que um único ponto central ou uma única entidade não possa exercer controle
Falam de contribuição financeira, mas também importa como e para quê ela será feita. A maioria dos projetos não está preparada para receber ou aproveitar doações. Ainda assim, seria bom se todos os projetos open source pudessem receber acesso substancial a IA para revisar codebases e pull requests, reduzindo o peso da manutenção, e já existem algumas tentativas nesse sentido
Não passa de teatro corporativo
A Microsoft diz que vai “contribuir com expertise, recursos e tecnologia de IA para identificar e corrigir vulnerabilidades com responsabilidade”, mas a Microsoft opera o NPM e o GitHub e tem acesso aos melhores modelos de IA e a datacenters gigantescos. Mesmo assim, a segurança dos próprios produtos está piorando rapidamente, e seus serviços estão virando hubs centrais para a disseminação de vários exploits
Para ver como a Microsoft lida com problemas de segurança em seus próprios projetos open source, recomendo esta thread no GitHub: https://github.com/dotnet/efcore/issues/38257
O EF Core atualmente distribui uma versão do SQLite com uma vulnerabilidade séria. Esse problema foi descoberto há mais de um ano, e o SQLite corrigiu em uma semana, mas o EF Core não marcou o driver como vulnerável até que usuários voltassem a reportar recentemente e discutissem com os desenvolvedores. A correção para a versão estável atual do .NET Core está prevista para entrar só daqui a cerca de dois meses
Depois da aquisição, em vez de continuar essa linha com o VSCode, a Microsoft criou um clima de desdém em relação ao Electron, e agora muita gente odeia Electron sem nem conseguir explicar por quê. O VSCode nem sequer fez fork do Atom; foi recriado do zero de forma parecida, ficou maior e mais lento, e agora ainda veio com Copilot embutido. No fim, voltei para o Pulsar, um bom fork do Atom
A Microsoft sempre faz aquisições de olho em oportunidades e na dinâmica competitiva, mas raramente usa bem o que compra. Acaba eliminando bons funcionários e bom código e estragando os produtos. Mesmo assim, não entendo por que todo mundo continua usando produtos da Microsoft. É preciso sair do LinkedIn e migrar juntos para outro sistema de controle de versão. Enquanto os desenvolvedores open source não mostrarem isso com ações, e não só com palavras, a Microsoft vai continuar piorando
Não vamos fazer isso. Vamos apenas fazer declarações grandiosas, deixar empresas comerciais destruírem tudo e depois reclamar muito da situação, mesmo sem termos feito absolutamente nada
Daqui para frente, acho que vai surgir um movimento que eu chamo de undo fork. É um fork que volta ao ponto anterior ao início da loucura para repensar as coisas, algo que só pessoas não presas a demandas comerciais podem fazer
Sempre aconselho quem se interessa por open source a manter distância da Linux Foundation. Hoje em dia ela virou uma barreira, em vez de viabilizar a liberdade de software
Para proteger o open source, é preciso começar não com palavras, mas com apoio concreto a projetos e desenvolvedores
Do ponto de vista de um desenvolvedor do OpenBSD, fornecer hardware novo aos desenvolvedores é realmente importante. Muitos trabalham em ThinkPads de 5 a 10 anos que já precisam ser trocados
https://www.openbsd.org/want.html
A OpenBSD Foundation ainda está cerca de 50% abaixo da meta de arrecadação para 2026
https://www.openbsdfoundation.org/campaign2026.html
https://brynet.ca/wallofpizza.html
No trecho “Amazon Web Services está junto”, toda a credibilidade deste texto desaparece
Isso soa como uma tentativa de centralização e controle. Seja lá quem for a Akrites, isso só vai dar às grandes empresas de tecnologia, incluindo o Google, poder para controlar o open source
Obrigado, mas passo. Lembro que o Google quer bloquear neste setembro, no Android, instalações de terceiros via
.apkA propósito, a maioria das pessoas inteligentes que conheço acha que a IA open source torna a Anthropic e a OpenAI financeiramente inviáveis. Muitas das empresas listadas aqui estão fortemente envolvidas com essas duas, e têm grande incentivo para abalar a IA open source antes que os clientes sintam o choque de preços. Eu estava esperando para ver qual seria o próximo movimento delas, e isso pode ser parte disso
A informação mais importante é a parte de que os participantes vão contribuir com recursos de engenharia
Resta ver se isso vai acontecer como planejado. Fora isso, não me impressionam muito as alegações deste projeto. A estrutura favorece centralização e redes centradas em empresas, exatamente o oposto da direção que a ética hacker tem incentivado por boas razões
Também pode virar mais uma fonte de pressão. Talvez consiga filtrar bem vulnerabilidades reais, mas o resultado ainda acabará sendo empurrado para mantenedores como alta prioridade. Muitos mantenedores já estão esgotados mesmo sem ruído de IA, e mesmo quando uma correção é fornecida, ainda precisa de revisão
No melhor cenário, isso pode reduzir o ruído, mas o trabalho continua existindo. O setor deveria financiar de forma ampla para que os projetos open source tenham autonomia para lidar com isso por conta própria. Isso provavelmente também é o melhor para a qualidade. Se for preciso filtrar ruído de IA, dá para adicionar essa função, mas não deveria ser por meio de uma estrutura secreta e opaca que controla tudo
Estou esperando o dia em que verei manchetes como “Todos nós dependemos do open source. Vamos financiá-lo juntos”
Gostei do nome “Akrites”
Talvez seja menos impactante para quem não é grego, mas para gregos ele transmite uma imagem bem forte
akron significa borda ou fronteira, então seria algo como “homens da fronteira” ou “pessoas da fronteira”. O ponto principal aqui é que não dá para projetar conflitos ou preconceitos modernos diretamente sobre uma história de mil anos atrás. No contexto histórico, era parecido com muitas outras fronteiras entre civilizações diferentes, e o importante é que era uma organização coletiva reunida para defender sua própria terra
[1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech
Acho que postar algo assim no Hacker News não faz muito sentido. A maioria aqui comprou a onda da IA a fundo e não se importa muito
Além disso, muitas das empresas na lista são as principais suspeitas de terem levado o open source ao estado em que está hoje
Mas concordo que muitas das empresas da lista são as principais suspeitas pelo estado do open source. Isso parece uma peça de relações públicas para lavar a imagem dessas empresas, e é difícil acreditar que elas realmente se importem com a ética do open source