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

Abdul Ali Bangash; Arshdeep Singh; Bram Adams; Tongxu Ge; Zhimin Zhao; Zitao Wang

REVIEW 2 major objections 6 minor 66 references

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

T0 review · 2 major / 6 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read GitHub projects that adopt CycloneDX show stronger community activity than those using SPDX.

desk verdict A genuinely useful, large empirical map of the SPDX/CycloneDX tool ecosystems, with RQ1–RQ3 mostly solid and RQ4's headline comparison confounded by unbalanced search pools. read the letter →

arxiv 2512.21781 v2 pith:IGCKLPE4 submitted 2025-12-25 cs.SE

Zhimin Zhao , Abdul Ali Bangash , Tongxu Ge , Arshdeep Singh , Zitao Wang , Bram Adams This is my paper · ORCID

classification cs.SE

keywords SBOMSPDXCycloneDXsoftwaresupplychainsecurityopen-sourceecosystemhealthGitHubminingCI/CDadoptiontooluse-casetaxonomy

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that the two dominant SBOM formats, SPDX and CycloneDX, are best understood as competing tool ecosystems, not just competing specifications. Its central finding is that open-source projects using CycloneDX tools show significantly higher GitHub activity—more stars, forks, watchers, commits, pull requests, releases, and contributors—while SPDX retains a larger, more established tool ecosystem and broader industry adoption. The study also maps which use cases each ecosystem supports, showing that CycloneDX tools skew toward build-time generation and integration, SPDX tools toward diffing and translation, and proprietary tools toward broader coverage than open-source tools. This matters because SBOM adoption is now policy-driven, and the paper gives practitioners evidence that format choice should include ecosystem health, not just the specification.

What carries the argument

Three components carry the argument. Use-case coverage is measured by manually classifying 170 tools against the official SBOM tool-use-case taxonomy (produce, consume, transform). Ecosystem health is measured with community-health metrics—stars, forks, watchers, pull requests, releases, contributors, commits—normalized by repository age and compared via Mann-Whitney U tests with Cliff's delta effect sizes. Adoption is measured by mining CI configuration snippets from tool READMEs and searching GitHub to find 1,394 projects that invoke an SBOM tool in their build pipeline; those projects are then compared as top-250 sets per format.

What would settle it

Execute a random sample of the 1,394 identified CI pipelines, confirm that SBOM files are actually generated, and re-run the community-health comparison on verified adopters only. If the CycloneDX advantage shrinks or reverses under verification—or if the same health gap appears when the two sets are matched for project age and language—the RQ4 claim is falsified.

Watch

Extended reading notes

Core claim

Analyzing 470 SPDX and 171 CycloneDX open-source tool repositories, plus 36,990 issue reports and the top 250 most-starred GitHub projects using each format, the paper finds a consistent pattern: CycloneDX-using projects have higher normalized medians on every community-health metric, with large effect sizes, and CycloneDX tools resolve issues faster on average (88 vs 130 days). SPDX counters with a larger tool population (470 vs 171), a head start since 2011, faster resolution of licensing issues, and stronger association with translation and diffing use cases. The paper's conclusion is that the ecosystems are complementary rather than one being superior: SPDX is the mature, broad incumbent

Load-bearing premise

The central claim depends on CI snippet matching correctly identifying real SBOM tool use and on top-250 comparisons from unbalanced pools (307 SPDX vs 1,087 CycloneDX projects) reflecting format effects rather than tool availability or search coverage.

Editorial extensions

If this is right

