Bus Factor = 1: 22 Bibliotecas Críticas para a Indústria Sustentadas por uma Única Pessoa

Em algum lugar, neste exato momento, um programador está acordado, corrigindo um bug em uma biblioteca da qual metade da internet depende. Ele faz isso de graça. Ninguém o conhece. Se ele desistir, ninguém virá em seu lugar.

Em abril de 2024, o pesquisador de segurança Andres Freund descobriu um backdoor no xz utils, uma ferramenta de compressão embutida na maioria das distribuições Linux. O ataque foi quase perfeito: dois anos de engenharia social, um mantenedor esgotado e código malicioso nos scripts de build. O mantenedor do xz, Lasse Collin, recebeu ajuda com o código, suporte em listas de e-mail e pressão de um "comunidade" de bots exigindo sua inclusão no projeto por parte do agressor (conhecido como Jia Tan) ao longo de dois anos. Em junho de 2022, Collin escreveu em uma lista de e-mail que sua "capacidade de manter o xz é limitada devido a problemas de saúde mental". Ele estava sozinho. Ele estava cansado. Ele cedeu. Esta é uma história sobre uma vulnerabilidade estrutural que todos nós criamos juntos e continuamos a ignorar.

Um Pouco de Matemática

O termo "bus factor" descreve o número mínimo de pessoas que precisam ser "atingidas por um ônibus" para que um projeto pare. Um bus factor = 1 significa que uma única pessoa é o único ponto de falha. Um estudo da Linux Foundation e da Harvard Business School analisou mais de 12 milhões de observações em ambientes de produção de mais de 10.000 empresas. A principal conclusão é banal: a maioria das bibliotecas de código aberto mais utilizadas é desenvolvida por um número insignificante de contribuidores. Percorri a API do GitHub para cem dependências críticas em npm, PyPI e pacotes de sistema Linux e compilei uma lista de projetos onde a atividade de commit nos últimos 12 meses pertenceu a 80% ou mais a uma única pessoa – com dezenas de milhões de downloads por semana. A lista acabou sendo inesperadamente longa. E inesperadamente familiar.

23 Bibliotecas nos Ombros de Uma Pessoa

Esta não é uma lista acadêmica. São dependências reais que estão atualmente em seus node_modules, requirements.txt e /usr/lib de sistemas de produção.

Nível de Sistema

1. xz utils – Lasse Collin, Finlândia. Utilitário de compressão instalado na maioria das distribuições Linux. Antes do backdoor de 2024, era um projeto totalmente solo. A história de Jia Tan mostrou: uma pessoa cansada é uma CVE não resolvida esperando a hora certa.
2. zlib – Jean-Loup Gailly e Mark Adler. Biblioteca de compressão presente literalmente em todo lugar: Python, Java, iOS, Android, navegadores, motores de jogos. Dois mantenedores com mais de 60 anos. O último lançamento significativo foi em 2022. O que virá a seguir é desconhecido.
3. libjpeg-turbo – Darrell Komander. Implementação JPEG de alta performance usada por Chrome, Firefox, LibreOffice, ffmpeg, VirtualBox. O desenvolvedor ativo é, na verdade, um só. Sem ele, o caos em metade dos pipelines de processamento de imagem.
4. OpenSSL (historicamente) – Várias pessoas com uma escassez catastrófica de recursos. Antes do Heartbleed em 2014, o único desenvolvedor em tempo integral do OpenSSL era Steven Henson – um homem com doutorado em matemática, morando em Staffordshire. Foi ele quem aprovou mais da metade de todas as alterações em 450.000 linhas de código. Steve Marquess, presidente da OpenSSL Software Foundation, cuidava do lado financeiro e organizacional, mas não do desenvolvimento. A biblioteca que protegia dois terços do tráfego HTTPS do planeta existia com US$ 2.000 em doações anuais. Após o Heartbleed, o financiamento aumentou, mas a própria história mostrou o quão profundamente conseguimos ignorar o óbvio.

JavaScript / Node.js

