Automatizando SBOM em Projetos Legacy Complexos: A Experiência do LibreOffice e Collabora Online
A geração de Software Bill of Materials (SBOM) em grandes projetos de código aberto como LibreOffice e Collabora Online apresenta desafios únicos. Este artigo detalha a jornada da Collabora para automatizar esse processo, abordando desde a coleta manual de licenças até a busca por soluções para dependências C/C++ complexas, em conformidade com regulamentações como o Cyber Resilience Act (CRA).
MundiX News·11 de junho de 2026·8 min de leitura·👁 8 views
A conferência FOSDEM, um evento anual de destaque para desenvolvedores de software livre e de código aberto, tem dedicado um espaço crescente à discussão sobre SBOMs e cadeias de suprimentos de software desde 2021, com um devroom específico para o tema. Este artigo é uma adaptação de uma apresentação de Thorsten Behrens na FOSDEM 2026, focando na experiência da Collabora Online na automação da geração de SBOM para um projeto legado de grande porte.
O Cyber Resilience Act (CRA) da União Europeia, juntamente com regulamentações nacionais como o GOST R 56939-2024 na Rússia, impulsionam a necessidade de transparência e rastreabilidade no software. O SBOM, ou Lista de Materiais de Software, deixa de ser um mero documento para se tornar parte integrante do processo de desenvolvimento seguro, especialmente para produtos que exigem altos níveis de confiança ou certificação. A Collabora Online, um pacote de escritório online de código aberto baseado no núcleo do LibreOffice, representa um caso de estudo complexo para a implementação de SBOMs automatizados.
A meta da Collabora era alcançar total transparência e rastreabilidade de todos os artefatos do produto para atender aos requisitos do CRA. Embora já tivessem alguma experiência com imagens de contêiner, o Collabora Online apresentou um desafio particular devido à sua arquitetura heterogênea: um núcleo em C++ massivo (LibreOffice Core), um frontend em JavaScript/TypeScript, mais de 100 bibliotecas nativas em C/C++ e dependências "periféricas" como fontes e dicionários, para as quais soluções automatizadas são escassas. Adicionalmente, os padrões do CRA ainda estão em evolução, tornando o processo semelhante a "consertar um carro em movimento".
Os Primeiros Passos: Trabalho Manual e Escolha de Ferramentas
Uma auditoria inicial revelou a ausência completa de SBOMs. Após pesquisa e consulta a especialistas, o formato SPDX foi escolhido como ponto de partida. A primeira tarefa foi a coleta de informações de licença. Para o Collabora Online, isso foi feito manualmente para as dependências diretas, incluindo uma lista de dependências JavaScript (felizmente, sem a complexidade típica de um ecossistema npm com milhares de pacotes aninhados) e fontes encontradas no console do administrador. As dependências C++ de alto nível, incluindo dezenas de bibliotecas e o próprio LibreOffice Core, também foram adicionadas manualmente. Para automatizar a coleta de versões, a equipe integrou a informação do sistema de build.
Fontes, Dicionários e Outros "Itens Simples"
Mesmo elementos aparentemente simples como fontes exigem atenção. Uma fonte possui uma licença e, portanto, deve constar no SBOM. Além disso, fontes são artefatos binários e seus mecanismos internos de hinting podem conter código executável em uma máquina virtual, representando uma potencial superfície de ataque. É crucial conhecer a versão da fonte, seu hash e verificar a existência de CVEs (Common Vulnerabilities and Exposures). Dicionários, embora mais simples em termos de licenciamento, também precisam ser listados. No total, além do código, a equipe precisou considerar cerca de 50 dicionários e centenas de fontes. A esperança de encontrar uma solução automatizada para o rastreamento de fontes em SBOMs não se concretizou, com relatórios de bugs relevantes ainda abertos.
LibreOffice Core: O Gigante Complexo
Em janeiro de 2025, o sistema gerava uma lista de licenças para dependências diretas do Collabora Online, com 26 relacionamentos e versões obtidas do sistema de build. O LibreOffice Core, no entanto, é uma parte colossal, complexa e problemática do projeto. Com 10 milhões de linhas de código, mais de 100 bibliotecas C/C++ de terceiros e uma vasta quantidade de fontes, a documentação manual de todas as suas dependências internas seria um esforço titânico e rapidamente obsoleto. A automação era uma necessidade absoluta.
Buscando Automação para C/C++
A falta de um padrão unificado de build e gerenciador de pacotes para C/C++, ao contrário de linguagens como Go, Java ou Python, representa um obstáculo. Cada biblioteca pode empregar seu próprio sistema legado. No entanto, o sistema de build do próprio LibreOffice, originário do OpenOffice de 2002, possui conhecimento detalhado sobre o que está sendo compilado. Ele é dinâmico, permite a ativação/desativação de funcionalidades e é responsável pelo empacotamento final em formatos como DEB, RPM ou MSI. A equipe desenvolveu um patch para extrair do sistema de build uma lista linear de todas as dependências que efetivamente entram no produto, permitindo a geração de um SBOM mínimo com componentes de terceiros e suas licenças. Gerenciadores de dependência como Conan e vcpkg existem para C/C++, mas muitos projetos legados relutam em adotá-los devido a sistemas de build estabelecidos e processos de desenvolvimento consolidados.
De Licenças à Segurança: Requisitos do BSI
O CRA exige mais do que apenas listas de licenças; ele demanda a capacidade de avaliar vulnerabilidades. As diretrizes do BSI (Agência Federal Alemã de Segurança da Informação) estabelecem um alto padrão, mesmo que não sejam obrigatórias. Seguindo-as, seria necessário determinar a origem de cada arquivo no disco (incluindo scripts Python, macros e fontes), identificando nome do componente, checksum, identificador CPE (para vincular a CVEs, algo frequentemente ausente para bibliotecas C++ antigas), licença declarada e real, e informações sobre bibliotecas de sistema vinculadas. Essa tarefa é complexa e dependente da plataforma, com SBOMs para Windows e Linux diferindo significativamente. A criação manual de strings CPE pode não garantir a correspondência com bancos de dados públicos de vulnerabilidades, levando a falsos positivos ou negativos.
Próximos Passos
O plano da Collabora é extrair o máximo de informação possível do sistema de build. Para obter uma visão completa, incluindo ligações dinâmicas e dados de bibliotecas de terceiros dentro do Core, será necessário aprofundar a análise dos sistemas de build. A equipe reconhece que não pode simplesmente exigir que os mantenedores de bibliotecas criem SBOMs, pois muitas são mantidas por indivíduos com recursos limitados. A geração de SBOMs deve ser integrada ao processo de build, pois o conteúdo dos componentes de software depende diretamente dos parâmetros de configuração atuais, e a manutenção manual pós-build é excessivamente trabalhosa. O próximo e mais desafiador estágio é detalhar a vasta base de código do LibreOffice Core para atender aos requisitos de segurança do CRA.
A conferência FOSDEM, um evento anual de destaque para desenvolvedores de software livre e de código aberto, tem dedicado um espaço crescente à discussão sobre SBOMs e cadeias de suprimentos de software desde 2021, com um devroom específico para o tema. Este artigo é uma adaptação de uma apresentação de Thorsten Behrens na FOSDEM 2026, focando na experiência da Collabora Online na automação da geração de SBOM para um projeto legado de grande porte.
O Cyber Resilience Act (CRA) da União Europeia, juntamente com regulamentações nacionais como o GOST R 56939-2024 na Rússia, impulsionam a necessidade de transparência e rastreabilidade no software. O SBOM, ou Lista de Materiais de Software, deixa de ser um mero documento para se tornar parte integrante do processo de desenvolvimento seguro, especialmente para produtos que exigem altos níveis de confiança ou certificação. A Collabora Online, um pacote de escritório online de código aberto baseado no núcleo do LibreOffice, representa um caso de estudo complexo para a implementação de SBOMs automatizados.
A meta da Collabora era alcançar total transparência e rastreabilidade de todos os artefatos do produto para atender aos requisitos do CRA. Embora já tivessem alguma experiência com imagens de contêiner, o Collabora Online apresentou um desafio particular devido à sua arquitetura heterogênea: um núcleo em C++ massivo (LibreOffice Core), um frontend em JavaScript/TypeScript, mais de 100 bibliotecas nativas em C/C++ e dependências "periféricas" como fontes e dicionários, para as quais soluções automatizadas são escassas. Adicionalmente, os padrões do CRA ainda estão em evolução, tornando o processo semelhante a "consertar um carro em movimento".
Os Primeiros Passos: Trabalho Manual e Escolha de Ferramentas
Uma auditoria inicial revelou a ausência completa de SBOMs. Após pesquisa e consulta a especialistas, o formato SPDX foi escolhido como ponto de partida. A primeira tarefa foi a coleta de informações de licença. Para o Collabora Online, isso foi feito manualmente para as dependências diretas, incluindo uma lista de dependências JavaScript (felizmente, sem a complexidade típica de um ecossistema npm com milhares de pacotes aninhados) e fontes encontradas no console do administrador. As dependências C++ de alto nível, incluindo dezenas de bibliotecas e o próprio LibreOffice Core, também foram adicionadas manualmente. Para automatizar a coleta de versões, a equipe integrou a informação do sistema de build.
Fontes, Dicionários e Outros "Itens Simples"
Mesmo elementos aparentemente simples como fontes exigem atenção. Uma fonte possui uma licença e, portanto, deve constar no SBOM. Além disso, fontes são artefatos binários e seus mecanismos internos de hinting podem conter código executável em uma máquina virtual, representando uma potencial superfície de ataque. É crucial conhecer a versão da fonte, seu hash e verificar a existência de CVEs (Common Vulnerabilities and Exposures). Dicionários, embora mais simples em termos de licenciamento, também precisam ser listados. No total, além do código, a equipe precisou considerar cerca de 50 dicionários e centenas de fontes. A esperança de encontrar uma solução automatizada para o rastreamento de fontes em SBOMs não se concretizou, com relatórios de bugs relevantes ainda abertos.
LibreOffice Core: O Gigante Complexo
Em janeiro de 2025, o sistema gerava uma lista de licenças para dependências diretas do Collabora Online, com 26 relacionamentos e versões obtidas do sistema de build. O LibreOffice Core, no entanto, é uma parte colossal, complexa e problemática do projeto. Com 10 milhões de linhas de código, mais de 100 bibliotecas C/C++ de terceiros e uma vasta quantidade de fontes, a documentação manual de todas as suas dependências internas seria um esforço titânico e rapidamente obsoleto. A automação era uma necessidade absoluta.
Buscando Automação para C/C++
A falta de um padrão unificado de build e gerenciador de pacotes para C/C++, ao contrário de linguagens como Go, Java ou Python, representa um obstáculo. Cada biblioteca pode empregar seu próprio sistema legado. No entanto, o sistema de build do próprio LibreOffice, originário do OpenOffice de 2002, possui conhecimento detalhado sobre o que está sendo compilado. Ele é dinâmico, permite a ativação/desativação de funcionalidades e é responsável pelo empacotamento final em formatos como DEB, RPM ou MSI. A equipe desenvolveu um patch para extrair do sistema de build uma lista linear de todas as dependências que efetivamente entram no produto, permitindo a geração de um SBOM mínimo com componentes de terceiros e suas licenças. Gerenciadores de dependência como Conan e vcpkg existem para C/C++, mas muitos projetos legados relutam em adotá-los devido a sistemas de build estabelecidos e processos de desenvolvimento consolidados.
De Licenças à Segurança: Requisitos do BSI
O CRA exige mais do que apenas listas de licenças; ele demanda a capacidade de avaliar vulnerabilidades. As diretrizes do BSI (Agência Federal Alemã de Segurança da Informação) estabelecem um alto padrão, mesmo que não sejam obrigatórias. Seguindo-as, seria necessário determinar a origem de cada arquivo no disco (incluindo scripts Python, macros e fontes), identificando nome do componente, checksum, identificador CPE (para vincular a CVEs, algo frequentemente ausente para bibliotecas C++ antigas), licença declarada e real, e informações sobre bibliotecas de sistema vinculadas. Essa tarefa é complexa e dependente da plataforma, com SBOMs para Windows e Linux diferindo significativamente. A criação manual de strings CPE pode não garantir a correspondência com bancos de dados públicos de vulnerabilidades, levando a falsos positivos ou negativos.
Próximos Passos
O plano da Collabora é extrair o máximo de informação possível do sistema de build. Para obter uma visão completa, incluindo ligações dinâmicas e dados de bibliotecas de terceiros dentro do Core, será necessário aprofundar a análise dos sistemas de build. A equipe reconhece que não pode simplesmente exigir que os mantenedores de bibliotecas criem SBOMs, pois muitas são mantidas por indivíduos com recursos limitados. A geração de SBOMs deve ser integrada ao processo de build, pois o conteúdo dos componentes de software depende diretamente dos parâmetros de configuração atuais, e a manutenção manual pós-build é excessivamente trabalhosa. O próximo e mais desafiador estágio é detalhar a vasta base de código do LibreOffice Core para atender aos requisitos de segurança do CRA.
