Pith. sign in

REVIEW 3 major objections 5 minor 47 references

No Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the Wild

T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

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

Pith's one-line read Most published SBOMs lack the dependency graph that vulnerability triage depends on, and consumers who treat missing edges as 'unreachable' measurably lose known-exploited vulnerabilities; reinterpreting silence as 'unknown' recovers them.

desk verdict The census is the contribution; the recall-recovery is an honest, in-sample demo—send it out but require artifacts and a replication. read the letter →

arxiv 2607.22140 v1 pith:SMTZV5WV submitted 2026-07-24 cs.SE cs.CR

Artur Zięba-Kozarzewski This is my paper · ORCID
classification cs.SEcs.CR
keywords SBOMdependencygraphreachabilityclosed-worldassumptionopen-worldsemanticsvulnerabilityprioritizationorphanratiosoftwaresupplychain
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

This paper tries to establish that the dependency graph an SBOM declares is often absent or degenerate, and that this absence is not benign. Scanning 78,612 real-world SBOM files, the author finds three regimes: about 53% declare no dependency edges at all, about 9% declare edges but leave most components isolated, and only about 38% form well-connected graphs. Whether edges appear is set by the generating tool, not by the software being described, and the specification's own mechanism for declaring incompleteness is used by 0.1% of documents. The author then argues that the common consumer inference 'no path means unreachable' is an unsound closed-world conclusion drawn from an incomplete artifact, and demonstrates in a production vulnerability-prioritization system that replacing the veto with an explicit 'unknown' level, guarded by a simple degeneracy detector, recovers known-exploited-vulnerability recall from 0.600 to 0.950 without alert flooding. The paper reports the recall effect as directional with a documented mechanism, not as a significance test.

What carries the argument

The central object is the declared graph G(S) = (V, E) of an SBOM and the orphan ratio ρ(S), the share of components with no declared edges. The orphan ratio induces a three-way taxonomy (no dependency block, degenerate-with-edges, connected) whose boundary at ρ = 0.5 is threshold-insensitive because the population's distribution has a near-empty valley between the two modes. This detector decides when the graph is too uninformative to support the closed-world 'no path ⇒ unreachable' inference; in that regime, missing edges are remapped to an explicit 'unknown' level rather than a veto. The asymmetry that carries the argument is that declared edges are trustworthy while absent edges are not,

What would settle it

Expand the ground-truth set to hundreds of known-exploited instances across many SBOMs and rerun the controlled comparison: if the recall difference between closed- and open-world scoring shrinks to statistical noise, the claim that the closed-world veto caused the misses is refuted.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that the declared dependency graph is not a reliable substrate for reachability reasoning. In a census of 77,092 parseable SBOMs, 52.9% contain no dependency block at all—failing the US federal minimum-elements requirement for dependency relationships—and among the 36,336 that do, the orphan-ratio distribution is bimodal: a connected mode, a degenerate mode (median 93% isolated components among large documents), and a near-empty valley. A consumer-style scan of 11 large container images lands squarely in the degenerate mode at 95–98% orphans. Because declared edges are almost always true but absent edges are not evidence of independence, the pap

Load-bearing premise

The 18-SBOM production testbed with 2,180 unique CVEs and 20 known-exploited ground-truth instances is representative enough that the measured recall recovery (0.600→0.950) is caused by the open-world semantics rather than by the particular sample.

Editorial extensions

If this is right

  • Consumers who multiply reachability into vulnerability scores are converting missing data into confident negative verdicts; in the measured production system, seven of eight missed known-exploited instances were orphan cases zeroed by the veto.
  • Field-oriented SBOM quality scores do not detect the absence: documents with no edges and well-connected documents score within 0.1 on a ten-point scale, so quality gates should score the graph itself.
  • Producers can move SBOMs between regimes cheaply—resolving against lockfiles instead of manifests drops the degenerate share from roughly 39% (Python) to about 1% (Composer), and a one-line completeness declaration converts silent incompleteness into machine-readable uncertainty.
  • In degenerate image scans, filtering orphan components before centrality computation preserves exact results while cutting runtime by 200–4000×; any graph-based component ranking must handle the isolated mass explicitly.
  • The regime split is stable: 52.9% of published SBOMs fail the mandatory dependency-relationships field, so any compliance or assurance workflow that assumes a usable graph is operating on a minority of documents.

