---
title: 'VDGraph: Unified Graph for SBOM & SCA'
url: https://www.emergentmind.com/topics/vdgraph
type: topic
---

# VDGraph: Unified Graph for SBOM & SCA

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” [2507.20502], 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 [2507.20502].

## 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 [2507.20502].

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 [2507.20502].

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 [2507.20502].

## 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\}$ [2507.20502].

| 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. $G_{SCA}$ 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 [2507.20502].

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 $|P(root,c)|$, where $P(root,c)$ is the set of distinct dependency paths to component $c$ 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 [2507.20502].

## 3. Graph construction and conflict resolution

VDGraph is constructed by merging $G_{SBOM}$ and $G_{SCA}$. The initialization step sets $G := G_{SBOM}$. For each component vertex $u \in G_{SCA}$, the algorithm checks whether there exists a component $u' \in G$ such that $u.name = u'.name$ and $u.version = u'.version$. If such a match exists, the SCA component is merged into the existing graph component. If no match exists, the component is added to $G$ and connected directly to the root by a `depn` edge. For each vulnerability adjacent to $u$ in $G_{SCA}$, the vulnerability vertex is added if absent, and a `has_v` edge from the component to the vulnerability is inserted [2507.20502].

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 [2507.20502].

Two formal properties are stated. First, **completeness**: the merged graph contains all vertices and edges of $G_{SBOM}$ and $G_{SCA}$ after merging. Second, **reachability**: every vulnerability vertex in $G$ 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 [2507.20502].

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

$$
O\big((|V_{SBOM}| + |V_{SCA}|)^2\big),
$$

since each edge is updated at most once [2507.20502].

## 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 [2507.20502]. 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` [2507.20502].

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 [2507.20502].

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:

```cypher
MATCH path=(r:root)-[:dependency*]->(c:component)
WHERE EXISTS {
  MATCH (c)-[:vulnerability]->(v:vulnerability)
  WHERE v.severity = 'HIGH'
}
RETURN c.name, count(*)

MATCH (r:root), (v:vulnerability)
MATCH path = shortestPath((r)-[*]->(v))
RETURN length(path)
```

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 [2507.20502].

## 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 [2507.20502].

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 [2507.20502].

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 [2507.20502].

## 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 [2507.20502].

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 [2507.20502].

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 [2507.20502].

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 [2507.20502].

## 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 [2507.20502]. 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 [1311.4166], and the broader visibility-graph family that includes the Circular Limited Penetrable Visibility Graph (CLPVG) [2104.13772]. 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 [2010.04408]. In diagram understanding, it denotes the visual diagram graph produced by the Dynamic Graph Generation Network in UDPnet [1711.09528]. In visual dialog, it denotes the spatial-temporal multi-modal graph component in the VD-GR architecture [2310.16590]. In visual document analysis, it denotes a visual document graph paradigm instantiated by GVdoc [2305.17219].

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.

Source: https://www.emergentmind.com/topics/vdgraph