Pith. sign in

REVIEW 4 major objections 5 minor 20 references

VDGraph: A Graph-Theoretic Approach to Unlock Insights from SBOM and SCA Data

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read VDGraph merges SBOM and SCA outputs into a single queryable graph in which every vulnerability is reachable from the project root, revealing concentrated risk points and a skewed depth distribution of vulnerabilities.

desk verdict A practical, honest SBOM-SCA graph integration with real empirical observations, but the validation is thin and the dependency-scope configuration should be reported. read the letter →

arxiv 2507.20502 v1 pith:XJISG5WU submitted 2025-07-28 cs.SE cs.CR

Howell Xia , Jonah Gluck , Sevval Simsek , David Sastre Medina , David Starobinski This is my paper
classification cs.SEcs.CR
keywords softwarebillofmaterialscompositionanalysisknowledgegraphdependencytransitivedependenciesvulnerabilitypropagationCypherqueriesJavaMavenecosystem
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

VDGraph is a graph-theoretic method for merging a project's SBOM dependency data with its SCA vulnerability report into a single labeled property graph whose nodes are the root project, components, and vulnerabilities. The central technical claim is that the merged graph is complete (every component and vulnerability from both sources appears) and root-reachable (every vulnerability can be traced back to the project root through dependency edges), so queries can expose relationships flat SCA reports hide. On 21 Maven-based Java projects, the two demonstration queries show that certain vulnerable library versions are concentrated risk points—one is reachable via over 150,000 dependency paths—and that vulnerabilities predominate at dependency depth three or more, with no direct one-hop vulnerable components. If correct, the method gives developers a queryable view for prioritizing patches by reachability and depth rather than severity alone.

What carries the argument

The central object is the labeled property graph G = (V, E, L_V, L_E), with vertex labels root, component, vulnerability and edge labels depn (dependency) and has_v (has vulnerability). It is built by Algorithm 1, which initializes G with G_SBOM, then merges each SCA component into the graph by matching name and version (or attaches unmatched components directly to the root), and finally links vulnerability vertices. This construction is what makes the two proved properties—completeness and root-reachability—hold, and those properties in turn license the two demonstration queries: counting distinct root-to-component paths (Cypher query in Listing 3) and computing shortest root-to-vulnerability path lengths (Listing 4).

What would settle it

Apply the same pipeline to the same 21 SBOMs with a second SCA tool backed by a different vulnerability database (for example, one that flags a direct first-level dependency as vulnerable or that fails to flag protobuf-java 2.5.0). If the recomputed depth distribution shows a substantial share of vulnerabilities at depths one or two, or the top risk-point components change, the paper's central empirical conclusions are refuted.

Watch

Extended reading notes

Core claim

The paper claims that combining the dependency subgraph built from a CycloneDX SBOM with the vulnerability subgraph produced by OSV-Scanner yields a graph G for which it proves two properties: completeness (everything in the SBOM and SCA outputs is represented) and reachability (from the root project vertex there is a path to every vulnerability vertex). The construction is Algorithm 1, which merges vertices whose name-version identifiers match and, when no match exists, attaches the SCA component directly to the root to preserve completeness. On the 21-project evaluation, Query 1 (counting distinct root-to-vulnerable-component paths) finds high-severity components such as protobuf-java 2.5.0 reachable through more than 150,000 paths, and Query 2 (shortest root-to-vulnerability path length) finds a depth distribution in which 74.0% of vulnerabilities lie at four or fewer hops and 69.7% of high/critical ones do, while no vulnerability sits one hop from the root. The authors interpret this as evidence that exposure concentrates in deep transitive layers that direct-dependency scanning underweights.

Load-bearing premise

The empirical findings treat OSV-Scanner's output as ground truth for which component versions are vulnerable, without cross-validation against another SCA tool or curated vulnerability dataset; if that tool misses or misattributes vulnerabilities, the depth distribution and risk-point rankings could change.

Editorial extensions

If this is right

  • Patch prioritization can use reachability counts: a moderate-severity library behind thousands of paths may warrant attention before a high-severity one behind a single path.
  • SCA alerts gain a dependency-chain context, so a vulnerable transitive component can be traced back to the exact chain that imports it.
  • Scanning strategies should not stop at direct and secondary dependencies, since the measured vulnerability density is lowest at those shallow depths and highest at depth three and beyond.
  • The same graph supports arbitrary future queries—shortest paths, shared dependencies, or ecosystem-level aggregation—without rerunning the merge.
  • The merge runs in seconds per project on a laptop, so the pipeline can be automated across many Maven projects.