Reading between the lines

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

  • Beyond the paper, the same closed-world fallacy likely extends to the component list itself: an SBOM that omits a file is analogous to one that omits edges, so consumers should apply the same open-world 'unknown' treatment to component enumeration, not just reachability.
  • Because edge emission is toolchain-determined, a consumer who knows the generating tool can predict the regime a priori; a testable extension is routing semantics by generator identity rather than by parsing the graph, which could make the open-world handling cheaper and more reliable.
  • The paper's production testbed is small; the natural generalization—which the author lists as future work—is replaying the open-world scoring on a stratified sample of the public corpus. Our guess is the effect will persist in degenerate documents but shrink in the connected regime, where the veto is legitimate.
  • If completeness declarations become mandatory and machine-checkable, the graph-quality dimension could be folded into existing quality gates, making the open-world default unnecessary in the long run; that would be a regulatory, not technical, fix.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper presents the first large-scale census of declared dependency-graph topology in SBOMs, scanning all 78,612 files of the Wild SBOMs corpus (77,092 parseable) with a streaming analyzer. It reports three regimes: 52.9% of parseable SBOMs declare no dependency edges at all; 8.8% declare a dependency block but with most components isolated (median orphan share 93% among large degenerate SBOMs); and 38.3% form a connected regime. Edge emission varies strongly with the generating tool, the CycloneDX compositions completeness declaration is used by only 0.10% of documents, and sbomqs quality scores do not distinguish edge-less from connected SBOMs. The paper argues that closed-world inference ('no path implies unreachable') is unsound in the first two regimes, and reports a production case study in which replacing the reachability veto with an 'unknown' level, guarded by an orphan-ratio degeneracy detector, raised KEV recall from 0.600 to 0.950 in controlled re-scoring (0.957 live) without alert flooding. The paper releases the scanner and per-SBOM topology dataset.

Significance. The population census is a substantial and timely contribution. Measuring the declared graph—not just field presence—across the full Wild SBOMs corpus directly quantifies an implicit assumption made by reachability-based SBOM consumers: that the SBOM's edge set approximates the true dependency graph. The finding that 52.9% of public SBOMs omit dependency relationships entirely, and that another 8.8% have a degenerate graph, is an important, falsifiable result. Methodological strengths include the full census rather than a sample, deterministic streaming scanner, two independent full scans with bit-identical results, threshold-insensitivity analysis, and public release of the scanner and derived dataset. The open-world semantics argument is well grounded in soundiness and closed-world-assumption literature. The recall-recovery case study is useful as a documented mechanism, but as the paper itself acknowledges, it is a single-site, small-sample, in-sample demonstration; its status as a 'validated consequence' is weaker than the population-level claims.