1. core-js – Denis Pushkarev (zloirock). Polyfill para a biblioteca padrão do JavaScript. Baixado mais de 250 milhões de vezes por semana. Usado em 75-80% dos 100 principais sites do mundo – incluindo Amazon, Netflix, Airbnb. Em 9 anos – 9 bilhões de downloads. O mantenedor é uma única pessoa. Em 2023, Denis publicou um post com o título "Estou fodidamente cansado". Sua renda com o suporte da biblioteca caiu de US$ 2.500 para US$ 400 por mês. A Tidelift parou de pagar devido a sanções contra a Rússia – o dinheiro simplesmente foi congelado. O OpenCollective reduziu os pagamentos. Naquela época, ele teve um filho. "Procurei outros mantenedores de várias maneiras por muito tempo, mas todas as tentativas falharam", escreveu ele. "O código aberto gratuito está fundamentalmente quebrado." Em resposta, milhares de desenvolvedores o atacaram com insultos, exigindo que o repositório fosse entregue à "comunidade" – que, é claro, nenhum deles representava.
2. Express.js – Doug Wilson, 17 milhões de downloads por semana. A base de inúmeras APIs Node.js em todo o mundo. Um mantenedor ativo. Periodicamente, surgem issues no GitHub com perguntas alarmantes: "Doug ainda está vivo?"
3. colors.js + faker.js – Marak Squires. Uma história que a indústria preferiu esquecer rapidamente. Marak mantinha colors (27 milhões de downloads por semana, 19.000 pacotes dependentes) e faker (3 milhões) sozinho. Em novembro de 2020, escreveu: "Chega de trabalho gratuito. Paguem ou façam fork". Ninguém o ouviu. Em janeiro de 2022, ele quebrou intencionalmente ambas as bibliotecas – adicionando um loop infinito em colors e removendo todo o código de faker. Metade do ecossistema npm parou da noite para o dia. Corporações que lucravam bilhões com seu código correram para encontrar forks. Pagar ao autor – não, fazer fork de seu trabalho – sim.
4. event-stream – Dominic Tarr. Um clássico do gênero. Em 2018, Dominic simplesmente transferiu os direitos do pacote (2 milhões de downloads por semana) para um estranho – porque estava cansado. O novo "mantenedor" adicionou código malicioso visando roubar criptomoedas de usuários do Copay. A vulnerabilidade permaneceu por vários meses. Dominic escreveu depois nos issues: "Eu não achava que alguém usava esse pacote seriamente".
5. Sindre Sorhus – uma categoria separada. O desenvolvedor norueguês mantém mais de 1000 pacotes npm. Incluindo got, ky, execa, ora, chalk, meow, p-limit, is-* e centenas de outros. Alguns deles são baixados centenas de milhões de vezes por semana. Sindre diz que trabalha sozinho. Se algo acontecer com ele – uma parte significativa da camada de ferramentas do JavaScript desmorona.

Python / PyPI

1. requests – Kenneth Reitz, depois Nathan Reconf. "HTTP for Humans" – a biblioteca Python mais popular fora da biblioteca padrão. Kenneth a criou, a manteve por muito tempo e depois escreveu publicamente que estava esgotado e transferia a gestão. Agora, uma pequena equipe trabalha nela, mas a história da transferência foi dolorosa.
2. Pillow – Alexander Krawetz e mais 2-3 pessoas. A principal biblioteca para manipulação de imagens em Python. Milhares de dependências. Vários contribuidores ativos, dos quais apenas uma ou duas pessoas realmente "seguram" o projeto.
3. urllib3 – Seth Larson. Nível inferior de HTTP para requests, pip e inúmeras ferramentas. Um mantenedor principal por muitos anos. Seth escreveu publicamente sobre burnout e a dificuldade de manutenção.
4. cryptography (PyCA) – formalmente um fundo, na prática algumas pessoas. A principal biblioteca criptográfica do ecossistema Python. Usada em TLS, SSH, criptografia de dados de milhões de aplicativos. Apesar da estrutura organizacional formal – mantenedores ativos contados nos dedos de uma mão.

Nível de Sistema / Nível C

