VDGraph: Unified Graph for SBOM & SCA

• VDGraph is a labeled property graph that integrates SBOM dependency structures with SCA vulnerability data for comprehensive software project insights.
• It enables path-centric analysis by supporting queries on the number of paths and shortest path lengths from the project root to vulnerable components.
• The method consolidates data through exact name-and-version matching, revealing concentrated risk points at deeper dependency levels.

VDGraph is a labeled property graph methodology for integrating Software Bill of Materials (SBOM) data with Software Composition Analysis (SCA) findings into a single, queryable representation of software-project dependencies and vulnerabilities. In the formulation introduced in “VDGraph: A Graph-Theoretic Approach to Unlock Insights from SBOM and SCA Data” (Xia et al., 28 Jul 2025), the method consolidates dependency structure from SBOMs and vulnerability evidence from SCA tools so that paths from a project root to vulnerable components can be analyzed directly. This graph-theoretic view supports path-count and shortest-path analyses, and the reported evaluation on 21 popular Java projects identified concentrated risk points and a predominance of vulnerabilities at depth three or higher (Xia et al., 28 Jul 2025).

1. Problem setting and analytical purpose

Modern software projects rely heavily on third-party components and therefore accumulate deep dependency trees. In the setting addressed by VDGraph, SBOM tools and SCA tools expose complementary but incomplete views of that structure. SBOMs provide dependency structure, metadata, and relationships, but do not include vulnerability findings; SCA tools provide vulnerability findings for discovered components, but generally present flat lists with limited dependency context (Xia et al., 28 Jul 2025).

VDGraph addresses this integration gap by constructing a unified graph in which dependency relationships and vulnerability attachments coexist. The immediate analytical consequence is that vulnerability analysis becomes path-centric rather than list-centric. Instead of asking only whether a component is vulnerable, the graph supports questions such as whether a vulnerability is reachable from the root project, how many dependency paths reach the affected component, and how deep in the dependency graph the vulnerable component appears (Xia et al., 28 Jul 2025).

This design is motivated by the observation that manually correlating SBOM and SCA outputs is error-prone because of naming differences, version-format discrepancies, and the existence of multiple dependency paths. VDGraph therefore treats integration itself as a graph construction problem, not merely as a reporting problem (Xia et al., 28 Jul 2025).

2. Formal graph model

The formal object is a labeled property graph

$G(V,E,L_V,L_E),$

where $V$ is the set of vertices, $E$ the set of directed edges, $L_V$ the set of vertex labels, and $L_E$ the set of edge labels. The vertex labels are

$L_V = \{root,\ comp.,\ vuln.\},$

and the edge labels are

$L_E = \{depn,\ has\_v\}.$

Each vertex $v$ carries properties including $\{name, id, version, source\}$ (Xia et al., 28 Jul 2025).

Element	Formal label	Role
Project root	root	entry vertex for dependency reachability
Software component	comp.	dependency artifact
Vulnerability	vuln.	vulnerability record
Dependency edge	depn	directed dependency relation
Vulnerability edge	has_v	component-to-vulnerability relation

The paper distinguishes two source subgraphs. $G_{SBOM}$ contains root and component vertices connected by depn edges, and is described as a connected dependency DAG rooted at the project. $V$0 contains component and vulnerability vertices connected by has_v edges, and is typically a forest in which one or more components connect to a vulnerability (Xia et al., 28 Jul 2025).

Reachability is defined along directed paths from the root through dependency edges and then to a vulnerability via a has_v edge. Two query primitives are central. Query 1 counts the number of distinct paths from the root to a vulnerable component of high severity, denoted $V$1, where $V$2 is the set of distinct dependency paths to component $V$3 that has a has_v edge to a high-severity vulnerability. Query 2 computes the shortest path length from the root to each vulnerability vertex (Xia et al., 28 Jul 2025).

3. Graph construction and conflict resolution