major comments (3)
  1. [Abstract / §VI / Contribution C3] The headline claim 'recovered KEV recall from 0.600 to 0.950' is presented in the abstract and contribution C3 as a validated consequence, but §VI explicitly states this is 'a directional effect with a documented mechanism rather than a significance test.' The evidence is an in-sample evaluation on 18 SBOMs with 20 KEV ground-truth instances, using the same frozen snapshot on which the intervention was designed after observing the failures. The Wilson 95% intervals overlap (0.600:[0.39,0.78]; 0.950:[0.76,0.99]). The abstract and C3 must either be supported by a pre-specified independent validation or be downgraded to 'directional evidence with a documented mechanism.' The population-level normative argument survives without this testbed, but the practical urgency of the open-world fix does not rest on 20 instances.
  2. [§IV, Table II, RQ2] The claim that 'Edge emission is determined by the generator, not the described software' is stronger than the observational data support. Table II shows strong variation across generators, but generator is confounded with ecosystem and input style; the paper's own ecosystem gradient (pypi 38.8% degenerate vs. composer ~1%, and the lockfile distinction in Section IV) shows this. The data are consistent with 'generator and input style jointly determine edge emission,' not with 'determined by the generator' as a causal statement. Please reword to 'varies strongly with/associated with the generator' or provide a controlled comparison (e.g., same project scanned by multiple tools) before making a causal claim that later feeds the toolmaker recommendation in Section VII.
  3. [§VI, fix and validation] The controlled re-scoring does not isolate the contribution of the degeneracy detector or the specific threshold τ=0.5. Since all 7 missed KEV instances were orphan×multiplicative-zero cases, assigning any positive 'unknown' factor to orphans in degenerate graphs recovers them almost by construction; the detector's role is only volume control. The paper reports a single configuration (τ=0.5, unknown factor 0.5). To support the claim that the detector, rather than the nonzero factor alone, is load-bearing, please report a sensitivity analysis (e.g., τ=0 meaning factor applied to all orphans, τ=1 meaning factor applied only to empty-block documents) with the corresponding recall and flooding numbers, or explicitly frame the detector as a volume-preserving device and not part of the recall effect.
minor comments (5)
  1. [Contributions / §VI] Align language: C3 calls the recall recovery 'validated consequence,' but §VI says 'directional effect ... rather than a significance test.' The abstract should carry the same caveat as the body.
  2. [Fig. 1 caption] The caption's explanation of the exactly-ρ=0.5 bin is confusing. Clarify that the bar for [0.5,0.6) includes the 215 documents at ρ=0.5, which are classified as connected under the strict ρ>τ rule, and that this is why the displayed bars from 0.5 upward sum to more than the degenerate-class size.
  3. [§IV / Table I] 'Well-connected' for the connected regime (ρ≤0.5) may overstate the case; some documents in this class have half their components isolated. Consider 'connected regime' or report the E/V distribution alongside the orphan ratio.
  4. [§VI] The live evaluation uses 23 KEV instances while the offline evaluation uses 20; state explicitly why the denominator changes (snapshot timing). Also report precision or F1 in addition to recall and volume increase, since alert flooding is only a proxy for precision.
  5. [§II] Typo: 'CW A' should be 'CWA' (closed-world assumption).

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; recall recovery is guarded by KEV ablation and explicitly caveated as directional.

full rationale

The paper's central derivation is a population census: parsing 77,092 SBOMs and computing V, E/V, orphan ratios is direct measurement against an external corpus (Wild SBOMs), with reproducibility checked by two independent scans. The taxonomy (Eq. 2) is a definition, not a derived prediction; the threshold tau=0.5 is justified by the measured valley in the orphan-ratio distribution. The strongest candidate for circularity is the RQ4/RQ5 recall-recovery claim, but the paper explicitly removes the KEV signal from scoring before measuring recall: 'the KEV signal is removed from scoring entirely, so the floor never activates and any recall change is attributable to the open-world semantics (i) alone,' which breaks the otherwise automatic link between the metric and the fix. The remaining concerns — the 18-SBOM/20-instance testbed, in-sample intervention, overlapping Wilson intervals — are generalization/validity limitations that the paper itself labels as 'a directional effect with a documented mechanism rather than a significance test'; they do not reduce the derivation to its inputs by construction. There are no self-citations used as load-bearing evidence, no imported uniqueness theorem, and no ansatz smuggled in via citation. Therefore no circular step is established.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical/formal entities. The 'unknown reachability level' is a scoring category, not an entity. Free parameters are limited to the degeneracy threshold, the 0.5 unknown factor, and the flooding guardrail; these are operational choices rather than fitted scientific constants. The main assumptions are domain-level (trust in declared edges, corpus representativeness) and standard logic (closed-world semantics).