1. curl / libcurl – Daniel Stenberg, 6 bilhões de instalações. Pré-instalado em Windows, macOS, todas as distribuições Linux. Embutido em smartphones, TVs, carros, impressoras, consoles de jogos. Desde 1998 – mais de 15.000 horas de trabalho de Daniel. Daniel é uma exceção à regra: ele trabalha em tempo integral para a wolfSSL, o projeto tem vários mantenedores confiáveis e boa documentação. Mas ele mesmo diz: "o maior desafio que o código aberto enfrenta é a manutenção". E ele sabe do que está falando – ele escreveu o livro "Uncurled" exatamente sobre isso.
2. SQLite – D. Richard Hipp. O banco de dados mais difundido do mundo. Presente em todos os iPhones, todos os dispositivos Android, Firefox, Chrome, Skype, Adobe Lightroom. Hipp intencionalmente fez do SQLite um projeto solo – segundo ele, isso simplifica a gestão. O código não aceita commits externos.
3. Netwide Assembler (NASM) – várias pessoas, historicamente um. O assembler usado no kernel Linux, compiladores, sistemas de alta performance. Periodicamente entra em longos períodos sem atualizações.
4. libpng – historicamente uma equipe mínima. Biblioteca PNG que está dentro de cada navegador. Por muitos anos, foi mantida por vários entusiastas sem nenhum financiamento.

Ruby / Go / Outros

1. Devise (Ruby) – José Valim + 2-3 mantenedores. Sistema de autenticação embutido em dezenas de milhares de aplicações Rails. Por anos, foi mantido por um ou dois indivíduos.
2. Nokogiri (Ruby) – Mike Dal, Aaron Patterson. Parser HTML/XML do qual uma parte significativa do ecossistema Ruby depende. Ativamente mantido, mas historicamente com uma equipe mínima.
3. gopkg.in/yaml.v2 – Gustavo Niemeyer. Parser YAML para Go usado em Kubernetes, Docker, milhares de microsserviços. Um autor que é difícil de contatar.
4. log4net (.NET) – versão .NET do logger Apache Commons, usada por uma grande parte das aplicações corporativas .NET. Commits chegam raramente, atividade mínima.
5. libyaml (C) – Kirill Simonov. Nível inferior para parsing YAML em várias linguagens, incluindo Python (PyYAML), Ruby, Perl. Um autor. O último commit significativo data de vários anos atrás.

Por Que Isso Acontece? A Economia Está Quebrada.

O código aberto funciona com matéria escura da economia: trabalho voluntário que é invisível até desaparecer. A pesquisa FOSS Contributor Survey (Linux Foundation, 2020) registrou: cerca de metade dos mantenedores não recebe um centavo por seu trabalho. Três quartos trabalham em empregos em tempo integral paralelamente. Os principais motivos não são dinheiro, mas "fazer algo importante" e "aprender coisas novas".

Isso é maravilhoso. Isso também é terrível. Porque "fazer algo importante" não paga o aluguel. Não financia licença maternidade/paternidade. Não protege contra doenças, prisão, burnout, morte. E as corporações que lucram bilhões com o trabalho alheio, em sua maioria, não sentem nenhuma obrigação de corrigir isso.

Aqui estão alguns números:

• US$ 2.000 por ano – orçamento anual do OpenSSL antes do Heartbleed. A biblioteca protegia dois terços do tráfego HTTPS mundial.
• US$ 0 – quanto Dominic Tarr recebeu por event-stream. Até que ele se cansou e entregou o projeto a um estranho.

Anatomia de um Desastre: Como o xz Quase Quebrou o Linux

A história do xz é digna de um artigo separado, mas não pode ser ignorada aqui – precisamente porque mostra como um bus factor = 1 se torna um vetor de ataque.

• Outubro de 2021. Surge a conta JiaT75 (Jia Tan) no GitHub. Primeiro commit – uma alteração inofensiva no libarchive. O início de um longo caminho de confiança.
• Fevereiro de 2022. Primeiro commit real no repositório xz – validação de parâmetros do codificador LZMA. Legítimo, útil.
• Abril-Junho de 2022. Contas Jigar Kumar, krygorin4545, Dennis Ens aparecem na lista de e-mail. Eles pressionam Lasse Collin: "Por que tão lento? O projeto precisa de um novo mantenedor. Adicione Jia Tan". As contas foram criadas recentemente, o histórico é quase vazio. Mais tarde, descobrirá-se – foi uma campanha coordenada.
• Junho de 2022. Lasse Collin escreve para a lista de e-mail: sua "capacidade de manter o xz é limitada devido a problemas de saúde mental". Ele está sozinho. Ele não está bem. Ele é grato pela ajuda.
• Novembro de 2022. O e-mail de contato do projeto é alterado para um alias – Jia Tan agora tem acesso.
• 2023. Jia Tan lança o primeiro release do xz. Assume o controle do projeto de fato. Faz alterações no sistema de build – "otimização".
• Fevereiro – Março de 2024. Código malicioso é introduzido no repositório – primeiro na forma de arquivos "de teste" binários que não entram diretamente no histórico do git. Tecnicamente sofisticado. O release comprometido sai como xz utils 5.6.0, depois 5.6.1.
• 29 de Março de 2024. O engenheiro da Microsoft, Andres Freund, nota uma anomalia: o sshd em sua máquina Debian está 500 ms mais lento do que o esperado. Ele começa a investigar. O que ele encontra – o faz escrever um e-mail para a lista de e-mail às 8 da manhã de sexta-feira com o assunto "IMPORTANTE".