VDGraph is constructed by merging $V$4 and $V$5. The initialization step sets $V$6. For each component vertex $V$7, the algorithm checks whether there exists a component $V$8 such that $V$9 and $E$0. If such a match exists, the SCA component is merged into the existing graph component. If no match exists, the component is added to $E$1 and connected directly to the root by a depn edge. For each vulnerability adjacent to $E$2 in $E$3, the vulnerability vertex is added if absent, and a has_v edge from the component to the vulnerability is inserted (Xia et al., 28 Jul 2025).

The reconciliation rule is deliberately simple: exact equality on (name, version) is the primary match key. Vulnerability vertices are deduplicated by identifier. If an SCA component matches multiple SBOM components, as can happen when the SCA output under-specifies version, the vulnerability is linked to each matched component. Timestamp reconciliation is not part of the method, and cross-ecosystem aliasing is not addressed in the reported evaluation, which is limited to Maven/Java (Xia et al., 28 Jul 2025).

Two formal properties are stated. First, completeness: the merged graph contains all vertices and edges of $E$4 and $E$5 after merging. Second, reachability: every vulnerability vertex in $E$6 is reachable from the root vertex. The direct-root attachment rule for unmatched SCA components guarantees this reachability, but the paper explicitly notes the resulting completeness-versus-accuracy trade-off, because such an added edge may be inaccurate (Xia et al., 28 Jul 2025).

Under an adjacency-matrix representation, the worst-case space and time complexity are both

$E$7

since each edge is updated at most once (Xia et al., 28 Jul 2025).

4. Toolchain, ETL, and query semantics

The proof-of-concept implementation combines the CycloneDX Maven plugin for SBOM generation, Google’s OSV-Scanner for SCA, Python scripts for JSON parsing and transformation, and Neo4j as the graph database queried with Cypher (Xia et al., 28 Jul 2025). In the Neo4j schema, the formal labels root, comp., and vuln. are realized as root, component, and vulnerability nodes, and the formal relations depn and has_v are realized as :dependency and :vulnerability (Xia et al., 28 Jul 2025).

SBOM ingestion maps the root node from metadata.component, component nodes from SBOM components, and dependency edges from the SBOM dependencies section, using bom-ref as identifier when available. For OSV-Scanner output, each vulnerability becomes a vulnerability vertex with properties such as identifier, severity, published, and modified. OSV package names of the form group:name are split, and when bom-ref is unavailable the ETL synthesizes an identifier of the form name_version. The implementation also flattens license arrays to facilitate Cypher filtering (Xia et al., 28 Jul 2025).

The paper provides representative Cypher queries. One query counts paths to components that have high-severity vulnerabilities; another computes shortest-path length from the root to each vulnerability:

$E$8

These queries exemplify the main purpose of VDGraph: turning dependency-vulnerability integration into a graph query problem. The significance lies less in the particular query language than in the fact that dependency reachability, multiplicity of paths, and vulnerability depth are all defined on the same graph object (Xia et al., 28 Jul 2025).

5. Empirical results and observed risk structure

The evaluation uses 21 popular Maven-based Java projects adapted from Balliu et al., selected to satisfy four conditions: Maven build, recent activity with commits no earlier than July 2024, at least one dependency, and at least 100 GitHub stars. For each project, the workflow generates a CycloneDX SBOM, scans it with OSV-Scanner, loads the result into Neo4j, and evaluates the graph by query. The reported environment is a MacBook Pro 14" (2023), Apple M3 Pro, 18 GB RAM, and ETL runtime is at most 4 seconds per project across the set (Xia et al., 28 Jul 2025).

The most prominent empirical finding is the existence of concentrated risk points, defined as vulnerable components of high severity reachable through numerous dependency paths. The paper gives several concrete examples. In flink, protobuf-java 2.5.0 is reachable through more than 150,000 distinct dependency paths; jackson-mapper-asl 1.9.13 through about 62,400; jettison 1.1 through about 43,600; netty 3.10.6.Final through about 13,200; and gson 2.2.4 through about 1,800. In alluxio, protobuf-java 3.19.6 is reachable through about 8,200 paths and netty-codec-http2 4.1.87.Final through about 6,150. In the smaller zerocode graph, jetty-server 9.2.28.v20190418 appears among the most reachable high-severity entries with about 24 paths (Xia et al., 28 Jul 2025).