free parameters (3)
  • orphan-ratio threshold τ = 0.5
    Chosen to classify NO_EDGES/degenerate/connected and to trigger the open-world semantics. The paper shows the near-empty valley (2.8% in 0.5–0.8) makes the classification insensitive (moving to 0.6 reclassifies 302 of 36,336 SBOMs), but it is still a hand-chosen cut.
  • unknown reachability factor = 0.5
    Multiplicative factor applied to orphan components when a graph is flagged degenerate in the production re-scoring. Not tuned against KEV labels; chosen as an operational middle value between 'reachable' (1) and 'unreachable' (0).
  • flooding guardrail volume increase = 15%
    Alert-volume increase cap used to show the recall recovery was not from indiscriminate up-scoring. An ad hoc operational bound, not derived from data.
assumptions (4)
  • domain assumption Declared edges are trustworthy: extractors transcribe manifests and do not invent dependencies
    Underpins the asymmetric-soundness argument that a missing edge is not evidence of independence. Introduced in Section VI via the soundiness manifesto [5] and applied throughout; if extractors can invent edges, the whole 'closed-world is unsound because missing edges are the only problem' framing weakens.
  • domain assumption Wild SBOMs corpus is representative of consumer-visible SBOMs
    The population-level regime shares (52.9% NO_EDGES etc.) generalize only if repository-committed SBOMs resemble what consumers actually hold. The author acknowledges this threat in Section III and notes container image scans are under-represented, which is why the 11-image corpus was added.
  • standard math Closed-world assumption semantics (Reiter) applies to SBOM graph queries
    Formalizes why 'no path ⇒ unreachable' is unsound unless the relation is complete; standard logic background cited as [6].
  • domain assumption NTIA minimum elements require dependency relationships
    Treats an SBOM without edges as failing a required baseline element; framing from reference [1].

how reviews work

0 comments
Cite this review

Pith. "Pith review of No Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the Wild." pith.science (2026). https://pith.science/paper/SMTZV5WV

@misc{pith2026260722140,
  author       = {Pith},
  title        = {Pith review of: No Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the Wild},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SMTZV5WV}},
  note         = {Machine review of arXiv:2607.22140}
}
read the original abstract

Software Bills of Materials (SBOMs) are consumed not only as component inventories but as dependency graphs: vulnerability triage, reachability filtering, and impact analysis all traverse the edges an SBOM declares. We present the first large-scale characterization of the declared dependency graph across 78,612 real-world SBOM files from the Wild SBOMs dataset (77,092 parseable). We find that the population splits into three regimes: 52.9% of SBOMs declare no edges at all (failing the NTIA minimum-elements requirement of dependency relationships), 8.8% declare a dependency block yet leave the majority of components isolated (degenerate regime; among such SBOMs with at least 50 components the median orphan share is 93%, and our 11 Syft-generated container-image SBOMs fall in this regime at 95-98% orphans), and 38.3% form well-connected graphs. Edge emission is determined by the generator, not the described software (0%-100% no-edge rates across tools), and the specification-level mechanism for declaring graph incompleteness (CycloneDX compositions) is used by 0.10% of the population. We argue that in the first two regimes, the common consumer inference "no path implies unreachable" is an unsound closed-world conclusion drawn from a demonstrably incomplete artifact; in a production vulnerability-prioritization system, replacing the resulting veto with an explicit "unknown" level guarded by a degeneracy detector recovered KEV recall from 0.600 to 0.950 (controlled re-scoring; 0.957 in a live end-to-end run) without alert flooding. We release our streaming scanner and the full per-SBOM topology dataset.

Figures

Figures reproduced from arXiv: 2607.22140 by the authors.

