pith. sign in

arxiv: 2606.02442 · v1 · pith:CE3Q3D7Vnew · submitted 2026-06-01 · 💻 cs.SE · cs.CR

Poking Around in the Dark: Why a Shared Understanding of Components Matters

Felix Reichmann , Wolfgang Krane , Alena Naiakshina , Martin Johns , Simon Koch This is my paper

Pith reviewed 2026-06-28 13:32 UTC · model grok-4.3

classification 💻 cs.SE cs.CR
keywords SBOMsoftware bill of materialscomponent inclusion mechanismssoftware supply chain securityvulnerability managementSBOM generation toolsopen source components
0
0 comments X

The pith

No SBOM generation tool covers all component inclusion mechanisms, preventing security-grade SBOMs under current definitions.

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

The paper questions the assumption that developers agree on what components an SBOM should list and that existing tools can produce reliable lists for supply chain security. It first maps out Component Inclusion Mechanisms across the full development lifecycle, then tests five tools on real projects written in Python, Java, Go, PHP, Rust, and C. The results show every tool misses at least some mechanisms, leaving systematic gaps and inconsistent results. Because of these blind spots, the authors conclude that SBOMs cannot yet deliver the security benefits they promise without first settling on a shared definition of a component.

Core claim

Through a ground-up analysis of Component Inclusion Mechanisms and a systematic evaluation of cdxgen, syft, trivy, ORT, and the Microsoft sbom-tool against a ground truth dataset in six languages, the authors establish that no tool covers all identified CIMs, that common gaps exist across tools, and that SBOMs therefore exhibit ambiguity and blind spots in component inclusion, rendering a security-grade SBOM unachievable with the evaluated tools.

What carries the argument

Component Inclusion Mechanisms (CIMs), the distinct ways components enter software during its development lifecycle that determine which items must appear in an SBOM.

If this is right

  • SBOM generators must be updated to handle every CIM before they can produce complete component lists.
  • Without a shared definition of what counts as a component, SBOMs cannot reliably support vulnerability identification.
  • Software supply chain security efforts that rely on SBOMs will fail to deliver consistent results.
  • Clarifying inclusion rules is a prerequisite for any further progress on SBOM tooling.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Standards groups may need to publish explicit inclusion criteria before tool vendors can close the observed gaps.
  • Users might reduce but not remove blind spots by running several SBOM generators in parallel and reconciling their outputs.
  • The same definitional problem could affect other transparency artifacts such as software composition analysis reports.
  • Language-specific or build-system-specific guidelines could be a practical next step while a universal definition is developed.

Load-bearing premise

The authors' ground truth dataset accurately captures all relevant components and CIMs across the six programming languages tested.

What would settle it

An independent replication that constructs a new ground truth for the same projects and shows at least one of the five tools identifying every component in that ground truth would falsify the claim that no tool covers all CIMs.

Figures

Figures reproduced from arXiv: 2606.02442 by Alena Naiakshina, Felix Reichmann, Martin Johns, Simon Koch, Wolfgang Krane.

Figure 1
Figure 1. Figure 1: Mechanisms to include software components. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
read the original abstract

By listing the components included in an application, Software Bills of Materials (SBOMs) are intended to support the timely identification of vulnerable components and ensure the security of the software supply chain. However, we question the underlying assumption that there is agreement on the components to be listed in an SBOM and that current technology is sufficient to secure the software supply chain. First, we propose a ground-up analysis of Component Inclusion Mechanisms (CIM) in the software's development lifecycle. Then we systematically analyze the four popular SBOM generation tools, cdxgen, syft, trivy, ORT, and the Microsoft sbom-tool, to understand how they define and identify relevant components. Finally, we assess these using a ground truth across the programming languages Python, Java, Go, PHP, Rust, and C. While today's tools are a step toward identifying components, our results show that no tool covers all identified CIMs and that common gaps exist across tools. We demonstrate that, under the current vague definitions and tooling, SBOMs exhibit ambiguity and blind spots in component inclusion. Thus, a security-grade SBOM is not achievable with the evaluated tools, necessitating further progress to ensure software supply chain security. We need to go back to the drawing board to clarify which components should be included in an SBOM and revise SBOM generators accordingly. Without a shared understanding of what a component is, any effort to secure software supply chains with SBOMs will fail.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper argues that SBOMs cannot achieve security-grade quality because current tools (cdxgen, syft, trivy, ORT, Microsoft sbom-tool) exhibit systematic blind spots in component identification. It supports this via a proposed ground-up taxonomy of Component Inclusion Mechanisms (CIMs), an empirical comparison of the five tools, and evaluation against a custom ground truth spanning Python, Java, Go, PHP, Rust, and C. The conclusion is that vague definitions and incomplete tooling necessitate revisiting what counts as a component before SBOMs can secure supply chains.

