O seu scanner de dependências não vê o risco que torna o código órfão
O verdadeiro risco da cadeia de fornecimento open source não está na licença nem na qualidade do código. Está no dia em que um mantenedor é afastado por motivos que nada têm a ver com o código, e a empresa herda o órfão.
O seu scanner de dependências é bom a detetar aquilo que consegue ver: lê a versão, verifica a licença, cruza vulnerabilidades conhecidas com uma base de dados de CVEs e produz um relatório organizado. Esse relatório tem um ponto cego do tamanho de uma pessoa.
O componente na base da sua stack é mantido por alguém. Por vezes por uma equipa, mas muitas vezes por uma única pessoa que o faz nas horas vagas. Nada no inventário de materiais de software (SBOM) da empresa regista quem é essa pessoa, a que jurisdição responde, ou o que aconteceria ao código se fosse afastada do projeto entre um lançamento e o seguinte.
Esse último cenário não é hipotético. Em outubro de 2024, o kernel Linux removeu cerca de onze mantenedores ligados a empresas russas, eliminando as suas entradas do ficheiro MAINTAINERS do kernel. O commit que fez a alteração deu apenas uma justificação lacónica, dizendo que as entradas foram retiradas «devido a vários requisitos de conformidade», e Linus Torvalds apoiou publicamente a decisão, apontando para a legislação de sanções por trás dela e não para qualquer argumento sobre o código. O gatilho não foi a qualidade do código, um incidente de segurança ou um diferendo de governação. Foi uma obrigação legal que o projeto não podia recusar, e que se aplicaria da mesma forma a qualquer projeto europeu sujeito aos regimes de sanções da UE à Rússia. O mecanismo importa mais do que o título: a conformidade regulatória foi além do código e removeu as pessoas que o mantinham.
A imagem espelhada desse risco é o backdoor da xz-utils, descoberto em março de 2024. Nesse caso, um mantenedor que tinha passado cerca de dois anos a ganhar a confiança de um projeto voluntário esgotado (CVE-2024-3094) usou esse lugar para introduzir um backdoor oculto numa biblioteca de compressão distribuída pela maioria das distribuições Linux. Um caso remove um mantenedor de confiança por via legal; o outro mostra quanto vale o lugar de um mantenedor para quem o quer explorar. Ambos apontam para o mesmo facto que o scanner ignora: o poder está em quem tem direitos de commit, não na sintaxe que essa pessoa submete.
O que acontece, na prática, quando um mantenedor é removido?
Siga a sequência. Um mantenedor é responsável por um módulo: revê patches, faz a triagem de bugs e valida lançamentos para essa fatia da árvore de código. Remova essa pessoa e os patches continuam a chegar, mas já ninguém tem autoridade ou contexto para os integrar. O módulo não avaria no dia da remoção. Degrada-se lentamente, uma correção de segurança por rever de cada vez.
O projeto não suporta esse custo. A empresa suporta. O projeto é um esforço voluntário sem contrato, sem SLA e sem qualquer obrigação para consigo. Quando um componente fica sem responsável, a empresa que o utiliza herda um passivo sem patches, sem triagem, que não escolheu e que não pode devolver com facilidade. A neutralidade da governação do projeto é irrelevante quando a remoção resultou de uma exigência legal e não de uma escolha de política interna.
Por que motivo o scanner não deteta este risco?
As regras de participação num projeto fundacional são definidas pela sua liderança, ao critério desta. Isto não é uma crítica: todo o projeto precisa de alguém que decida quem faz commits. Mas significa que a exposição da empresa a essa dependência inclui, silenciosamente, decisões sobre as quais não tem qualquer palavra a dizer nem visibilidade: quem é admitido, quem é removido, e com que fundamento. Uma licença não capta isto. Um SBOM não capta isto. Um scanner, muito menos.
Retire a camada de discurso e sobram duas exposições familiares: risco de pessoa-chave e risco de discricionariedade de governação, escondidos debaixo de infraestrutura que a empresa trata como um ativo fixo. A área financeira já tem vocabulário para isto quando surge numa relação com um fornecedor. Raramente esse vocabulário é aplicado à biblioteca open source três camadas mais abaixo, porque essa biblioteca parece física, uma lei da natureza, e não uma relação com pessoas a quem se pode dizer para sair.
Duas pressões estão a convergir. Os regimes de sanções e de controlo de exportação alcançam hoje diretamente as listas de mantenedores, e o seu alcance continua a alargar-se, com relevância direta para empresas europeias sujeitas aos mesmos regimes. Ao mesmo tempo, as dependências mais críticas são muitas vezes as que têm menos gente a mantê-las, sustentadas por um punhado de voluntários, como ficou claro tanto no quase-desastre da xz-utils como na correria do Log4Shell, em dezembro de 2021. Menos pessoas de confiança, mais probabilidade de uma delas ser afastada por uma regra que o projeto não pode contestar, e uma janela mais larga em que código sem manutenção fica por corrigir. As equipas que constroem sobre agentes automatizados que instalam e atualizam dependências a alta velocidade devem tratar isto como uma restrição de conceção, não como um caso extremo. É um dos problemas mais delicados na construção de sistemas agênticos seguros.
A resposta correta não é entrar em pânico por causa de um projeto específico, nem fingir que é possível alojar internamente todo o grafo de dependências da empresa. É acrescentar uma pergunta à due diligence técnica que a maioria das equipas nunca faz: que evento legal ou discricionário poderia remover os mantenedores deste componente de um dia para o outro, e qual é o plano para o código órfão na manhã seguinte?
Essa pergunta separa rapidamente as dependências. A maioria está bem: base alargada de mantenedores, várias organizações envolvidas, um bus factor saudável. Algumas não estão: um único mantenedor, uma única jurisdição, um único ponto de falha que nenhuma ferramenta automática assinala porque a falha vive nas pessoas e na lei, não na sintaxe. Essas poucas merecem um plano de contingência, seja financiar um segundo mantenedor, isolar internamente uma versão validada, seja construir a capacidade interna para corrigir o próprio código, se for preciso.
A stack da empresa não é apenas código importado. É um conjunto de relações com pessoas que podem ser removidas por forças que nada têm a ver consigo. Audite as pessoas, não apenas os pacotes.
Perguntas frequentes
Um SBOM protege contra o risco de mantenedores ou de sanções?
Não. Um inventário de materiais de software (SBOM) regista que componentes e versões a empresa utiliza, e que licenças e vulnerabilidades conhecidas têm. Não diz nada sobre quem mantém cada componente, quantas pessoas podem rever uma correção de segurança, ou se um evento legal ou de governação poderia remover essas pessoas. É exatamente nessa lacuna que vive o risco de código órfão, pelo que um SBOM é necessário mas não suficiente.
O que é o risco de pessoa-chave numa dependência open source?
É a exposição criada quando um componente depende de uma pessoa, ou de muito poucas, para rever e integrar alterações. Se essa pessoa sair, for removida por motivos de conformidade, ou simplesmente deixar de contribuir, os patches deixam de ser integrados mesmo que continuem a ser submetidos. O código degrada-se silenciosamente, e a empresa que o utiliza herda o resultado sem manutenção.
Como se avalia o risco de governação numa dependência open source?
Olhe para além da licença e do código, para as pessoas e as regras. Verifique o número de mantenedores ativos e o bus factor, se os contribuidores estão distribuídos por várias organizações e jurisdições, e quem tem o critério para admitir ou remover committers. Depois pergunte que evento legal ou de liderança, isolado, poderia remover a manutenção de um dia para o outro, e registe o plano de contingência para os componentes cuja resposta seja desconfortável.
Relacionado
- No Ubuntu 26.04 LTS, o Coreutils Que Sustenta as Suas Compilações Já Não É GNU
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Os Processos por Segredos Comerciais Ganham-se Anos Antes de Alguém se Demitir. Pergunte à Faccenda Chicken.
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.