💻 computer science

The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX

Este artigo compara os ecossistemas de ferramentas de SBOM do SPDX e do CycloneDX ao analisar centenas de ferramentas e milhares de relatórios de problemas, revelando que, embora o SPDX ostente um conjunto de ferramentas maior, mais maduro e com adoção mais ampla, o CycloneDX demonstra um maior engajamento de desenvolvedores e indicadores específicos de saúde de projeto, destacando as forças complementares de ambos os formatos.

Autores originais: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Publicado 2026-06-12

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um chef comandando um restaurante enorme. Para manter seus clientes seguros e felizes, você precisa saber exatamente quais ingredientes estão em cada prato que serve. Você precisa saber a marca da farinha, a data de validade do leite e se algum dos temperos veio de uma fazenda que teve um problema recente de contaminação.

No mundo do software, essa "lista de ingredientes" é chamada de Software Bill of Materials (SBOM). É um documento que lista cada código e biblioteca que um programa de software utiliza.

No entanto, ter apenas uma lista não é suficiente; você precisa das ferramentas certas para escrever a lista, verificá-la e atualizá-la. Atualmente, existem dois "idiomas" ou formatos principais para escrever essas listas: SPDX e CycloneDX. Pense neles como duas marcas diferentes de livros de receitas. Uma (SPDX) existe desde 2010 e é muito tradicional, enquanto a outra (CycloneDX) começou em 2017 e é mais nova e moderna.

Este artigo é um grande estudo que compara os ecossistemas de ferramentas que cercam esses dois livros de receitas. Os pesquisadores não olharam apenas para as receitas; eles olharam para as ferramentas de cozinha (programas de software) que ajudam os chefs a escrever e gerenciar essas listas.

Aqui está o que eles descobriram, dividido de forma simples:

1. A Cozinha de Ferramentas: Quem tem o quê?

Os pesquisadores analisaram centenas de ferramentas (tanto gratuitas/open-source quanto pagas/proprietárias) para ver quais tarefas elas podem realizar.

O "Multitarefa" vs. O "Especialista": Eles descobriram que as ferramentas pagas (proprietárias) são como mestres chefs que podem fazer quase tudo: escrever a lista, analisá-la, visualizá-la e corrigi-la. As ferramentas gratuitas (open-source), embora muito úteis, são um pouco mais limitadas. Elas são ótimas para escrever a lista (construção), mas muitas vezes têm dificuldade com visualizações sofisticadas ou análises profundas.
A Divisão de Formatos:
- As ferramentas CycloneDX são como os "construtores". Elas são excelentes em gerar a lista automaticamente enquanto o software está sendo construído.
- As ferramentas SPDX são como os "bibliotecários". Elas são muito fortes em comparar listas, traduzi-las de um formato para outro e lidar com detalhes de licenciamento legal.

2. A Vibe da Comunidade: Quem é mais ativo?

Os pesquisadores verificaram a "saúde" das comunidades por trás dessas ferramentas (quantas pessoas estão contribuindo, quantos "stars" elas têm no GitHub, quão rápido elas corrigem bugs).

CycloneDX é o novato energético: Mesmo que existam menos ferramentas CycloneDX no total, a comunidade ao redor delas é muito mais ativa. Eles têm mais contribuidores, mais "stars" (curtidas) e corrigem bugs muito mais rápido (cerca de 67% mais rápido) do que a comunidade SPDX. Parece uma startup agitada e de ritmo acelerado.
SPDX é o veterano estabelecido: Possui um número maior de ferramentas e um ecossistema muito maduro e estável. No entanto, ele se move de forma mais lenta. Leva mais tempo para corrigir bugs, mas tem um foco muito forte em questões legais e de licenciamento, o que faz sentido, pois começou como uma ferramenta para rastrear licenças de software.

3. Que Problemas Eles Estão Resolvendo?