Reading between the lines

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

  • Aggregating path counts across the whole Maven ecosystem could produce a library-level 'exposure rank' that the paper does not compute, and which would be a direct extension of Query 1.
  • Because the paper adopts a conservative propagation model (any dependent inherits the vulnerability), the depth distribution is an upper bound on real exploitable exposure; combining the graph with call-graph reachability would likely push vulnerable depths even deeper.
  • The 127 colliding name-version identifiers across 4,316 entries suggest that switching to purl- or CPE-based matching would reduce merge errors, a testable improvement over the current heuristic.
  • A re-run with a second SCA tool using a different vulnerability database would show whether the 'depth three-plus' concentration is a property of the ecosystem or an artifact of OSV coverage.
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

4 major / 5 minor

Summary. The paper introduces VDGraph, a labeled-property-graph methodology that merges SBOM dependency data with SCA vulnerability data into a single queryable graph. The authors formalize the graph schema, present Algorithm 1 for merging an SBOM subgraph with an SCA forest, and prove two properties: completeness (all SBOM and SCA vertices/edges are preserved) and reachability (every vulnerability vertex is reachable from the root). They implement the approach using the CycloneDX Maven plugin, OSV-Scanner, and Neo4j, and evaluate it on 21 Maven-based Java projects. Two Cypher queries are defined: one counts dependency paths from the root to vulnerable components of high severity, and one computes the shortest path length from the root to each vulnerability. The evaluation reports concentrated risk points, such as protobuf-java_2.5.0 being reachable via over 150,000 paths in flink, and a depth distribution in which most vulnerabilities appear at depth three or deeper.

Significance. If the empirical findings are validated, VDGraph offers a useful and practical integration of SBOM and SCA outputs, enabling queries that flat SCA reports do not support, such as enumerating dependency paths to vulnerable components and measuring vulnerability depth. The formal properties are correct but follow almost directly from the algorithm's construction; their value is mainly in making explicit the guarantees the graph provides. The paper also contributes a working proof-of-concept pipeline, concrete Cypher queries, and a reproducible automation workflow built on open formats and tools. The main significance lies in the empirical observations about concentrated risk points and the depth distribution of vulnerabilities, but these observations are currently tied to a single SCA tool and an undocumented dependency-scope configuration, so their generality is not yet established.

major comments (4)
  1. [Section V and Section IV-A] The central empirical claims—the risk-point rankings in Figure 3, the depth distribution in Figure 4, and the 150,000-path count for protobuf-java_2.5.0—are computed entirely from OSV-Scanner's output and the OSV database, with no cross-validation against another SCA tool or an independently curated vulnerability dataset. The paper itself cites Sharma et al. [6] showing that SCA tools using different databases report different vulnerabilities, so the findings could be tool-specific. Please add at least one independent SCA tool or a NVD/GHSA-based verification and report the overlap and disagreement in detected vulnerabilities, or explicitly temper the conclusions to OSV-Scanner's coverage.
  2. [Section IV-A and Section V-B/V-C] The manuscript never reports Maven dependency-scope filtering during SBOM generation with the CycloneDX Maven plugin. Depending on the plugin configuration, test-, provided-, and optional-scope dependencies can be included in the SBOM, and those edges would then be part of the graphs over which path counts and depths are computed. If test-scope edges are present, the depth distribution in Figure 4 and the large path counts in Figure 3 measure build/test dependencies rather than production reachability. This is a structural over-approximation distinct from the semantic over-approximation acknowledged in Section VI. Please state the exact CycloneDX Maven plugin configuration used, and either filter to compile/runtime scopes or provide evidence that the reported results are insensitive to scope inclusion.
  3. [Section V] The evaluation is based on 21 projects selected by a 'modified version' of Balliu et al. [9]'s criteria, but the modifications are not justified and no sensitivity analysis is provided. The aggregate depth-distribution claims (e.g., 74.0% of vulnerabilities within four hops, no one-hop vulnerabilities) are presented without per-project breakdowns, confidence intervals, or statistical tests. Given the small and possibly non-representative sample, the claim that 'vulnerabilities predominantly emerge at a depth of three dependency levels or higher' needs robustness checks, such as per-project distributions and a bootstrap or permutation analysis, before it can be stated as a general property of Maven projects.
  4. [Section III-D, Proposition 2] The proof of reachability relies on the assumption that every component in the SBOM subgraph is reachable from the root, but this assumption is never verified for the generated SBOMs. If the CycloneDX Maven plugin emits components that are not connected to the root by dependency edges, or if OSV-Scanner reports a component absent from the SBOM's reachable set, the reachability property could fail. The manuscript should either verify acyclicity and root-reachability for all 21 SBOMs or state and justify the assumption more carefully. Relatedly, Section IV-D says the no-match case 'never occurs' in the implementation, which means the completeness-preserving fallback in Algorithm 1 lines 8-9 is never exercised; this should be acknowledged as a limitation of the evaluation.