Figure 1
Figure 1. Orphan-ratio distribution over the block-declaring subpopulation: a [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 2 linked inside Pith

  1. [1]

    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),” United States Department of Commerce, Tech. Rep., 2021, pursuant to Execu- tive Order 14028

    2021

  2. [2]

    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, to appear. arXiv:2601.05622

    arXiv 2026

  3. [3]

    Software dark mat- ter: Gazing at uncharted files to navigate SBOM integrations,

    A. Reddypalle, D. Roellke, and S. Torres-Arias, “Software dark mat- ter: Gazing at uncharted files to navigate SBOM integrations,” 2026, preprint

    2026

  4. [4]

    Wild SBOMs: a large-scale dataset of software bills of materials from public code,

    L. Soeiro, T. Robert, and S. Zacchiroli, “Wild SBOMs: a large-scale dataset of software bills of materials from public code,” inProceedings of the 22nd International Conference on Mining Software Repositories (MSR), Data and Tool Showcase, 2025, dataset: https://doi.org/10.5281/ zenodo.14250103. arXiv:2503.15021

    arXiv 2025

  5. [5]

    In defense of soundiness: A manifesto,

    B. Livshits, M. Sridharan, Y . Smaragdakis, O. Lhoták, J. N. Amaral, B.- Y . E. Chang, S. Z. Guyer, U. P. Khedker, A. Møller, and D. Vardoulakis, “In defense of soundiness: A manifesto,”Communications of the ACM, vol. 58, no. 2, pp. 44–46, 2015

    2015

  6. [6]

    On closed world data bases,

    R. Reiter, “On closed world data bases,” inLogic and Data Bases. Plenum Press, 1978, pp. 55–76

    1978

  7. [7]

    CycloneDX bill of materials specification, version 1.6 — compositions,

    OW ASP Foundation, “CycloneDX bill of materials specification, version 1.6 — compositions,” https://cyclonedx.org/use-cases/ compositions-dependencies/, 2024

    2024

  8. [8]

    Executive order 14028: Improving the nation’s cybersecurity,

    The White House, “Executive order 14028: Improving the nation’s cybersecurity,” Federal Register 86 FR 26633, 2021

    2021