Significance. If the ground-truth construction and tool evaluations hold, the work supplies concrete evidence that existing SBOM generators leave reproducible gaps across languages and that standards bodies must first settle definitional questions. The multi-language scope and direct tool comparison are strengths; the absence of any machine-checked artifacts or parameter-free derivations is noted but does not diminish the empirical contribution if the dataset is reproducible.

major comments (2)
  1. [Abstract / Methods] Abstract and Methods (ground-truth construction paragraph): the central claim that 'no tool covers all identified CIMs' and that 'a security-grade SBOM is not achievable' rests entirely on the completeness of the authors' ground truth. No description is given of how CIMs were enumerated, whether inter-rater agreement was measured, or how the dataset was cross-checked against language-specific package registries and build manifests. Without these details the reported gaps cannot be distinguished from artifacts of an incomplete or over-inclusive ground truth.
  2. [Results] Results section (tool-coverage tables): the paper reports common gaps across tools but does not state exclusion criteria for components that appear only in transitive dependencies, build-time artifacts, or language-specific runtime images. If the ground truth includes such items while the evaluated tools follow narrower but defensible policies (e.g., CycloneDX or SPDX scoping rules), the 'blind spot' diagnosis is not yet load-bearing.
minor comments (2)
  1. [Introduction] The acronym CIM is introduced without an explicit mapping to existing terms in SPDX, CycloneDX, or NTIA guidance; a short table relating CIM categories to those standards would improve clarity.
  2. [Figures/Tables] Figure captions and table headers should explicitly state the number of projects or packages per language so readers can assess statistical power.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments. We will revise the manuscript to provide more details on the ground truth construction and evaluation criteria as requested.

read point-by-point responses

  1. Referee: [Abstract / Methods] Abstract and Methods (ground-truth construction paragraph): the central claim that 'no tool covers all identified CIMs' and that 'a security-grade SBOM is not achievable' rests entirely on the completeness of the authors' ground truth. No description is given of how CIMs were enumerated, whether inter-rater agreement was measured, or how the dataset was cross-checked against language-specific package registries and build manifests. Without these details the reported gaps cannot be distinguished from artifacts of an incomplete or over-inclusive ground truth.

    Authors: The referee correctly identifies that the current manuscript provides limited detail on the ground-truth construction. We will add a dedicated subsection in the Methods section describing the enumeration process: CIMs were identified by examining the build and packaging mechanisms documented in official language references and tools for Python (setup.py, requirements.txt, pip), Java (Maven, Gradle), Go (go.mod), PHP (composer), Rust (Cargo), and C (make, autotools). Cross-checking was done by comparing against package registries and inspecting sample projects' manifests. Inter-rater agreement was not formally measured; the process was collaborative among the authors with consensus on inclusions. This addition will allow readers to assess the completeness of the ground truth. revision: yes

  2. Referee: [Results] Results section (tool-coverage tables): the paper reports common gaps across tools but does not state exclusion criteria for components that appear only in transitive dependencies, build-time artifacts, or language-specific runtime images. If the ground truth includes such items while the evaluated tools follow narrower but defensible policies (e.g., CycloneDX or SPDX scoping rules), the 'blind spot' diagnosis is not yet load-bearing.

    Authors: We will revise the Results section to explicitly state our inclusion criteria: the ground truth encompasses all components that are installed or referenced during build or runtime, including transitive dependencies that end up in the final artifact. We exclude components that are only used in development environments but not shipped. Regarding standards, we note that CycloneDX and SPDX do not mandate exclusion of transitive dependencies, and our evaluation uses a security-oriented broad scope to highlight potential risks. This clarification will address the concern and strengthen the interpretation of the gaps. revision: yes