minor comments (5)
  1. [Section V-C] The text says developers can 'unitize more secure components'; this should read 'utilize'.
  2. [Section II] 'discuses' should be 'discusses', and the author list of reference [9] is attributed to 'Balliu et al.' but the cited work is by Soto-Valero et al.; please correct the in-text attribution.
  3. [Section III-A and Section IV-F] The ontology defines the dependency edge label as 'depn', but Listing 3 uses ':dependency' and Listing 4 uses an unlabeled relationship. Please align the Cypher queries with the formal edge labels.
  4. [Section IV-D] The statement that an unmatched OSV-Scanner component 'never occurs' contradicts the example in Figure 2(b), where woodstox-core is attached directly to the root; please clarify that this is a hypothetical illustration and not an observed case.
  5. [Section III-E and Listing 3] Query 1 counts all paths from the root to a component using an unbounded-length pattern. If the SBOM dependency graph contains cycles, this count may be infinite or ill-defined; please state whether cycles were observed and, if so, how the query avoids counting paths with repeated vertices.

Circularity Check

0 steps flagged · score 2.0 of 10

No load-bearing circularity; the formal properties are definitional but harmless, and the sole author-overlapping citation is background only.

full rationale

The derivation chain in VDGraph is not a fitted model that predicts its own inputs. Algorithm 1 explicitly merges GSBOM and GSCA, and Propositions 1 and 2 simply restate the effect of that construction: every SBOM/SCA vertex and edge is copied in, and every vulnerability is connected to a component that is either in the SBOM or attached to the root. These are definitional correctness statements, not empirical predictions, and they are not used to justify the paper's headline measurements. Query 1 and Query 2 are executed as graph queries over the constructed graph, so the path counts and shortest-path depths are measured outputs, not quantities fitted from a subset of the same data. No parameter is calibrated and no related quantity is predicted from a fitted constant. The only self-citation is Sharma et al. [6], which includes three of the present authors; it is used in the Introduction and Related Work to support the background observation that SCA tools using different databases can disagree. This observation is not load-bearing for the graph construction, the theoretical properties, or the empirical findings, and nothing in the paper's argument depends on that citation as a substitute for evidence. The paper also discloses the over-approximation inherent in treating any dependency as inheriting a vulnerability, which is an acknowledged limitation rather than a hidden circular step. Accordingly, the central results are self-contained and externally checkable against the SBOM/SCA pipeline, so the circularity score is low.

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

The VDGraph construction and queries rest on several domain assumptions about the data sources and graph structure. No free parameters are fitted; the empirical results are direct measurements from the constructed graphs. The main assumptions are reachability of the SBOM graph, accuracy of OSV-Scanner data, reliability of name-version matching, and the conservative propagation model.

assumptions (4)
  • domain assumption Every dependency in the SBOM is reachable from the root vertex in GSBOM.
    Stated in Section III-D as the basis for Proposition 2. If false, some vulnerability vertices would be unreachable and the reachability property and depth queries would be invalid.
  • domain assumption OSV-Scanner vulnerability data is accurate and complete for the components listed in the SBOM.
    The empirical findings in Section V rely entirely on OSV-Scanner output; the paper does not cross-validate against other SCA tools or ground truth.
  • domain assumption A component name plus version is a reliable key to match SBOM and SCA components.
    Section IV-D describes matching on name and version. Collisions exist (127 of 4316 entries) and can cause incorrect vulnerability attribution, although the paper reports only one such case in practice.
  • domain assumption Any component that depends on a vulnerable package is assumed to inherit the vulnerability (conservative propagation).
    Acknowledged as an over-approximation in Section VI; it can produce false positives but is inherent to SCA.