O backdoor poderia permitir que o agressor executasse código remotamente em qualquer máquina com sshd vulnerável. Faltavam semanas para a ampla disseminação: Debian unstable e Fedora já haviam incluído as versões comprometidas. Para os releases estáveis, faltava pouco.

Foi encontrado por acaso. Uma pessoa. Por causa de 500 milissegundos. Se Andres Freund não fosse paranoico – você saberia disso de uma maneira completamente diferente.

Três Cenários do Que Acontece Quando um Mantenedor Desiste.

• Cenário 1: Morte Silenciosa. O projeto para de ser atualizado. Bugs se acumulam. Primeiro surgem forks, depois forks de forks. Em alguns anos, metade da internet executa uma biblioteca com CVEs de 2019 não resolvidas, que ninguém suporta oficialmente, mas todos usam.
• Cenário 2: Transferência para um Estranho. event-stream. O mantenedor se esgota e entrega os direitos ao primeiro que pedir. O novo proprietário se revela não ser quem dizia ser.
• Cenário 3: Sabotagem Consciente. colors.js, faker.js, node-ipc. O mantenedor se cansa, fica com raiva – e usa a única alavancagem que tem. Tudo isso poderia ter sido evitado: simplesmente pagando à pessoa.

"Mas é código aberto – quem quiser, faz fork."

O contra-argumento padrão. Soa razoável e é completamente sem sentido na prática. Fazer fork de uma biblioteca crítica não é "apenas copiar o repositório". Significa:

• Assumir o suporte e a compreensão de toda a base de código (às vezes – centenas de milhares de linhas ao longo de 20 anos)
• Garantir a compatibilidade com tudo o que depende da sua versão
• Corrigir as CVEs que surgirão
• Moderar issues e PRs de centenas de usuários irritados
• Fazer isso de graça, porque "você mesmo se ofereceu".

É disso que o mantenedor anterior já fugiu. A fila de voluntários não é particularmente longa.

O Que Está Acontecendo na Indústria

Após o Heartbleed (2014), surgiu o Core Infrastructure Initiative. Após o Log4Shell (2021) – o projeto Alpha-Omega da OpenSSF com um orçamento de US$ 10 milhões. Após o xz (2024) – mais uma rodada de conferências e grupos de trabalho alarmantes. O padrão é familiar: crise → interesse em pânico → dinheiro → três anos de atenção relativa → esquecimento.

Existem bons exemplos. A Rust Foundation financia os desenvolvedores da linguagem. A PHP Foundation paga oito desenvolvedores em regime de meio período. A Django Software Foundation apoia vários desenvolvedores fellows. O OpenSSL, após o Heartbleed, finalmente recebeu financiamento contínuo.

Mas são exceções. Para a maioria dos projetos críticos – nada mudou.

Em Vez de Epílogo

Em 2020, surgiu a famosa charge xkcd #2347 com uma "torre de componentes aleatórios" que sustenta "toda a infraestrutura digital moderna" – e uma única pessoa em algum lugar de Nebraska que a mantém. Quase 6 anos se passaram. O meme se tornou mais relevante, não menos.

Construímos uma economia global de trilhões de dólares sobre os alicerces do trabalho voluntário de pessoas que a maioria de nós nunca viu e nunca agradeceu. Normalizamos isso a ponto de nos surpreendermos quando algo dá errado.

O xz foi quase uma catástrofe. Se você conhece um projeto com bus factor = 1 que deveria ser adicionado a esta lista – escreva nos comentários. Se você mesmo é um mantenedor assim – ainda mais.

Os dados de atividade de commit foram coletados através da API do GitHub (endpoint /repos/{owner}/{repo}/stats/contributors). A lista não pretende ser exaustiva.