Circularity Check

0 steps flagged

No significant circularity; empirical comparison to independent ground truth

full rationale

The paper conducts a ground-up CIM analysis, evaluates four SBOM tools against that analysis, and compares results to an author-constructed ground truth dataset spanning six languages. No equations, fitted parameters, or self-citations appear in the provided text that would reduce the central claim (tool gaps relative to the ground truth) to a definitional or self-referential loop. The ground truth is presented as derived separately from the tool evaluations, satisfying the criterion for an external benchmark. This is a standard empirical study structure with no load-bearing self-citation chains or renaming of known results.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the proposed CIM taxonomy and an un-detailed ground truth dataset; both are introduced or assumed within the paper without external verification described in the abstract.

axioms (1)
  • domain assumption A complete and accurate ground truth exists for component inclusion across the tested languages
    Used as benchmark to evaluate tool coverage
invented entities (1)
  • Component Inclusion Mechanisms (CIM) no independent evidence
    purpose: Categorize how components enter software during the development lifecycle
    New analytical lens proposed to expose gaps in SBOM tools

pith-pipeline@v0.9.1-grok · 5806 in / 1170 out tokens · 24193 ms · 2026-06-28T13:32:02.022350+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

194 extracted references · 3 canonical work pages

  1. [1]

    One year after log4shell, firms still strug- gle to hunt down log4j,

    L. Vaas, “One year after log4shell, firms still strug- gle to hunt down log4j,” 2022. [Online]. Avail- able: https://www.contrastsecurity.com/security-influencers/one-year- after-log4shell-firms-still-struggle-to-hunt-down-log4j

    2022

  2. [2]

    Log4j vulnerability (log4shell): Ongoing challenges in remediation,

    P. Umbelino, “Log4j vulnerability (log4shell): Ongoing challenges in remediation,” 2022. [Online]. Available: https://www.bitsight.com/ blog/log4j-vulnerability-log4shell-ongoing-challenges-remediation

    2022

  3. [3]

    Advisory on software bill of materials and real-time vulnerability monitoring for open-source soft- ware and third-party dependencies,

    S. Springett, “Advisory on software bill of materials and real-time vulnerability monitoring for open-source soft- ware and third-party dependencies,” 2025. [Online]. Avail- able: https://owasp.org/blog/2025/02/24/advisory-on-implementation- of-software-bill-of-materials-for-vulnerability-management

    2025

  4. [4]

    Enhancing software supply chain re- silience: Strategy for mitigating software supply chain security risks and ensuring security continuity in development lifecycle,

    A. Ahmed and A. Abdullah, “Enhancing software supply chain re- silience: Strategy for mitigating software supply chain security risks and ensuring security continuity in development lifecycle,”Interna- tional Journal on Soft Computing, vol. 15, no. 1/2, pp. 01–18, 2024

    2024

  5. [5]

    Review of the december 2021 log4j event,

    Cybersecurity and Infrastructure Security Agency, “Review of the december 2021 log4j event,” 2022. [Online]. Available: https://www.cisa.gov/sites/default/files/publications/CSRB- Report-on-Log4-July-11-2022_508.pdf

    2021

  6. [6]

    Measurement challenges in software assurance and supply chain risk management,

    N. R. Mead, C. Woody, and S. Hissam, “Measurement challenges in software assurance and supply chain risk management,” 2024. [Online]. Available: https://www.sei.cmu.edu/blog/measurement-challenges-in- software-assurance-and-supply-chain-risk-management/

    2024

  7. [7]

    Cve-2014-0160,

    Information Technology Laboratory, “Cve-2014-0160,” 2014. [Online]. Available: https://nvd.nist.gov/vuln/detail/cve-2014-0160

    2014

  8. [8]

    Analysis of supply chain attacks in open-source software and miti- gation strategies,

    J. Merigala, V. Kumar, J. Gujjarlapudi, M. Gupta, and A. S. Kumar, “Analysis of supply chain attacks in open-source software and miti- gation strategies,” in2024 5th International Conference on Communi- cation, Computing & Industry 6.0 (C2I6). Bengaluru, India: IEEE, 2024, pp. 1–5

    2024

  9. [9]

    Executive order 14028: Improving the nation’s cybersecurity,

    President of the United States, “Executive order 14028: Improving the nation’s cybersecurity,” pp. 26633–26647, 2021. [Online]. Available: https://www.federalregister.gov/documents/2021/ 05/17/2021-10460/improving-the-nations-cybersecurity

    2021

  10. [10]

    Cyber resilience act: Cra,

    European Parliament and the council of the european union, “Cyber resilience act: Cra,” 2024. [Online]. Available: https://eur- lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847

    2024

  11. [11]

    Owasp top 10:2025,

    Open Web Application Security Project, “Owasp top 10:2025,” 2025. [Online]. Available: https://owasp.org/Top10/2025/

    2025

  12. [12]

    Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,

    T. W. Stalnaker, N. Wintersgill, O. Chaparro, M. Di Penta, D. M. German, and D. Poshyvanyk, “Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,” inProceedings of the IEEE/ACM 46th International Con- ference on Software Engineering (ICSE), A. Roychoudhury, A. Paiva, R. Abreu, and M. Storey, Eds. L...

    2024

  13. [13]

    On the way to sboms: In- vestigating design issues and solutions in practice,

    T. Bi, B. Xia, Z. Xing, Q. Lu, and L. Zhu, “On the way to sboms: In- vestigating design issues and solutions in practice,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 6, pp. 1–25, 2024

    2024

  14. [14]

    Software bills of materials are required. are we there yet?

    N. Zahan, E. Lin, M. Tamanna, W. Enck, and L. Williams, “Software bills of materials are required. are we there yet?”IEEE Security & Privacy, vol. 21, no. 2, pp. 82–88, 2023

    2023

  15. [15]

    Jbo- maudit: Assessing the landscape, compliance, and security implications of java sboms,

    Y. Xiao, D. Kirat, D. L. Schales, J. Jang, L. Xing, and X. Liao, “Jbo- maudit: Assessing the landscape, compliance, and security implications of java sboms,” inProceedings 2025 Network and Distributed System Security Symposium, C. Pöpper and H. Okhravi, Eds. San Diego, CA, USA: Internet Society, 2025, pp. 1–20

    2025

  16. [16]

    Challenges of producing software bill of materials for java,

    M. Balliu, B. Baudry, S. Bobadilla, M. Ekstedt, M. Monperrus, J. Ron, A. Sharma, G. Skoglund, C. Soto-Valero, and M. Wittlinger, “Challenges of producing software bill of materials for java,”IEEE Security & Privacy, vol. 21, no. 6, pp. 12–23, 2023

    2023

  17. [17]

    Sbom generation tools under microscope: A focus on the npm ecosystem,

    M. F. Rabbi, A. I. Champa, C. Nachuma, and M. F. Zibran, “Sbom generation tools under microscope: A focus on the npm ecosystem,” inProceedings of the 39th ACM/SIGAPP Symposium on Applied Computing (SAC), J. Hong, J. W. Park, and A. Przybyłek, Eds. Avila Spain: ACM, 2024, pp. 1233–1241

    2024

  18. [18]

    Sbom generation tools in the python ecosystem: an in-detail analysis,

    S. Cofano, G. Benedetti, and M. Dell’Amico, “Sbom generation tools in the python ecosystem: an in-detail analysis,” in2024 IEEE 23rd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). Sanya, China: IEEE, 2024, pp. 427–434

    2024

  19. [19]

    A large scale empirical analysis on the adherence gap between standards and tools in sbom,

    C. Wang, J. Wu, H. Lyu, X. Ling, T. Luo, Y. Wu, and C. Zhao, “A large scale empirical analysis on the adherence gap between standards and tools in sbom,”ACM Transactions on Software Engineering and Methodology, 2026. [Online]. Available: https://dl.acm.org/doi/epdf/10.1145/3788692

    work page doi:10.1145/3788692 2026

  20. [20]

    Accuracy evaluation of sbom tools for web applications and system-level software,

    A. Halbritter and D. Merli, “Accuracy evaluation of sbom tools for web applications and system-level software,” inProceedings of the 19th International Conference on Availability, Reliability and Security. Vienna Austria: ACM, 2024, pp. 1–9

    2024

  21. [21]

    Sbom generation tools and formats affect compliance with us standard,

    A. R. Manzi Muneza, A. Keefe, E. O’Donoghue, C. Izurieta, and A. M. Reinhold, “Sbom generation tools and formats affect compliance with us standard,” in2025 IEEE International Conference on Soft- ware Analysis, Evolution and Reengineering - Companion (SANER-C). Montreal, QC, Canada: IEEE, 2025, pp. 81–88

    2025

  22. [22]

    A viewpoint on knowing software: Bill of materials quality when you see it,

    S. Torres-Arias, D. Geer, and J. S. Meyers, “A viewpoint on knowing software: Bill of materials quality when you see it,”IEEE Security & Privacy, vol. 21, no. 6, pp. 50–54, 2023

    2023

  23. [23]

    On the correctness of metadata- based sbom generation: A differential analysis approach,

    S. Yu, W. Song, X. Hu, and H. Yin, “On the correctness of metadata- based sbom generation: A differential analysis approach,” in2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). Brisbane, Australia: IEEE, 2024, pp. 29–36

    2024

  24. [24]

    On the accuracy of github’s dependency graph,

    D. Bifolco, S. Nocera, S. Romano, M. Di Penta, R. Francese, and G. Scanniello, “On the accuracy of github’s dependency graph,” in Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering (EASE). Salerno Italy: ACM, 2024, pp. 242–251

    2024

  25. [25]

    Technical guideline tr- 03183: Cyber resilience requirements for manufacturers and products: Part 2: Software bill of materials (sbom),

    Federal Office for Information Security, “Technical guideline tr- 03183: Cyber resilience requirements for manufacturers and products: Part 2: Software bill of materials (sbom),” 2024. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ Publications/TechGuidelines/TR03183/BSI-TR-03183-2-2_0_0.pdf

    2024

  26. [26]

    Spdx specification: Package,

    The Linux Foundation, “Spdx specification: Package,” 2024. [Online]. Available: https://spdx.github.io/spdx-spec/v3.0.1/model/ Software/Classes/Package/

    2024

  27. [27]

    Framing software component transparency: Establishing a common software bill of materials (sbom): Second edition,

    National Telecommunications and Information Administration, “Framing software component transparency: Establishing a common software bill of materials (sbom): Second edition,” 2021. [Online]. Available: https://www.ntia.gov/files/ntia/publications/ntia_ sbom_framing_2nd_edition_20211021.pdf

    2021

  28. [28]

    Sbom generation based on code-level external component trees,

    X. Kong, H. Zhuo, X. Miao, W. Huang, and J. Du, “Sbom generation based on code-level external component trees,”Scientific reports, vol. 15, no. 1, p. 45277, 2025

    2025

  29. [29]

    Cyclonedx generator (cdxgen),

    CycloneDX, “Cyclonedx generator (cdxgen),” 2017. [Online]. Available: https://github.com/CycloneDX/cdxgen

    2017

  30. [30]

    [Online]

    Anchore, “Syft,” 2020. [Online]. Available: https://github.com/anchore/ syft

    2020

  31. [31]

    [Online]

    Aquasecurity, “Trivy,” 2019. [Online]. Available: https://github.com/ aquasecurity/trivy

    2019

  32. [32]

    Oss review toolkit (ort),

    The Linux Foundation, “Oss review toolkit (ort),” 2017. [Online]. Available: https://github.com/oss-review-toolkit/ort

    2017

  33. [33]

    Microsoft sbom tool,

    Microsoft, “Microsoft sbom tool,” 2022. [Online]. Available: https: //github.com/microsoft/sbom-tool

    2022

  34. [34]

    A shared vision of software bill of materials (sbom) for cybersecurity,

    Cybersecurity and Infrastructure Security Agency, “A shared vision of software bill of materials (sbom) for cybersecurity,” 2025. [Online]. Available: https://www.cisa.gov/resources-tools/resources/ shared-vision-software-bill-materials-sbom-cybersecurity

    2025

  35. [35]

    National Institute of Standards and Technology (NIST), “Sbom,”

  36. [36]

    Available: https://csrc.nist.gov/glossary/term/sbom

    [Online]. Available: https://csrc.nist.gov/glossary/term/sbom

  37. [37]

    Survey of existing sbom formats and standards,

    National Telecommunications and Information Administration, “Survey of existing sbom formats and standards,” 2021. [Online]. Available: https://www.ntia.gov/sites/default/files/publications/sbom_ formats_survey-version-2021_0.pdf

    2021

  38. [38]

    Information technology. software asset management. software identification tag,

    International Organization for Standardization (ISO), “Information technology. software asset management. software identification tag,”

  39. [39]

    Available: https://www.iso.org/standard/65666.html

    [Online]. Available: https://www.iso.org/standard/65666.html

  40. [40]

    Cyclonedx specification overview,

    Open Web Application Security Project, “Cyclonedx specification overview,” 2025. [Online]. Available: https://cyclonedx.org/ specification/overview/

    2025

  41. [41]

    Spdx specifications,

    The Linux Foundation, “Spdx specifications,” 2023. [Online]. Available: https://spdx.dev/use/specifications/ 15

    2023

  42. [42]

    Comparing sbom standards: Spdx vs. cyclonedx,

    Sonatype, “Comparing sbom standards: Spdx vs. cyclonedx,” 2023. [Online]. Available: https://www.sonatype.com/blog/comparing-sbom- standards-spdx-vs.-cyclonedx-vs.-swid

    2023

  43. [43]

    National vulnerability database,

    Information Technology Laboratory, “National vulnerability database,”

  44. [44]

    Available: https://nvd.nist.gov/

    [Online]. Available: https://nvd.nist.gov/

  45. [45]

    The impact of sbom generators on vulnerability assessment in python: A comparison and a novel approach,

    G. Benedetti, S. Cofano, A. Brighente, and M. Conti, “The impact of sbom generators on vulnerability assessment in python: A comparison and a novel approach,” inApplied Cryptography and Network Security, ser. Lecture Notes in Computer Science, M. Fischlin and V. Moonsamy, Eds. Cham: Springer Nature Switzerland, 2025, vol. 15826, pp. 487– 509

    2025

  46. [46]

    Roles and benefits for sbom across the supply chain: Ntia multistakeholder process on software component transparency use cases and state of practice working group,

    National Telecommunications and Information Administration, “Roles and benefits for sbom across the supply chain: Ntia multistakeholder process on software component transparency use cases and state of practice working group,” 2019. [Online]. Available: https://www.ntia.gov/files/ntia/publications/ntia_sbom_use_ cases_roles_benefits-nov2019.pdf

    2019

  47. [47]

    Types of software bill of material (sbom) documents,

    Cybersecurity and Infrastructure Security Agency, “Types of software bill of material (sbom) documents,” 2023. [On- line]. Available: https://www.cisa.gov/resources-tools/resources/types- software-bill-materials-sbom

    2023

  48. [48]

    About the dependency graph,

    GitHub, Inc., “About the dependency graph,” 2025. [Online]. Available: https://docs.github.com/en/code-security/supply-chain- security/understanding-your-software-supply-chain/about-the- dependency-graph

    2025

  49. [49]

    The minimum elements for a software bill of materials (sbom),

    National Telecommunications and Information Administration, “The minimum elements for a software bill of materials (sbom),”

  50. [50]

    Available: https://www.ntia.gov/report/2021/minimum- elements-software-bill-materials-sbom

    [Online]. Available: https://www.ntia.gov/report/2021/minimum- elements-software-bill-materials-sbom

    2021

  51. [51]

    Sbom-scorecard,

    Ebay, “Sbom-scorecard,” 2022. [Online]. Available: https://github. com/eBay/sbom-scorecard

    2022

  52. [52]

    sbomqs: The comprehensive sbom quality & compliance tool,

    Interlynk, “sbomqs: The comprehensive sbom quality & compliance tool,” 2023. [Online]. Available: https://github.com/interlynk- io/sbomqs

    2023

  53. [53]

    Cyclonedx editor/validator,

    Festo SE & Co. KG, “Cyclonedx editor/validator,” 2023. [Online]. Available: https://github.com/Festo-se/cyclonedx-editor-validator

    2023

  54. [54]

    lib4sbom,

    A. Harrison, “lib4sbom,” 2023. [Online]. Available: https://github. com/anthonyharrison/lib4sbom

    2023

  55. [55]

    Sbomaudit,

    ——, “Sbomaudit,” 2023. [Online]. Available: https://github.com/ anthonyharrison/sbomaudit

    2023

  56. [56]

    Spdx tools-python,

    The Linux Foundation, “Spdx tools-python,” 2016. [Online]. Available: https://github.com/spdx/tools-python

    2016

  57. [57]

    Spdx ntia conformance checker,

    ——, “Spdx ntia conformance checker,” 2022. [Online]. Available: https://github.com/spdx/ntia-conformance-checker

    2022

  58. [58]

    Cyclonedx cli,

    CycloneDX, “Cyclonedx cli,” 2020. [Online]. Available: https: //github.com/CycloneDX/cyclonedx-cli

    2020

  59. [59]

    A landscape study of open-source tools for software bill of materials (sbom) and supply chain security,

    D. Garcia, M. T. Mirakorhli, S. Dillon, K. Laporte, M. Morrison, H. Lu, V. Koscinski, C. Enoch, M. Fazelnia, and R. Chen, “A landscape study of open-source tools for software bill of materials (sbom) and supply chain security,” in2025 IEEE/ACM 3rd International Workshop on Software Vulnerability Management (SVM). Ottawa, ON, Canada: IEEE, 2025, pp. 37–45

    2025

  60. [60]

    Cve: Glossary,

    MITRE Corporation, “Cve: Glossary,” 2026. [Online]. Available: https://www.cve.org/ResourcesSupport/Glossary

    2026

  61. [61]

    Ai copilot code quality: Evaluating 2024’s increased defect rate via code quality metrics,

    W. Harding, “Ai copilot code quality: Evaluating 2024’s increased defect rate via code quality metrics,” 2025. [Online]. Available: https://www.gitclear.com/ai_assistant_code_quality_2025_research

    2024

  62. [62]

    Hiddencpg: Large-scale vulnerable clone detection using subgraph isomorphism of code property graphs,

    S. Wi, S. Woo, J. J. Whang, and S. Son, “Hiddencpg: Large-scale vulnerable clone detection using subgraph isomorphism of code property graphs,” inProceedings of the ACM Web Conference 2022, ser. WWW ’22. New York, NY, USA: Association for Computing Machinery, 2022, p. 755–766. [Online]. Available: https://doi.org/10.1145/3485447.3512235

    work page doi:10.1145/3485447.3512235 2022

  63. [63]

    Software systems at risk: An empirical study of cloned vulnerabilities in practice,

    S. Kim and H. Lee, “Software systems at risk: An empirical study of cloned vulnerabilities in practice,”Computers & Security, vol. 77, pp. 720–736, 2018

    2018

  64. [64]

    Researchers find serious ai bugs exposing meta, nvidia, and microsoft inference frameworks,

    R. Lakshmanan, “Researchers find serious ai bugs exposing meta, nvidia, and microsoft inference frameworks,” 2025. [Online]. Available: https://thehackernews.com/2025/11/researchers- find-serious-ai-bugs.html

    2025

  65. [65]

    Large scale study of orphan vulnerabilities in the software supply chain,

    D. Reid, K. Rahkema, and J. Walden, “Large scale study of orphan vulnerabilities in the software supply chain,” inProceedings of the 19th International Conference on Predictive Models and Data Analytics in Software Engineering, ser. PROMISE 2023. New York, NY, USA: Association for Computing Machinery, 2023, p. 22–32. [Online]. Available: https://doi.org/1...

    work page doi:10.1145/3617555.3617872 2023

  66. [66]

    Security vulnerabilities in categories of clones and non-cloned code: An empirical study,

    M. R. Islam, M. F. Zibran, and A. Nagpal, “Security vulnerabilities in categories of clones and non-cloned code: An empirical study,” in2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). Toronto, ON: IEEE, 2017, pp. 20–29

    2017

  67. [67]

    Stack overflow considered harmful? the impact of copy&paste on android application security,

    F. Fischer, K. Bottinger, H. Xiao, C. Stransky, Y. Acar, M. Backes, and S. Fahl, “Stack overflow considered harmful? the impact of copy&paste on android application security,” in2017 IEEE Symposium on Security and Privacy (SP). San Jose, CA, USA: IEEE, 2017, pp. 121–136

    2017

  68. [68]

    [Online]

    Gradle, Inc., “Gradle,” 2026. [Online]. Available: https://gradle.org/

    2026

  69. [69]

    [Online]

    Python Packaging Authority, “pip,” 2025. [Online]. Available: https://pip.pypa.io/en/stable/

    2025

  70. [70]

    Composer: A dependency manager for php,

    N. Adermann and J. Boggiano, “Composer: A dependency manager for php,” 2026. [Online]. Available: https://getcomposer.org/

    2026

  71. [71]

    Go wiki: Go modules,

    Google, “Go wiki: Go modules,” 2026. [Online]. Available: https://go.dev/wiki/Modules

    2026

  72. [72]

    Gradle: Declaring versions and ranges,

    Gradle, Inc., “Gradle: Declaring versions and ranges,”

  73. [73]

    Available: https://docs.gradle.org/current/userguide/ dependency_versions.html

    [Online]. Available: https://docs.gradle.org/current/userguide/ dependency_versions.html

  74. [74]

    pip documentation: User guide,

    The pip developers, “pip documentation: User guide,” 2025. [Online]. Available: https://pip.pypa.io/en/stable/user_guide/

    2025

  75. [75]

    Poetry: Dependency specification,

    Poetry, “Poetry: Dependency specification,” 2025. [Online]. Available: https://python-poetry.org/docs/main/managing-dependencies/

    2025

  76. [76]

    Composer: Versions and constraints,

    N. Adermann and J. Boggiano, “Composer: Versions and constraints,” 2025. [Online]. Available: https://getcomposer.org/doc/ articles/versions.md

    2025

  77. [77]

    State of the software supply chain: 2026,

    Sonatype, “State of the software supply chain: 2026,” 2026. [Online]. Available: https://www.sonatype.com/state-of-the-software- supply-chain/2026/software-infrastructure-growth

    2026

  78. [78]

    Pypi stats: Analytics for pypi packages,

    Python Software Foundation, “Pypi stats: Analytics for pypi packages,”

  79. [79]

    Available: https://pypistats.org/

    [Online]. Available: https://pypistats.org/

  80. [80]

    Widespread supply chain compromise impacting npm ecosystem: Alert,

    Cybersecurity and Infrastructure Security Agency, “Widespread supply chain compromise impacting npm ecosystem: Alert,” 2025. [Online]. Available: https://www.cisa.gov/news-events/alerts/2025/09/ 23/widespread-supply-chain-compromise-impacting-npm-ecosystem

    2025

Showing first 80 references.