A equipe analisou milhares de "relatórios de bugs" (reclamações ou pedidos de ajuda) para ver com o que as pessoas estão tendo dificuldades.

CycloneDX sofre com "Bugs": Por ser mais novo, as reclamações mais comuns são sobre coisas quebrando ou não funcionando corretamente. A comunidade está ocupada corrigindo esses problemas fundamentais.
SPDX sofre com "Novos Recursos": Por ser mais antigo e estável, os pedidos mais comuns são por novos recursos ou melhorias. As pessoas não estão perguntando "por que isso está quebrado?" tanto quanto perguntam "você pode adicionar este novo recurso legal?".
A Velocidade do Licenciamento: Se você tem um problema com licenças de software, o SPDX resolve isso muito mais rápido. Se você tem um bug de software geral, o CycloneDX resolve isso muito mais rápido.

4. Quem Está Usando o Quê?

Os pesquisadores olharam para os 250 projetos de software mais populares para ver qual "livro de receitas" eles utilizam.

Os Projetos "Descolados": Projetos escritos em linguagens modernas como Go e Python (frequentemente usadas para segurança e computação em nuvem) tendem a preferir o CycloneDX. Esses projetos costumam ser muito ativos, possuem muitos contribuidores e se movem rápido.
Os Projetos "Corporativos": Projetos escritos em Java e C# (frequentemente usados em grandes corporações) tendem a preferer o SPDX. Esses projetos costumam ser focados em conformidade rigorosa e regras legais.

O Resultado Final

O artigo conclui que escolher entre SPDX e CycloneDX não é apenas sobre escolher um formato; é sobre escolher o ecossistema certo para suas necessidades.

Se você está construindo um projeto de ritmo acelerado e focado em segurança (como um app na nuvem) e precisa de ferramentas que corrijam bugs rapidamente e se integrem bem ao desenvolvimento moderno, o CycloneDX e sua comunidade ativa podem ser sua melhor aposta.
Se você está em uma grande corporação onde a conformidade legal é soberana e precisa de ferramentas que sejam ótimas para traduzir formatos e lidar com licenças, o SPDX e seu ecossistema maduro e estável são provavelmente a melhor escolha.

Em resumo: CycloneDX é a máquina rápida, ágil e de correção de bugs, enquanto o SPDX é o veterano confiável e especialista em leis. Ambos são essenciais, mas servem a mestres diferentes.

Resumo Técnico: O Estado dos Ecossistemas de Ferramentas de SBOM

Declaração do Problema

As cadeias de suprimentos de software modernas dependem fortemente de dependências de terceiros, criando riscos significativos de segurança e confiabilidade quando existem vulnerabilidades em componentes menos seguros (ex: Log4Shell, SolarWinds). Embora as Listas de Materiais de Software (SBOMs) tenham emergido como um mecanismo crítico para transparência e responsabilidade — mandatado pela Ordem Executiva dos EUA em 2021 e adotado globalmente — sua utilidade é fortemente dependente das ferramentas que as geram, analisam e gerenciam.

Apesar da existência de dois formatos dominantes de SBOM, SPDX (estabelecido em 2010) e CycloneDX (introduzido em 2017), há uma falta de compreensão empírica sobre a saúde, maturidade e capacidades funcionais dos ecossistemas de ferramentas que circundam esses formatos. Os profissionais enfrentam desafios na seleção das ferramentas corretas devido à limitação de padronização, variabilidade na maturidade das ferramentas e falta de dados sobre quais formatos melhor suportam casos de uso específicos (ex: automação de build vs. conformidade de licença). Estudos anteriores focaram nas especificações em si ou em pesquisas limitadas com praticantes, deixando uma lacuna na análise quantitativa dos ecossistemas reais de ferramentas.

Metodologia

Os autores conduziram um estudo empírico abrangente comparando os ecossistemas SPDX e CycloneDX através de quatro Questões de Pesquisa (RQs), utilizando uma abordagem de coleta e análise de dados em múltiplas etapas:

Coleta e Classificação de Ferramentas (RQ1):
- Fonte de Dados: Centros oficiais de ferramentas para CycloneDX (219 ferramentas) e SPDX (47 ferramentas) até 27 de janeiro de 2024.
- Filtragem: A verificação manual identificou 108 ferramentas de código aberto (OSS) e 62 proprietárias. 78 ferramentas foram encontradas como suporte a ambos os formatos (Dual-Format).
- Análise: Dois autores categorizaram manualmente 187 ferramentas (140 CycloneDX, 47 SPDX) usando a Taxonomia de Classificação de Ferramentas da NTIA (categorias Produce, Consume, Transform) via ordenação por cartas fechadas. A confiabilidade inter-avaliador foi estabelecida (Krippendorff's $\alpha$ = 0,872).
Análise de Saúde do Ecossistema (RQ2):
- Conjunto de Dados: Expandiu o conjunto de dados OSS para incluir forks contribuintes do GitHub, resultando em 171 repositórios CycloneDX e 470 SPDX.
- Métricas: Avaliado usando métricas de saúde de comunidade CHAOSS (Stars, Watchers, Forks, Contribuidores, Pull Requests, Releases, Commits).
- Normalização: Todas as métricas foram normalizadas pela idade do repositório (dias) para considerar as diferenças de maturidade. A significância estatística foi testada usando o teste Mann-Whitney U com correção de Bonferroni.
Análise de Relatórios de Problemas (RQ3):
- Conjunto de Dados: Extraiu 36.990 relatórios de problemas (pós-2018) de 90 repositórios de ferramentas CycloneDX e 191 de ferramentas SPDX.
- Construção de Taxonomia: Derivou 14 categorias distintas de problemas a partir de issues tagueadas.
- Classificação: Validou uma abordagem de anotação baseada em LLM (usando mistralai/devstral-small-2-2) contra anotação humana em uma amostra aleatória estratificada (379 issues, $\alpha$ = 0,768). O modelo classificou todas as 33.840 issues.
- Métricas: Analisou a prevalência de problemas e tempos de resolução entre as categorias.
Análise de Adoção de Projetos (RQ4):
- Conjunto de Dados: Identificou 2.426 projetos no GitHub que utilizam ferramentas de SBOM em seus pipelines de CI (focando em casos de uso de "Build").
- Seleção: Comparou os 250 projetos mais estrelados que usam apenas ferramentas CycloneDX vs. os 250 que usam apenas ferramentas SPDX.
- Análise: Comparou métricas de saúde de projeto e distribuições de linguagens de programação (GPL vs. DSL).

Contribuições Principais e Resultados

1. Cobertura de Casos de Uso (RQ1)

Proprietário vs. OSS: Ferramentas proprietárias suportam uma gama mais ampla de casos de uso (1,14x mais) do que ferramentas OSS. Especificamente, ferramentas proprietárias são mais fortes em Analyze (Analisar) e View (Visualizar), enquanto ferramentas OSS se destacam em Support (Suporte/Integração/APIs).
Diferenças de Formato:
- Ferramentas apenas CycloneDX mostram forte associação positiva com casos de uso de Build e Support, mas carecem de suporte para Diff (comparação).
- Ferramentas apenas SPDX estão fortemente associadas a Translate (conversão de formato) e Diff, mas mostram suporte limitado para ferramentas de Build no conjunto de dados (embora o artigo note que a Microsoft fornece geração de SPDX nativa para o GitHub).
- Ferramentas de formato duplo (Dual-format) são prevalentes em casos de uso de Import, mas carecem de capacidades de Support.

2. Saúde da Comunidade das Ferramentas (RQ2)

Engajamento: Apesar de possuírem menos repositórios totais (171 vs. 470), as ferramentas CycloneDX exibem maior engajamento da comunidade. Elas possuem valores medianos mais altos para Stars, Watchers, Forks, Contribuidores e Pull Requests.
Atividade: As ferramentas CycloneDX apresentam maior atividade de commits e frequência de releases.
Contribuidores Recorrentes: Embora haja diferenças insignificantes na taxa de contribuidores recorrentes na maioria dos grupos de contagem de commits, as ferramentas SPDX atraem um volume maior de contribuições de contribuidores com mais de 1.000 commits, sugerindo um engajamento de longo prazo mais profundo em contribuições específicas de alto volume.

3. Prevalência e Resolução de Problemas (RQ3)

Volume de Problemas: As ferramentas CycloneDX têm um número médio de relatórios de problemas normalizados (abertos e fechados) superior ao das SPDX.
Velocidade de Resolução: As ferramentas CycloneDX resolvem problemas significativamente mais rápido (67,69% menos tempo de resolução em média).
- CycloneDX: Dominado por Correções de Bugs e Defeitos (41,90%). Resolve estes 174% mais rápido que o SPDX.
- SPDX: Dominado por Desenvolvimento de Funcionalidades e Melhorias (36,25%). Resolve questões de Licenciamento 51,85% mais rápido que o CycloneDX, consistente com as origens do SPDX como um formato focado em licenciamento.
Implicação: O ecossistema CycloneDX parece estar em uma fase de rápida correção de bugs e estabilização, enquanto o ecossistema SPDX está focado em expansão de funcionalidades e conformidade de licenciamento complexa.

4. Padrões de Adoção de Projetos (RQ4)

Saúde do Projeto: Projetos que utilizam ferramentas CycloneDX demonstram métricas de saúde de comunidade mais altas (mais estrelas, forks, contribuidores e commits) em comparação com aqueles que utilizam ferramentas SPDX.
Preferências de Linguagem:
- CycloneDX é prevalente em projetos Go e Python (frequentemente associados a DevOps focados em segurança e microsserviços).
- SPDX é prevalente em projetos Java e C# (alinhando-se com conformidade corporativa e necessidades formais de licenciamento).
Correlação de Atividade: Projetos com contagens de commits mais altas tendem a usar ferramentas que suportam View, Diff e Import (categoria Consume), enquanto projetos de menor atividade preferem Edit, Merge e Analyze (categorias Produce/Transform).

Significância e Alegações

O artigo afirma que a escolha de um formato de SBOM não deve ser feita isoladamente, mas deve considerar a maturidade e a saúde do ecossistema de ferramentas circundante.

Para DevOps Focado em Segurança: O estudo sugere que o CycloneDX pode ser preferível para projetos Go/Python que exigem automação de build rápida, resolução de bugs e alto engajamento da comunidade.
Para Conformidade Corporativa: O SPDX continua sendo a escolha mais forte para projetos Java/C# que priorizam conformidade de licença, tradução de formato e diffing, apoiado por um ecossistema mais maduro (embora menos ativo).
Para Desenvolvedores de Ferramentas: O estudo identifica lacunas específicas: ferramentas OSS precisam melhorar suas capacidades de Analyze e View (atualmente dominadas por ferramentas proprietárias), enquanto desenvolvedores de ferramentas SPDX devem focar em reduzir o backlog de funcionalidades, e desenvolvedores de CycloneDX devem manter seu alto rendimento de correção de bugs.
Impacto Regulatório: A análise nota uma inflexão visível na atividade de problemas após o mandato do governo dos EUA em 2021, ilustrando como eventos regulatórios moldam a dinâmica do desenvolvimento de código aberto em escala de ecossistema.

Os autores concluem que, embora ambos os formatos sejam essenciais, seus ecossistemas de ferramentas exibem estágios evolutivos e prioridades distintas. Compreender essas diferenças permite que os profissionais tomem decisões informadas que se alinhem às suas necessidades específicas de projeto, stacks de linguagem e requisitos de conformidade.