The second major finding concerns vulnerability depth. Across the 21 projects, there are no vulnerable components at depth 1, few at depth 2, and a predominance at depth 3 or higher, with most vulnerabilities at depth 3–4. The aggregate shortest path from root to vulnerability has mean 4.07 hops and median 4 hops. Moreover, 74.0% of all vulnerabilities lie within at most 4 hops, and 69.7% of critical-plus-high vulnerabilities lie within at most 4 hops. The paper compares this with the overall component-depth distribution, noting that 82.2% of all components are within at most 4 hops, but 34.7% of all components occur at depths 1–2, which show proportionally fewer vulnerabilities than depths 3–4. The interpretation stated in the paper is that direct and secondary dependencies are relatively less vulnerable, while deeper transitive dependencies dominate vulnerability exposure (Xia et al., 28 Jul 2025).

6. Limitations, validity threats, and prospective extensions

The reported methodology is toolchain-specific. The evaluation is limited to Maven-based Java projects, CycloneDX as SBOM format, OSV-Scanner as SCA source, and Neo4j as graph backend. Cross-ecosystem aliasing is not handled, and the name-plus-version reconciliation rule is intentionally conservative (Xia et al., 28 Jul 2025).

VDGraph also inherits upstream data-quality limitations. Prior SBOM incompleteness or inaccuracy propagates into the graph, as do SCA false positives, false negatives, and naming inconsistencies. The integration rule that connects unmatched SCA components directly to the root preserves completeness and reachability, but may distort the actual dependency structure. Likewise, linking a vulnerability to all matched components in a multi-match case preserves coverage at the cost of specificity (Xia et al., 28 Jul 2025).

The propagation model is conservative in a second sense: any dependency on a vulnerable package is treated as exposure, independent of call reachability. This can over-approximate risk. Scalability was practical for the tested projects, but larger monorepos and multi-language dependency graphs were not evaluated (Xia et al., 28 Jul 2025).

Future work proposed in the paper includes broader ecosystem support, improved matching and reconciliation, multi-project interconnected graphs, and more sophisticated risk scoring beyond severity, depth, and path count (Xia et al., 28 Jul 2025).

7. Terminological reuse across arXiv

The name VDGraph is not uniform across arXiv. In the software-supply-chain literature, it denotes the SBOM–SCA knowledge graph just described (Xia et al., 28 Jul 2025). In other literatures, however, the same label or closely related expansions refer to structurally different objects.

In time-series analysis, it has been used to denote a visibility-graph representation of a series, including the Natural Visibility Graph underlying the “Visibility Graph Averaging” aggregation operator (Chen et al., 2013), and the broader visibility-graph family that includes the Circular Limited Penetrable Visibility Graph (CLPVG) (Xuan et al., 2021). In graph generative modeling, it has been used to denote the Dirichlet Graph Variational Autoencoder (DGVAE), whose nodewise latent variables are Dirichlet-distributed soft cluster memberships (Li et al., 2020). In diagram understanding, it denotes the visual diagram graph produced by the Dynamic Graph Generation Network in UDPnet (Kim et al., 2017). In visual dialog, it denotes the spatial-temporal multi-modal graph component in the VD-GR architecture (Abdessaied et al., 2023). In visual document analysis, it denotes a visual document graph paradigm instantiated by GVdoc (Mohbat et al., 2023).

The label therefore denotes different graph constructs in different research domains. A plausible implication is that, outside the 2025 software-supply-chain paper, “VDGraph” functions less as a standardized term than as a context-dependent abbreviation whose meaning must be inferred from the surrounding model or application.