Show all 47 references
  1. [9]

    Regulation (eu) 2024/2847 on hor- izontal cybersecurity requirements for products with digital elements (cyber resilience act),

    European Parliament and Council, “Regulation (eu) 2024/2847 on hor- izontal cybersecurity requirements for products with digital elements (cyber resilience act),” 2024, SBOM requirement: Annex I, Part II

    2024

  2. [10]

    Framing software component transparency: Establishing a com- mon software bill of materials (SBOM),

    CISA, “Framing software component transparency: Establishing a com- mon software bill of materials (SBOM),” Cybersecurity and Infrastruc- ture Security Agency, Tech. Rep., 2024, third Edition

    2024

  3. [11]

    Automated SBOM-driven vulnerability triage for IoT firmware: A lightweight pipeline for risk prioritization,

    A. Tolay, “Automated SBOM-driven vulnerability triage for IoT firmware: A lightweight pipeline for risk prioritization,” 2026

    2026

  4. [12]

    Exploit prediction scoring system (EPSS),

    J. Jacobs, S. Romanosky, B. Edwards, I. Adjerid, and M. Roytman, “Exploit prediction scoring system (EPSS),”Digital Threats: Research and Practice, vol. 2, no. 3, 2021

    2021

  5. [13]

    Con- flicting scores, confusing signals: An empirical study of vulnerability scoring systems,

    V . Koscinski, M. Nelson, A. Okutan, R. Falso, and M. Mirakhorli, “Con- flicting scores, confusing signals: An empirical study of vulnerability scoring systems,” 2025

    2025

  6. [14]

    Efficacy of EPSS in high severity CVEs found in KEV,

    R. Parla, “Efficacy of EPSS in high severity CVEs found in KEV,” 2024

    2024

  7. [15]

    Towards predicting multi-vulnerability attack chains in software supply chains from software bill of materials graphs,

    L. Baird and A. Moin, “Towards predicting multi-vulnerability attack chains in software supply chains from software bill of materials graphs,” 2026, fSE 2026 IVR track

    2026

  8. [16]

    The ripple effect of vul- nerabilities in Maven Central: Prevalence, propagation, and mitigation challenges,

    E. Ul Haq, S. Wang, and R. S. Allison, “The ripple effect of vul- nerabilities in Maven Central: Prevalence, propagation, and mitigation challenges,” 2025

    2025

  9. [17]

    Out of sight, still at risk: The lifecycle of transitive vulnerabilities in Maven,

    P. Przymus, M. Fejzer, J. Nar˛ ebski, K. Rykaczewski, and K. Stencel, “Out of sight, still at risk: The lifecycle of transitive vulnerabilities in Maven,” 2025

    2025

  10. [18]

    Tracing vulnerabilities in Maven: A study of CVE lifecycles and dependency networks,

    C. Yang-Smith and A. Abdellatif, “Tracing vulnerabilities in Maven: A study of CVE lifecycles and dependency networks,” 2025

    2025

  11. [19]

    Propagation- based vulnerability impact assessment for software supply chains,

    B. Ruan, Z. Lin, J. Liu, C. Zhang, K. Ji, and Z. Liang, “Propagation- based vulnerability impact assessment for software supply chains,” 2025

    2025

  12. [20]

    Vulnerable open source dependencies: Counting those that matter,

    I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vulnerable open source dependencies: Counting those that matter,” in ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2018

    2018

  13. [21]

    Vuln4Real: A methodology for counting actually vulnerable dependencies,

    ——, “Vuln4Real: A methodology for counting actually vulnerable dependencies,”IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1592–1609, 2022

    2022

  14. [22]

    Backstabber’s knife collection: A review of open source software supply chain attacks,

    M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” inDetection of Intrusions and Malware, and Vulnerability Assessment (DIMVA), ser. LNCS, vol. 12223, 2020

    2020

  15. [23]

    SoK: Taxonomy of attacks on open-source software supply chains,

    P. Ladisa, H. Plate, M. Martinez, and O. Barais, “SoK: Taxonomy of attacks on open-source software supply chains,” inIEEE Symposium on Security and Privacy (S&P), 2023, arXiv:2204.04008

    2023 arXiv

  16. [24]

    Small world with high risks: A study of security threats in the npm ecosystem,

    M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in 28th USENIX Security Symposium, 2019, arXiv:1902.09217

    2019 arXiv

  17. [25]

    Syft: CLI tool and library for generating a software bill of materials from container images and filesystems,

    Anchore, Inc., “Syft: CLI tool and library for generating a software bill of materials from container images and filesystems,” https://github.com/ anchore/syft, 2024, version 1.42, accessed 2026-07

    2024

  18. [26]

    sbomqs: Quality metrics for SBOMs,

    Interlynk, “sbomqs: Quality metrics for SBOMs,” https://github.com/ interlynk-io/sbomqs, 2024, accessed 2026-07

    2024

  19. [27]

    A study of security vulnerabilities on Docker Hub,

    R. Shu, X. Gu, and W. Enck, “A study of security vulnerabilities on Docker Hub,” inACM Conference on Data and Application Security and Privacy (CODASPY), 2017

    2017

  20. [28]

    On the relation between outdated docker containers, severity vulnerabilities, and bugs,

    A. Zerouali, T. Mens, G. Robles, and J. M. Gonzalez-Barahona, “On the relation between outdated docker containers, severity vulnerabilities, and bugs,” inIEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2019

    2019

  21. [29]

    A faster algorithm for betweenness centrality,

    U. Brandes, “A faster algorithm for betweenness centrality,”Journal of Mathematical Sociology, vol. 25, no. 2, pp. 163–177, 2001

    2001

  22. [30]

    SBOMproof: Beyond alleged SBOM compliance for supply chain security of container images,

    J. Bufalino, M. Di Francesco, A. Blaise, and S. Secci, “SBOMproof: Beyond alleged SBOM compliance for supply chain security of container images,” 2025, preprint

    2025

  23. [31]

    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,” 2024, preprint

    2024

  24. [32]

    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 (ARES), 2024

    2024

  25. [33]

    The state of the SBOM tool ecosystems: A comparative analysis of SPDX and CycloneDX,

    Z. Zhao, A. A. Bangash, T. Ge, A. Singh, Z. Wang, and B. Adams, “The state of the SBOM tool ecosystems: A comparative analysis of SPDX and CycloneDX,” 2025

    2025

  26. [34]

    A landscape study of open source and proprietary tools for software bill of materials (SBOM),

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

    2024

  27. [35]

    Supply chain insecurity: The lack of integrity protection in SBOM solutions,

    C. Ozkan, X. Zou, and D. Singelee, “Supply chain insecurity: The lack of integrity protection in SBOM solutions,” 2024

    2024

  28. [36]

    A reality check on SBOM- based vulnerability management: An empirical study and a path for- ward,

    L. Zhou, M. Dacier, and C. Konstantinou, “A reality check on SBOM- based vulnerability management: An empirical study and a path for- ward,” 2025, preprint

    2025

  29. [37]

    Software bills of materials in Maven Central,

    Y . Gamage, N. Gonzalez Fernandez, M. Monperrus, and B. Baudry, “Software bills of materials in Maven Central,” inProceedings of the 22nd International Conference on Mining Software Repositories (MSR), 2025, arXiv:2501.13832

    2025

  30. [38]

    SBOM dataset from 100 000+ public GitHub repositories,

    A. Chaora, “SBOM dataset from 100 000+ public GitHub repositories,” Zenodo, 2025

    2025

  31. [39]

    Soft- ware bill of materials in software supply chain security: A systematic literature review,

    E. O’Donoghue, Y . Hastings, E. Ortiz, and A. R. Manzi Muneza, “Soft- ware bill of materials in software supply chain security: A systematic literature review,” 2025

    2025

  32. [40]

    An empirical comparison of dependency network evolution in seven software packaging ecosystems,

    A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019

    2019

  33. [41]

    Structure and evolution of package dependency networks,

    R. Kikas, G. Gousios, M. Dumas, and D. Pfahl, “Structure and evolution of package dependency networks,” inProceedings of the 14th Interna- tional Conference on Mining Software Repositories (MSR), 2017

    2017

  34. [42]

    Structural and connectiv- ity patterns in the Maven Central dependency network,

    D. Ogenrwot, J. Businge, and S. Arifuzzaman, “Structural and connectiv- ity patterns in the Maven Central dependency network,” 2025, preprint

    2025

  35. [43]

    On the impact of outdated and vulnerable JavaScript pack- ages in Docker images,

    A. Zerouali, V . Cosentino, T. Mens, G. Robles, and J. M. Gonzalez- Barahona, “On the impact of outdated and vulnerable JavaScript pack- ages in Docker images,” inIEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2019

    2019

  36. [44]

    Beyond metadata: Code- centric and usage-based analysis of known vulnerabilities in open-source software,

    S. E. Ponta, H. Plate, and A. Sabetta, “Beyond metadata: Code- centric and usage-based analysis of known vulnerabilities in open-source software,” inProceedings of the IEEE International Conference on Software Maintenance and Evolution (ICSME), 2018, eclipse Steady

    2018

  37. [45]

    A comparative study of vulner- ability reporting by software composition analysis tools,

    N. Imtiaz, S. Thorn, and L. Williams, “A comparative study of vulner- ability reporting by software composition analysis tools,” 2021, eSEM 2021

    2021

  38. [46]

    Hidden dependencies and component variants in SBOM-based software composition analysis,

    S. Rasheed, M. McPhee, L. Patterson, S. MacDonell, and J. Dietrich, “Hidden dependencies and component variants in SBOM-based software composition analysis,” 2026, preprint

    2026

  39. [47]

    Judge: Identifying, understanding, and evaluating sources of unsoundness in call graphs,

    M. Reif, F. Kübler, M. Eichberg, D. Helm, and M. Mezini, “Judge: Identifying, understanding, and evaluating sources of unsoundness in call graphs,” inProceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2019

    2019

Pith tools

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