how reviews work

0 comments
Cite this review

Pith. "Pith review of VDGraph: A Graph-Theoretic Approach to Unlock Insights from SBOM and SCA Data." pith.science (2026). https://pith.science/paper/XJISG5WU

@misc{pith2026250720502,
  author       = {Pith},
  title        = {Pith review of: VDGraph: A Graph-Theoretic Approach to Unlock Insights from SBOM and SCA Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XJISG5WU}},
  note         = {Machine review of arXiv:2507.20502}
}
read the original abstract

The high complexity of modern software supply chains necessitates tools such as Software Bill of Materials (SBOMs) to manage component dependencies, and Software Composition Analysis (SCA) tools to identify vulnerabilities. While there exists limited integration between SBOMs and SCA tools, a unified view of complex dependency-vulnerability relationships remains elusive. In this paper, we introduce VDGraph, a novel knowledge graph-based methodology for integrating vulnerability and dependency data into a holistic view. VDGraph consolidates SBOM and SCA outputs into a graph representation of software projects' dependencies and vulnerabilities. We provide a formal description and analysis of the theoretical properties of VDGraph and present solutions to manage possible conflicts between the SBOM and SCA data. We further introduce and evaluate a practical, proof-of-concept implementation of VDGraph using two popular SBOM and SCA tools, namely CycloneDX Maven plugin and Google's OSV-Scanner. We apply VDGraph on 21 popular Java projects. Through the formulation of appropriate queries on the graphs, we uncover the existence of concentrated risk points (i.e., vulnerable components of high severity reachable through numerous dependency paths). We further show that vulnerabilities predominantly emerge at a depth of three dependency levels or higher, indicating that direct or secondary dependencies exhibit lower vulnerability density and tend to be more secure. Thus, VDGraph contributes a graph-theoretic methodology that improves visibility into how vulnerabilities propagate through complex, transitive dependencies. Moreover, our implementation, which combines open SBOM and SCA standards with Neo4j, lays a foundation for scalable and automated analysis across real-world projects.

Figures

Figures reproduced from arXiv: 2507.20502 by the authors.