SBOM adopters should evaluate the health of a format's tooling, not just the specification, before choosing; a format with fewer tools can still have more active maintainers.
Open-source tool developers have a clear gap to fill: build-time SBOM generation and integration support are well covered, but analysis and visualization features lag proprietary tools.
CycloneDX-using projects' higher engagement suggests that security-focused, modern cloud-native projects (Go, Python) are driving one ecosystem, while enterprise compliance stacks (Java, C#) drive the other.
Issue-resolution data points to concrete priorities: licensing issues are resolved faster by SPDX tools, while bug-fix and feature-development issues are resolved faster by CycloneDX tools.
Both formats have maintained strengths: CycloneDX resolves most issue categories faster, while SPDX resolves licensing issues 51.85% faster.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the engagement gap is real, it may not be caused by the format itself; CycloneDX tools tend to be promoted more heavily on their official tool center and are more numerous in the search pool, so the top-250 comparison may partly reflect discoverability and marketing rather than intrinsic quality.
A natural test is to run the CI SBOM-generation steps on a sample of the 1,394 projects and verify that SBOM files are actually produced; the paper acknowledges it did not execute projects, so a validation study could confirm or weaken the adoption findings.
The language split (Go/Python toward CycloneDX, Java/C# toward SPDX) suggests that format choice tracks the surrounding dev toolchain; if SPDX 3.0 expands beyond licensing, the activity gap may narrow as enterprise and cloud-native communities converge.
Future studies could use projects that generate both formats' SBOMs as matched controls, isolating format effects from project popularity.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The useful thing here is the scale and transparency of the mapping. The manual classification of 170 tools against the NTIA taxonomy, the ecosystem-level health metrics across 641 repositories, and the issue-label analysis across ~34k reports are all real work, and the replication package makes it checkable. RQ1's finding that proprietary tools skew dual-format while OSS tools skew single-format is a clean, credible result, and the chi-square diagnostics there are fine. RQ2 and RQ3 are also defensible: normalized metrics, Mann-Whitney with Bonferroni, effect sizes reported, and the issue-category hand-coding is documented with Kappa agreement and example issues. The paper is honest about snapshot limits and about not executing the CI snippets.

Where I part company with the authors is RQ4. The claim that CycloneDX-adopting projects are more active and mature rests on comparing the top 250 most-starred projects from pools of 307 SPDX-only and 1,087 CycloneDX-only projects, found via 11 SPDX vs 50 CycloneDX search patterns. That means the SPDX set is almost the entire detected population while the CycloneDX set is the top quarter. If the SPDX pattern set under-detects smaller projects, the comparison is not format-driven; it is coverage-driven. The paper itself concedes the CI snippets were not executed, so snippet presence is a noisy proxy. This is a load-bearing flaw in the headline claim, but it is repairable: matched sampling on stars/language/age, or at minimum a sensitivity analysis that compares the top N for several N and reports how pool truncation changes the gap. The language-preference analysis (Go/Python with CycloneDX, Java/C# with SPDX) is suggestive but inherits the same detection bias.

The minor issues are minor: the RQ1 chi-square double-counts dual-format tools across both groups, which inflates the test's significance, though the reported Cramér's V and residuals are still informative as descriptive associations. The abstract's phrase about industry adoption goes beyond what GitHub data can support; the threats section says as much.

Bottom line: for a reader who wants a descriptive map of SBOM tooling gaps, RQ1–RQ3 are worth the time, and the dataset is a useful starting point for future work. The RQ4 conclusion should not be cited as established until the pools are matched. I would send it to peer review, but with a clear request to redo RQ4's comparison and to soften the abstract. It deserves a serious referee, not a desk reject.

Referee Report

2 major / 6 minor

Summary. The paper presents a comparative empirical study of the SPDX and CycloneDX SBOM tool ecosystems. It manually classifies 170 tools from the official tool centers, compares CHAOSS-based health metrics for 171 CycloneDX and 470 SPDX tool repositories, analyzes 36,990 issue reports, and identifies 1,394 GitHub projects that appear to use SBOM tools in CI pipelines. The headline claim, stated in Section 4.4.1, is that projects adopting CycloneDX tools are more active and mature than those using SPDX tools, while SPDX retains a larger and more mature tool ecosystem. The paper is mostly descriptive and includes a replication package.

Significance. If the findings were robust, this would be a useful reference for SBOM practitioners and tool vendors. The strengths include a manually curated tool inventory, use of CHAOSS metrics, a substantial issue-report analysis, and a publicly available replication kit. The paper does not rely on fitted parameters or circular derivations. However, the central RQ4 claim that CycloneDX-using projects are more active is not currently supported because of a structural selection/detection confound: the top-250 sets are drawn from pools of very different sizes and were identified with very different numbers of search patterns. This concern is load-bearing for the abstract and the conclusions.

major comments (2)

[§3.5, §4.4.1, Table 8] The RQ4 comparison is confounded by selection and detection asymmetry. The paper compares the top-250 most-starred projects from a pool of 307 SPDX-using projects with the top-250 from a pool of 1,087 CycloneDX-using projects, where the pools were found using 11 SPDX CI patterns versus 50 CycloneDX patterns. Keeping the top 250 from the SPDX pool retains 81% of all detected SPDX projects, while the same selection retains only 23% of the CycloneDX pool. Even under identical underlying distributions, the CycloneDX top-250 will be drawn from a much higher quantile than the SPDX top-250, so the Mann-Whitney U tests in Table 8 do not test a well-defined population difference. The acknowledgment in Section 6.1 that CI snippets were not executed and SBOM generation was not verified further weakens the identification of actual SBOM usage. To support the headline claim, the authors need to either
[§4.1.1, Table 1, Table 2, Figure 3] The chi-square analysis of use-case support is ambiguous about whether dual-format tools are counted as independent observations in both the SPDX and CycloneDX groups. Table 1 appears to list percentages for all tools supporting each format, while Figure 3 and Table 2 treat dual-format tools as a separate category. If the chi-square test used the Table 1 columns, then dual-format tools are double-counted and the independence assumption is violated, invalidating the p-value and Cramér's V. The manuscript should state the exact contingency table used and, if necessary, re-run the analysis on exclusive categories (SPDX-only, CycloneDX-only, dual-format).

minor comments (6)

[Figure 1 vs. §3.5/§4.4] Figure 1 says 'Top-200 projects' but the text consistently says 'Top-250'. Please reconcile.
[Tables 4 and 8] The p-values are formatted ambiguously, e.g., '1.00 −10' and '3.79 −12'. These should be written in standard scientific notation, and values below 0.001 should be reported as '<0.001' rather than '0.000'.
[§4.3.1] 'format deviation' should be 'standard deviation' throughout this section.
[§4.3.3, Figure 12] The sentence 'SPDX tools have most (43.12%) of the issue reports related to Feature Development and Enhancement and Code Components' is confusing; 43.12% refers only to Feature Development and Enhancement, while Code Components is 21.57%.
[§4.4.1] The claim sentence lists 'commits' twice in the same enumeration ('stars, watchers, forks, pull requests, releases, contributors, and commits'). Please remove the duplication.
[§3.2] The description of the random sample from the CycloneDX tool center (140 of 219) should clarify whether the 170 distinct tools used in the analysis are the same as the sampled 187 after duplicate removal, and how the sampling weights are handled in the reported percentages.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the study is an empirical measurement; RQ4's pool asymmetry is a validity threat, not a definitional reduction.

full rationale

The paper contains no mathematical derivation or fitted-parameter structure whose output is equivalent to its input by construction. RQ1-RQ3 are manual and statistical descriptions of tool characteristics, health metrics, and issue reports; the reported differences are measured, not derived from the definitions of SPDX/CycloneDX. RQ4 compares GitHub projects identified by CI snippet matches, and the claim that CycloneDX-using projects show higher activity is an empirical observation on the collected data, not a quantity forced by the selection procedure. The top-250 selection does introduce a comparability threat (307 SPDX vs 1,087 CycloneDX projects, and the paper itself notes in Section 6.1 that snippet presence was not verified by executing the projects), but this is a construct-validity concern, not circularity: the compared metrics are not defined in terms of the selection criterion in a way that guarantees the result. The only self-citations (Mens et al. 2017a,b; Foundjem et al. 2021) are cited as prior applications of CHAOSS-style health metrics; they are not load-bearing for the paper's central findings, which rely on GitHub data and standard statistical tests. No uniqueness theorem, ansatz, or renamed result is invoked. Therefore the derivation chain is self-contained with respect to its empirical inputs, and no circular step can be exhibited.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The study relies on standard empirical assumptions about GitHub metrics, tool-center representativeness, age normalization, static CI-snippet matching, the NTIA taxonomy, and issue-tag fidelity. These are domain assumptions rather than ad hoc parameters; no free parameters are fitted and no new entities are postulated.

assumptions (6)

domain assumption GitHub community metrics (stars, forks, watchers, PRs, commits, contributors) are valid proxies for ecosystem health and maturity.
Used throughout RQ2 and RQ4; if these metrics do not reflect true health or engagement, the comparative conclusions weaken.
domain assumption Official SPDX and CycloneDX tool centers provide a representative set of tools for each ecosystem.
RQ1 and RQ2 sample from these lists; tools not listed are excluded, potentially biasing ecosystem-level conclusions.
domain assumption Normalization by repository age yields fair comparisons across repositories of different lifespans.
Applied to all metrics in RQ2 and RQ4; assumes linear scaling with age, which may not hold for young or very old repositories.
domain assumption CI configuration snippet matching correctly identifies projects that actually use SBOM tools.
RQ4 relies on static code-pattern search without building or running projects; the paper acknowledges this in Section 6.1.
domain assumption The NTIA tool taxonomy is an appropriate and complete framework for categorizing SBOM tool use cases.
RQ1 bases all classifications on this taxonomy; if the taxonomy is incomplete, the use-case coverage findings are incomplete.
domain assumption Issue tags assigned by maintainers faithfully represent the content of issues.
RQ3 uses tagged issues for category analysis; tag assignment may be inconsistent across projects and formats.

how reviews work

0 comments

Cite this review

Pith. "Pith review of The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX." pith.science (2026). https://pith.science/paper/IGCKLPE4

@misc{pith2026251221781,
  author       = {Pith},
  title        = {Pith review of: The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IGCKLPE4}},
  note         = {Machine review of arXiv:2512.21781}
}

read the original abstract

Software Bills of Materials (SBOMs) improve software release transparency by documenting components and dependencies, but their practical value depends on the tools that generate, analyze, and manage them. This paper compares the tool ecosystems of the two dominant SBOM formats: SPDX and CycloneDX. We analyze 108 open-source and 62 proprietary SBOM tools, compare ecosystem-level health metrics across 470 SPDX and 171 CycloneDX tools, examine 36,990 issue reports from open-source tools, and study the top 250 open-source projects using each format. Our results show that CycloneDX-using projects often exhibit stronger developer engagement and selected project health indicators, while SPDX benefits from a larger, more mature tool ecosystem and broader industry adoption. These findings highlight the complementary strengths of both ecosystems and identify opportunities for improving SBOM tooling across formats.

Figures

Figures reproduced from arXiv: 2512.21781 by the authors.

**Figure 2.** Distribution of 170 manually analyzed SBOM tools across the SBOM spec [PITH_FULL_IMAGE:figures/full_fig_p014_2.png] view at source ↗

**Figure 3.** Distribution of the 170 manually analyzed tools across Open-source vs. [PITH_FULL_IMAGE:figures/full_fig_p015_3.png] view at source ↗

Figures from the paper (13 more)

**Figure 4.** Figure 4: Visualization of the Pearson residuals to compare the use cases of SPDX, [PITH_FULL_IMAGE:figures/full_fig_p016_4.png]

**Figure 5.** Figure 5: Comparison of how 170 SBOM tools (both open-source and proprietary) [PITH_FULL_IMAGE:figures/full_fig_p017_5.png]

**Figure 6.** Figure 6: Visualization of the Pearson residuals to compare the use cases of Open [PITH_FULL_IMAGE:figures/full_fig_p018_6.png]

**Figure 7.** Figure 7: Comparison of the distribution of normalized metrics (by repository age), [PITH_FULL_IMAGE:figures/full_fig_p020_7.png]

**Figure 8.** Figure 8: Distribution of open-source contributor groups (by number of normalized [PITH_FULL_IMAGE:figures/full_fig_p023_8.png]

**Figure 9.** Figure 9: Representation of 17,093 issue reports in 90 CycloneDX tool repositories [PITH_FULL_IMAGE:figures/full_fig_p025_9.png]

**Figure 10.** Figure 10: Resolution time of 13,281 closed issue reports in 90 CycloneDX tool repos [PITH_FULL_IMAGE:figures/full_fig_p026_10.png]

**Figure 11.** Figure 11: Trend of prevalence and resolution time of issue reports from 2018 to 2023. [PITH_FULL_IMAGE:figures/full_fig_p027_11.png]

**Figure 12.** Figure 12: The distribution of Github issue reports by their category across SPDX [PITH_FULL_IMAGE:figures/full_fig_p032_12.png]

**Figure 13.** Figure 13: Distribution of resolution time (in seconds) of issue categories of SPDX [PITH_FULL_IMAGE:figures/full_fig_p034_13.png]

**Figure 14.** Figure 14: Community health metrics of Top-250 projects that use SPDX tools vs. [PITH_FULL_IMAGE:figures/full_fig_p035_14.png]

**Figure 15.** Figure 15: Programming languages of projects that use CycloneDX tools vs. projects [PITH_FULL_IMAGE:figures/full_fig_p037_15.png]

**Figure 16.** Figure 16: Visualization of the Pearson residuals to compare the Quartiles (by number [PITH_FULL_IMAGE:figures/full_fig_p038_16.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

66 extracted references · 3 canonical work pages

[1]

, " * write output.state after.block = add.period write newline

ENTRY address archive author booktitle chapter doi edition editor eid eprint howpublished institution journal key month note number organization pages publisher school series title type url volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all ...
[2]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...
[3]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...
[4]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION n.separate 't := "" #0 'numnames := t empty not t #-1 #1 subs...
[5]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...
[6]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION n.separate 't := "" #0 'numnames := t empty not t #-1 #1 subs...
[7]

://github.com/SAILResearch/replication-25-ali-sbom_tools_ecosystem

AbdulAli (2025) Sbom replication kit. ://github.com/SAILResearch/replication-25-ali-sbom_tools_ecosystem

2025
[8]

Empirical Software Engineering 21:1437--1475

Assar S, Borg M, Pfahl D (2016) Using text clustering to predict defect resolution time: a conceptual replication and an evaluation of prediction accuracy. Empirical Software Engineering 21:1437--1475

2016

Show all 66 references

[9]

2303.11102

Balliu M, Baudry B, Bobadilla S, Ekstedt M, Monperrus M, Ron J, Sharma A, Skoglund G, Soto-Valero C, Wittlinger M (2023) Challenges of producing software bill of materials for java. 2303.11102

2023 arXiv
[10]

ACM Transactions on Software Engineering and Methodology

Batoun MA, Yung KL, Tian Y, Sayagh M (2023) An empirical study on github pull requests’ reactions. ACM Transactions on Software Engineering and Methodology

2023
[11]

https://www.dynatrace.com/news/blog/what-is-log4shell/, log4j vulnerability explained

Berger A (2023) W hat is L og4 S hell? T he L og4j vulnerability explained (and what to do about it) --- dynatrace.com. https://www.dynatrace.com/news/blog/what-is-log4shell/, log4j vulnerability explained

2023
[12]

Bhattacharya P, Neamtiu I (2011) Assessing programming language impact on development and maintenance: A study on c and c++. In: Proceedings of the 33rd International Conference on Software Engineering, Association for Computing Machinery, New York, NY, USA, ICSE '11, p 171–18...

2011
[13]

ACM Transactions on Software Engineering and Methodology

Bi T, Xia B, Xing Z, Lu Q, Zhu L (2023) On the way to sboms: Investigating design issues and solutions in practice. ACM Transactions on Software Engineering and Methodology

2023
[14]

Journal of Systems and Software 146:112--129

Borges H, Valente MT (2018) What’s in a github star? understanding repository starring practices in a social coding platform. Journal of Systems and Software 146:112--129

2018
[15]

https://scribesecurity.com, [Victim to a Software Supply Chain Vulnerability]

Brudo B (2023) What Happens When an AI Company Falls Victim to a Software Supply Chain Vulnerability . https://scribesecurity.com, [Victim to a Software Supply Chain Vulnerability]

2023
[16]

cyclonedx

Brudo B (2024) Spdx vs. cyclonedx. https://scribesecurity.com/blog/spdx-vs-cyclonedx-sbom-formats-compared/, [What are SBOM Formats]

2024
[17]

https://chaoss.community/kb-metrics-and-metrics-models/

C P L Foundation (Accessed May 27, 2024) Community health analytics open source software . https://chaoss.community/kb-metrics-and-metrics-models/

2024
[18]

Sociological methods & research 42(3):294--320

Campbell JL, Quincy C, Osserman J, Pedersen OK (2013) Coding in-depth semistructured interviews: Problems of unitization and intercoder reliability and agreement. Sociological methods & research 42(3):294--320

2013
[19]

@ alex, this fixes\# 9

Chopra A, Mo M, Dodson S, Beschastnikh I, Fels SS, Yoon D (2021) "@ alex, this fixes\# 9": Analysis of referencing patterns in pull request discussions. Proceedings of the ACM on human-computer interaction 5(CSCW2):1--25

2021
[20]

Tutorials in Quantitative Methods for Psychology 112, doi:10.1037/0033-2909.112.1.155

Cohen J (1992) A power primer. Tutorials in Quantitative Methods for Psychology 112, doi:10.1037/0033-2909.112.1.155

1992 doi
[21]

ACM New York, NY, USA, vol 62, pp 36--43

Cox R (2019) Surviving software dependencies. ACM New York, NY, USA, vol 62, pp 36--43

2019
[22]

Princeton university press

Cram \'e r H (1999) Mathematical methods of statistics, vol 43. Princeton university press

1999
[23]

https://www.techtarget.com/searchsecurity/tip/SBOM-formats-compared-CycloneDX-vs-SPDX-vs-SWID-Tags, [CycloneDX vs

Das R (2023) Sbom formats compared. https://www.techtarget.com/searchsecurity/tip/SBOM-formats-compared-CycloneDX-vs-SPDX-vs-SWID-Tags, [CycloneDX vs. SPDX vs. SWID Tags]

2023
[24]

diversity, productivity and quality—empirical study of the openstack ecosystem

Foundjem A, Eghan E, Adams B (2021) Onboarding vs. diversity, productivity and quality—empirical study of the openstack ecosystem. In: 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), IEEE, pp 1033--1045

2021
[25]

Research in Social and Administrative Pharmacy 9(3):330--338

Gisev N, Bell JS, Chen TF (2013) Interrater agreement and interrater reliability: key concepts, approaches, and applications. Research in Social and Administrative Pharmacy 9(3):330--338

2013
[26]

Elsevier, vol 172, p 110653

Gkortzis A, Feitosa D, Spinellis D (2021) Software reuse cuts both ways: An empirical analysis of its relationship with security vulnerabilities. Elsevier, vol 172, p 110653

2021
[27]

The Linux Foundation

Hendrick S (2022) Software bill of materials (sbom)and cybersecurity readiness. The Linux Foundation

2022
[28]

In: Proceedings of the 23rd International Conference on Software Engineering

Herbsleb JD, Mockus A, Finholt TA, Grinter RE (2001) An empirical study of global software development: distance and speed. In: Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001, IEEE, pp 81--90

2001
[29]

In: 2011 18th Working Conference on Reverse Engineering, pp 219--228, doi:10.1109/WCRE.2011.34

Herraiz I, Shihab E, Nguyen TH, Hassan AE (2011) Impact of installation counts on perceived quality: A case study on debian. In: 2011 18th Working Conference on Reverse Engineering, pp 219--228, doi:10.1109/WCRE.2011.34

2011 doi
[30]

https://wwwisoorg/standard/45170html ISO/IEC JTC 1/SC 27

ISO/IEC (2022) Swid. https://wwwisoorg/standard/45170html ISO/IEC JTC 1/SC 27

2022
[31]

quality analysis of open-source software

Jarczyk O, Gruszka B, Jaroszewicz S, Bukowski L, Wierzbicki A (2014) Github projects. quality analysis of open-source software. pp 80--94, doi:10.1007/978-3-319-13734-6_6

2014 doi
[32]

Empirical Software Engineering 22, doi:10.1007/s10664-016-9436-6

Jiang J, Lo D, He J, Xia X, Kochhar PS, Zhang L (2017) Why and how developers fork what from whom in github. Empirical Software Engineering 22, doi:10.1007/s10664-016-9436-6

2017 doi
[33]

Concurrent Engineering 8(4):297--321, doi:10.1177/1063293X0000800404

Jiao J, Tseng MM, Ma Q, Zou Y (2000) Generic bill-of-materials-and-operations for high-variety production management. Concurrent Engineering 8(4):297--321, doi:10.1177/1063293X0000800404

2000 doi
[34]

Information and Software Technology 49(11-12):1073--1086

Kampenes VB, Dyb T, Hannay JE, Sj berg DI (2007) A systematic review of effect size in software engineering experiments. Information and Software Technology 49(11-12):1073--1086

2007
[35]

In: Product-Focused Software Process Improvement: 16th International Conference, PROFES 2015, Bolzano, Italy, December 2-4, 2015, Proceedings 16, Springer, pp 295--310

Kikas R, Dumas M, Pfahl D (2015) Issue dynamics in github projects. In: Product-Focused Software Process Improvement: 16th International Conference, PROFES 2015, Bolzano, Italy, December 2-4, 2015, Proceedings 16, Springer, pp 295--310

2015
[36]

Ladisa P, Plate H, Martinez M, Barais O (2022) Taxonomy of attacks on open-source software supply chains

2022
[37]

https://spdxorg/

Linux (2023) Spdx. https://spdxorg/

2023
[38]

In: 2020 IEEE Systems Security Symposium (SSS), pp 1--4, doi:10.1109/SSS47320.2020.9174365

Martin RA (2020) Visibility & control: Addressing supply chain challenges to trustworthy software-enabled things. In: 2020 IEEE Systems Security Symposium (SSS), pp 1--4, doi:10.1109/SSS47320.2020.9174365

2020
[39]

1711.04532

Mens T, Adams B, Marsan J (2017 a ) Towards an interdisciplinary, socio-technical analysis of software ecosystem health. 1711.04532

2017 arXiv
[40]

arXiv preprint arXiv:171104532

Mens T, Adams B, Marsan J (2017 b ) Towards an interdisciplinary, socio-technical analysis of software ecosystem health. arXiv preprint arXiv:171104532

2017
[41]

arXiv preprint arXiv:240211151

Mirakhorli M, Garcia D, Dillon S, Laporte K, Morrison M, Lu H, Koscinski V, Enoch C (2024) A landscape study of open source and proprietary tools for software bill of materials (sbom). arXiv preprint arXiv:240211151

2024
[42]

Muir \' \'E \'O (2019) Framing software component transparency: Establishing a common software bill of material (sbom). vol 12

2019
[43]

In: 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME), IEEE, pp 39--49

Nocera S, Romano S, Di Penta M, Francese R, Scanniello G (2023) Software bill of materials adoption: A mining study from github. In: 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME), IEEE, pp 39--49

2023
[44]

https://www.ntia.gov/other-publication/ntia-software-component-transparency, [SBOM Virtual Multistakeholder Meeting]

NTIA (2021) Ntia software component transparency. https://www.ntia.gov/other-publication/ntia-software-component-transparency, [SBOM Virtual Multistakeholder Meeting]

2021
[45]

https://cyclonedxorg/

OWASP (2021) Cyclonedx. https://cyclonedxorg/

2021
[46]

https://cyclonedx.org/docs/1.4/json/, [CycloneDx Documentation]

OWASP (2023 a ) Official cyclonedx specification documentation json reference v1.4. https://cyclonedx.org/docs/1.4/json/, [CycloneDx Documentation]

2023
[47]

https://cyclonedx.org/tool-center/, [CycloneDx Tools]

OWASP (2023 b ) Official cyclonedx tool center. https://cyclonedx.org/tool-center/, [CycloneDx Tools]

2023
[48]

Commun ACM 60(10):91–100, doi:10.1145/3126905, ://doi.org/10.1145/3126905

Ray B, Posnett D, Devanbu P, Filkov V (2017) A large-scale study of programming languages and code quality in github. Commun ACM 60(10):91–100, doi:10.1145/3126905, ://doi.org/10.1145/3126905

2017 doi
[49]

Remaley EL, Remaley D (2021) Ntia sbom effort is progressing well. NTIA

2021
[50]

https://redis.io/, [Redis Library]

Sanfilippo S (2023) R edis --- redis.io. https://redis.io/, [Redis Library]

2023
[51]

https://spdx.dev/tools-community/, [Open Source SPDX Tools]

SPDX (2023 a ) Official SPDX Open Source Tools . https://spdx.dev/tools-community/, [Open Source SPDX Tools]

2023
[52]

https://spdx.dev/tools-commercial/, [Commercial Proprietary SPDX Tools]

SPDX (2023 b ) Official SPDX Proprietary Tools . https://spdx.dev/tools-commercial/, [Commercial Proprietary SPDX Tools]

2023
[53]

https://spdx.github.io/spdx-spec/v2.3/package-information/, [SPDX Documentation]

SPDX (2023 c ) Official SPDX Specification Documentation v2.3 . https://spdx.github.io/spdx-spec/v2.3/package-information/, [SPDX Documentation]

2023
[54]

van der Storm T (2007) Component-based configuration, integration and delivery

2007
[55]

(2007) Component-based configuration, integration and delivery

Storm VD, Tijs, et al. (2007) Component-based configuration, integration and delivery

2007
[56]

://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf, [NTIA2021]

Telecommunications N, (NTIA) IA (2021 a ) Minimum Elements for a Software Bill of Materials (SBOM) . ://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf, [NTIA2021]

2021
[57]

://www.ntia.gov/files/ntia/publications/ntia_sbom_tooling_taxonomy-2021mar30.pdf, [NTIATaxonomy]

Telecommunications N, (NTIA) IA (2021 b ) Sbom tool classification taxonomy. ://www.ntia.gov/files/ntia/publications/ntia_sbom_tooling_taxonomy-2021mar30.pdf, [NTIATaxonomy]

2021
[58]

an overview of some recommended measures of effect size

Tomczak M, Tomczak E (2014) The need to report effect size estimates revisited. an overview of some recommended measures of effect size. Trends in Sport Sciences

2014
[59]

Waltermire DA, Feldman L, Witte GA (2016) Improving security and software management through the use of swid tags. David A. Waltermire, Larry Feldman, Gregory A. Witte

2016
[60]

Wan Z, Xia X, Lo D, Murphy GC (2019) How does machine learning change software development practices? IEEE Transactions on Software Engineering 47(9):1857--1871

2019
[61]

(1970) Critical values and probability levels for the wilcoxon rank sum test and the wilcoxon signed rank test

Wilcoxon F, Katti S, Wilcox RA, et al. (1970) Critical values and probability levels for the wilcoxon rank sum test and the wilcoxon signed rank test. Selected tables in mathematical statistics 1:171--259

1970
[62]

Forrester

Worthington J (2023) The world lags with sbom requirements, but likely not for long. Forrester

2023
[63]

In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), IEEE, pp 2630--2642