Figure 1
Figure 1. VDGraph combines an SBOM subgraph with an SCA subgraph to create a full dependency chain from the root to each vulnerability (the figure shows an example for one vulnerability). vulnerabilities. Therefore SBOM files alone cannot reliably provide security compliance. While significant progress has been made in generating and utilizing SBOMs and SCA tools, there remains a need for solutions that can effectively scale … view at source ↗
Figure 2
Figure 2. Example of running VDGraph for the flink project. VDGraph provides the full path to each vulnerability, listing each intermediate dependency component. B. Producing SBOM and SCA Subgraphs The initial step in our framework is to run the SBOM and SCA tools, which separately produce two subgraphs: GSBOM and GSCA. In GSBOM, the vertices are either the root or a component, and the only possible edge label is a dependency… view at source ↗
Figure 3
Figure 3. Top vulnerable components (with high severity) for [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Distribution of the length of the shortest paths from [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Distribution of the length of the shortest paths from [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

20 extracted references · 16 canonical work pages

  1. [6]

    Un- derstanding Similarities and Differences Between Software Composition Analysis Tools,

    P. Sharma, Z. Shi, S. Simsek, D. Starobinski, and D. S. Medina, “Un- derstanding Similarities and Differences Between Software Composition Analysis Tools,” IEEE Security & Privacy , vol. 23, no. 1, pp. 53–63, 2025

    work page 2025

  2. [9]

    A comprehensive study of bloated dependencies in the Maven ecosystem,

    C. Soto-Valero, N. Harrand, M. Monperrus, and B. Baudry, “A comprehensive study of bloated dependencies in the Maven ecosystem,” Empirical Software Engineering , vol. 26, no. 3, Mar. 2021. [Online]. Available: http://dx.doi.org/10.1007/s10664-020-09914-8

    doi:10.1007/s10664-020-09914-8 2021

  3. [1]

    Identifying, prioritizing and evaluating vulnerabilities in third party code,

    A. Cobleigh, M. Hell, L. Karlsson, O. Reimer, J. S ¨onnerup, and D. Wisenhoff, “Identifying, prioritizing and evaluating vulnerabilities in third party code,” in 2018 IEEE 22nd International Enterprise Distributed Object Computing Workshop (EDOCW) . IEEE, 2018, pp. 208–211

    work page 2018

  4. [2]

    License compliance issues in free and open source software,

    G. Gangadharan, S. De Paoli, V. D’Andrea, and M. Weiss, “License compliance issues in free and open source software,” MCIS 2008 Proceedings, p. 2, 2008

    work page 2008

  5. [3]

    The impact of maintainability on component-based software systems,

    Mari and Eila, “The impact of maintainability on component-based software systems,” in 2003 Proceedings 29th Euromicro Conference . IEEE, 2003, pp. 25–32

    work page 2003

  6. [4]

    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. [Online]. Available: https://arxiv.org/abs/2402.11151

    arXiv 2024

  7. [5]

    An open guide to evaluating software composition analysis tools,

    I. Haddad, “An open guide to evaluating software composition analysis tools,” Linux Foundation, 2020

    work page 2020

  8. [7]

    Google OSV scanner,

    Google, “Google OSV scanner,” 2023. [Online]. Available: https://google.github.io/osv-scanner/

    work page 2023

Show all 20 references
  1. [8]

    dependency-track,

    The OWASP Foundation, “dependency-track,” 2023. [Online]. Available: https://dependencytrack.org/

    2023

  2. [10]

    Cyclonedx maven plugin,

    The OWASP Foundation, “Cyclonedx maven plugin,” 2024. [Online]. Available: https://github.com/CycloneDX/cyclonedx-maven-plugin

    2024

  3. [11]

    The system package data exchange ™ (spdx®),

    Linux Foundation, “The system package data exchange ™ (spdx®),”

  4. [12]

    On the Way to SBOMs: Investigating Design Issues and Solutions in Practice,

    T. Bi, B. Xia, Z. Xing, Q. Lu, and L. Zhu, “On the Way to SBOMs: Investigating Design Issues and Solutions in Practice,” ACM Trans. Softw. Eng. Methodol. , vol. 33, no. 6, Jun. 2024. [Online]. Available: https://doi.org/10.1145/3654442

    2024 doi

  5. [13]

    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. [Online]. Available: https://arxiv.org/abs/2409.06390

    2024 arXiv

  6. [14]

    Impacts of Software Bill of Materials (SBOM) Generation on Vulnerability Detection,

    E. O’Donoghue, B. Boles, C. Izurieta, and A. M. Reinhold, “Impacts of Software Bill of Materials (SBOM) Generation on Vulnerability Detection,” in Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses , ser. SCORED ’24. New York, N...

    2024

  7. [15]

    Jbomaudit: Assessing the landscape, compliance, and security implica- tions of java sboms,

    Y. Xiao, D. Kirat, D. L. Schales, J. Jang, L. Xing, and X. Liao, “Jbomaudit: Assessing the landscape, compliance, and security implica- tions of java sboms,” in ISOC Network and Distributed System Security Symposium, 2025

    2025

  8. [16]

    Automating SBOM Generation with Zero-Shot Semantic Similarity,

    D. Pereira, C. Molloy, S. Acharya, and S. H. H. Ding, “Automating SBOM Generation with Zero-Shot Semantic Similarity,” 2024. [Online]. Available: https://arxiv.org/abs/2403.08799

    2024 arXiv

  9. [17]

    Graph labeling,

    J. A. Gallian, “Graph labeling,” The electronic journal of combinatorics, pp. DS6–Nov, 2012

    2012

  10. [18]

    Package-url,

    S. Schuberth, P. Ombredanne, J. Kowalleck, W. Bartholomew, S. Springett, and J. M. Horan, “Package-url,” https://github.com/package-url/purl-spec, 2017

    2017

  11. [19]

    Db-engines ranking of graph dbms,

    DB-Engines, “Db-engines ranking of graph dbms,” 2025. [Online]. Available: https://db-engines.com/en/ranking/graph+dbms

    2025

  12. [2021]

    Available: https://spdx.dev

    [Online]. Available: https://spdx.dev

Pith tools

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