Xia B, Bi T, Xing Z, Lu Q, Zhu L (2023 a ) An empirical study on software bill of materials: Where we stand and the road ahead. In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), IEEE, pp 2630--2642

2023
[64]

arXiv preprint arXiv:230702088

Xia B, Zhang D, Liu Y, Lu Q, Xing Z, Zhu L (2023 b ) Trust in software supply chains: Blockchain-enabled sbom and the aibom future. arXiv preprint arXiv:230702088

2023
[65]

In: 2019 IEEE 26th international conference on software analysis, Evolution and Reengineering (SANER), IEEE, pp 589--593

Zerouali A, Mens T, Robles G, Gonzalez-Barahona JM (2019) On the diversity of software package popularity metrics: An empirical study of npm. In: 2019 IEEE 26th international conference on software analysis, Evolution and Reengineering (SANER), IEEE, pp 589--593

2019
[66]

In: Perspectives on data science for software engineering, Elsevier, pp 137--141

Zimmermann T (2016) Card-sorting: From text to themes. In: Perspectives on data science for software engineering, Elsevier, pp 137--141

2016

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.

[1] [1]

, " * write output.state after.block = add.period write newline

ENTRY address archive author booktitle chapter doi edition editor eid eprint howpublished institution journal key month note number organization pages publisher school series title type url volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all ...

[2] [2]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...

[3] [3]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...

[4] [4]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION n.separate 't := "" #0 'numnames := t empty not t #-1 #1 subs...

[5] [5]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...

[6] [6]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION n.separate 't := "" #0 'numnames := t empty not t #-1 #1 subs...

[7] [7]

://github.com/SAILResearch/replication-25-ali-sbom_tools_ecosystem

AbdulAli (2025) Sbom replication kit. ://github.com/SAILResearch/replication-25-ali-sbom_tools_ecosystem

2025

[8] [8]

Empirical Software Engineering 21:1437--1475

Assar S, Borg M, Pfahl D (2016) Using text clustering to predict defect resolution time: a conceptual replication and an evaluation of prediction accuracy. Empirical Software Engineering 21:1437--1475

2016