Dependency Snapshotting Techniques

• Dependency snapshotting is a technique that captures explicit dependency states at a specific time, enabling precise querying, reproducibility, and validation across various execution contexts.
• It employs diverse methods—from repository graphs and lockfiles to runtime introspection and proof-state reuse—to manage evolving dependency relationships.
• Applications include ensuring build reproducibility, accelerating serverless startup, and performing ecosystem-level vulnerability analysis in complex software environments.

Searching arXiv for the cited papers to ground the article in current metadata and identifiers. Dependency snapshotting denotes a family of techniques that capture a dependency-relevant state at a specific point in time and preserve it for later querying, validation, reproduction, restoration, or comparison. The captured state may be a repository-wide dependency graph, a fully resolved build, a runtime set of executing dependencies, an API interaction trace, an elaborated proof state, a booted serverless instance, or a subset of a large object or dataflow graph. What unifies these systems is the conversion of an otherwise implicit, drifting, or repeatedly reconstructed dependency relation into an explicit artifact that can be reused across time or across execution branches (Benelallam et al., 2019, Schmid et al., 1 Oct 2025, Chockchowwat et al., 18 Nov 2025).

1. Concept and terminology

The literature does not use a single implementation model for dependency snapshotting. In software ecosystems, the snapshot is often a temporal graph indexed by release date and version precedence, as in the Maven Dependency Graph and Debian’s evolutionary dependency graphs (Benelallam et al., 2019, Tang et al., 2024). In build and supply-chain settings, the snapshot may be a lockfile, a traced read/write dependency set, or a binary whose DT_NEEDED entries have been rewritten to absolute paths (Schmid et al., 1 Oct 2025, Spall et al., 2020, Zakaria et al., 2022). In runtime settings, the snapshot may instead encode which dependencies actually executed, which interactions crossed an API boundary, or which subset of memory pages or proof-state structures must be reused to avoid redundant reconstruction (Cofano et al., 23 Oct 2025, Monce et al., 28 Jul 2025, Ustiugov et al., 2021, Shen et al., 25 May 2026).

A common misconception is that dependency snapshotting is synonymous with complete snapshotting. Several systems explicitly reject that equation. Chipmink contrasts Pickle/Dill-style complete snapshotting with graph-based delta identification and pod-based partial persistence (Chockchowwat et al., 18 Nov 2025). Asynchronous Barrier Snapshotting persists only operator states on acyclic execution topologies and adds only a minimal record log on cyclic dataflows (Carbone et al., 2015). REAP does not eagerly restore an entire serverless image; it records and prefetches a stable working set of guest-memory pages (Ustiugov et al., 2021). The concurrent snapshot literature makes the same distinction at the abstract object level: partial $\lambda$-Snap supports PARTIAL_SCAN over a subset of components rather than forcing full-vector reads (Kallimanis et al., 2020).

2. Temporal ecosystem snapshots

The Maven Dependency Graph (MDG) is a canonical repository-scale snapshot. It takes Maven Central as of September 6, 2018, extracts artifact metadata and direct dependencies from pom.xml, and stores the result in Neo4j as a graph database in which dependencies are explicit rather than implicit (Benelallam et al., 2019). The graph is defined as

$$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$

where $\mathcal{A}$ are artifact nodes, $\mathcal{C}$ calendar nodes, $\mathcal{D}$ dependency relationships, and $\mathcal{N}$ version-precedence relationships. Artifact nodes carry coordinates, group, artifact, version, release_date, and packaging; coordinates uniquely identify an artifact node. Dependencies are represented by DEPENDS_ON edges from a user artifact to a provider artifact, with scope values Compile, Runtime, Provided, Test, System, and Import. Version evolution is represented by NEXT, and temporal indexing is provided by YEAR, MONTH, and DAY calendar nodes (Benelallam et al., 2019).

The reported scale is large enough to motivate explicit snapshotting as a research artifact rather than a convenience layer. Maven Central had about 2.8M unique artifacts at that time, while the graph contains metadata for 2,407,335 artifacts, 35,699 groups, 223,478 libraries, 2,183,845 upgrades, and 9,715,669 directed dependency edges, with graph density about 4.03 (Benelallam et al., 2019). The authors emphasize that this snapshot is substantially larger than the earlier Maven Repository Dataset, with 13.5× more artifacts and 14.7× more dependencies since July 30, 2011. The result is a temporal ecosystem graph that supports questions about deployments in a given year, version-chain traversal, dependency freshness, migration, adoption, and vulnerability exposure (Benelallam et al., 2019).

A closely related but more explicitly historical form appears in Debian ecosystem reconstruction. Using the official Debian snapshot archive, the study of fixed-release Linux reconstructs dependency graphs from historic mirror states by crawling Packages.gz, retaining the first snapshot of each day, parsing Package, Version, and Depends, and building a day-level Evolutionary Dependency Graph over Debian 7 through Debian 11 (Tang et al., 2024). Packages are identified by $$\langle \text{package name}, \text{version} \rangle$$, and version constraints use Debian relation operators

$<<,\ \le,\ =,\ \ge,\ >>.$

The resulting dataset reports 37K projects, 102K packages, 1.5 million package versions, 8 million package-level dependencies, and 1.8 million project-level dependencies (Tang et al., 2024).

Snapshot	Temporal indexing	Reported scale
MDG	release_date, YEAR/MONTH/DAY, NEXT	2,407,335 artifacts; 9,715,669 dependency edges
Debian EDGraph	first snapshot of each day from snapshot.debian.org	37K projects; 1.5 million package versions

The Debian study shows why temporal snapshots matter analytically. They support release-pair compatibility analysis, identification of obsolete-release behavior, and extension to an Evolutionary Dependency-Vulnerability Graph via Debian Security Tracker and vuln-list matching (Tang et al., 2024). The paper reports that between adjacent releases 70% to 85% of common projects are updated to new versions, 96% of updates occur during the development stage, only 4% during formal Debian life, and less than 0.1% during LTS. It also reports that a package has about 6 external dependencies on average, only a small fraction of projects are directly vulnerable, but more than 87% of projects are affected through transitive dependencies; in bullseye, 749 (2%) are original vulnerable projects and 27,325 (88%) are transitively affected (Tang et al., 2024). This suggests that repository snapshotting is not merely archival; it is the data substrate for ecosystem-level causal analysis.

3. Build reproducibility and supply-chain integrity

In build systems, dependency snapshotting usually freezes a resolution result that would otherwise drift. Maven-Lockfile does this for Maven by generating a human-readable JSON lockfile that captures the full resolved dependency tree, including resolved versions, checksums, source information, a distinction between direct and indirect/transitive dependencies, and optionally environment metadata and Maven plugins (Schmid et al., 1 Oct 2025). The workflow is explicit: generate a lockfile, validate a build environment against it, rebuild old versions using a frozen pom.lockfile.xml, and optionally regenerate or validate lockfiles in CI through a GitHub Action. For historical rebuilds, the freeze feature replaces direct dependency versions in pom.xml, adds transitive dependencies to dependencyManagement with their version and scope, and then invokes Maven with -f pom.lockfile.xml (Schmid et al., 1 Oct 2025).

The integrity model is checksum-based. Validation checks the resolved dependency set against the lockfile and compares the checksum of each artifact with the recorded checksum; the paper summarizes the key idea as same version + same checksum implying the same artifact state, while mismatch indicates a possible silent update or tampering (Schmid et al., 1 Oct 2025). In evaluation, the authors randomly chose 10 previous releases of Maven-Lockfile itself, found that all 10 releases had valid lockfiles, and rebuilt 9 out of 10 successfully; the failure was traced to a dependency-resolution bug involving transitive dependencies with test scope in the frozen POM and was fixed in version 5.1.0. A separate experiment perturbed JAR bytes and showed that validation correctly reported a changed checksum (Schmid et al., 1 Oct 2025). The paper is equally clear about limits: remote checksum mode depends on trust in the repository, local checksum mode cannot detect pre-download tampering, and compatibility across tool versions matters.

A different build-time formulation appears in Rattle’s traced dependencies. Instead of asking developers to declare dependencies, the system traces what each command reads and writes, records the observed inputs and outputs with cryptographic hashes, and then skips commands whose observed file content has not changed (Spall et al., 2020). The goal is “perfect dependencies”: dependencies are captured from actual execution and are therefore correct by construction, subject to the hazard model. The paper defines command read and write sets, build inputs as

$$\bigcup_{c \in C} c_r \setminus \bigcup_{c \in C} c_w,$$

and outputs as

$\bigcup_{c \in C} c_w.$

It then characterizes correctness through read-write, write-write, and speculative-write-read hazards (Spall et al., 2020). This is dependency snapshotting in a narrower but exact sense: the snapshot is the observed dependency relation of a concrete build execution.

Binary-level deployment determinism yields yet another variant. In the HPC setting, Shrinkwrap freezes dependency resolution into ELF binaries by rewriting DT_NEEDED entries so they contain absolute paths rather than sonames and by lifting transitive dependencies to the top-level binary (Zakaria et al., 2022). The paper argues that directory-based search via RPATH, RUNPATH, and LD_LIBRARY_PATH is too coarse to encode a precise dependency closure. Shrinkwrap therefore snapshots which libraries were needed, where they were found, and in what order they should be loaded. The reported effect is both reproducibility and startup reduction: for Nix-built emacs, normal loading involved 1823 stat/openat calls and 0.034121 s, whereas the shrinkwrapped binary used 104 calls and 0.000950 s, a 36× speedup; on a large dynamically linked MPI application, the wrapped executable improved launch time from 169 s to 30.5 s at 512 processes on 4 nodes, and achieved a 7.2× speedup at 2048 processes (Zakaria et al., 2022). A plausible implication is that dependency snapshotting can be performance-critical even when its initial motivation is determinism.

4. Runtime introspection and compatibility contracts

Build-time snapshots do not necessarily reveal what executes at runtime. Classport addresses this by embedding dependency identity into Java class files as a runtime-visible annotation and retrieving it through a Java agent (Cofano et al., 23 Oct 2025). The system consists of an Embedder at build time and an Introspector at execution time. The Embedder injects dependency metadata into each class as $\mathcal{C}$5 and Maven then packages an uber-JAR containing the annotated classes. At runtime, the Introspector instruments execution through the Instrumentation API, reads the annotation from executing classes, and emits the observed runtime dependency set as CSV (Cofano et al., 23 Oct 2025). The evaluation on six Maven projects reports successful embedding in all tested projects, with build-time overhead from +0.51s to +18.86s, disk overhead from 10% to 29%, runtime overhead from 0.74% to 4.27%, and FP = 0 and FN = 0 for all projects (Cofano et al., 23 Oct 2025). The paper’s central point is that manifests and lockfiles do not say which dependencies are actually exercised in production.

API interaction snapshots move from dependency identity to dependency behavior. Gilesi treats the actual interactions at the client–library boundary during client test execution as the client’s expected contract with the library (Monce et al., 28 Jul 2025). Each interaction is formalized as

$$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$0

where $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$1 is the API method, $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$2 the receiver object, $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$3 the input arguments, and $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$4 the typed result, either a return value or an exception (Monce et al., 28 Jul 2025). Gilesi identifies the client-specific API footprint with UCov, instruments relevant methods via Java instrumentation APIs and Byte Buddy, serializes easy-to-serialize values with XStream, and compares old and new snapshots by protocol order and pairwise interaction equality (Monce et al., 28 Jul 2025).

This formulation addresses a specific weakness of ordinary client regression testing: tests validate client logic, not necessarily every subtle property of the library. In a preliminary case study on Jsoup with 6 clients and Commons-Lang3 with 21 clients, using 158 mutants, Gilesi detected 96% while client tests detected 89%; all mutants detected by client tests were also detected by Gilesi, and Gilesi additionally detected 10 mutants missed by client tests (Monce et al., 28 Jul 2025). The undetected cases involved library-side I/O side effects or effectively equivalent default-return behavior. A common misconception is that compatibility is fully captured by successful compilation or unchanged direct dependency lists; these results show that behavioral compatibility may instead depend on preserving the sequence of invocations and the values exchanged at the API boundary.

5. Execution-state reuse and acceleration

Some work uses snapshotting not to preserve dependency identity but to preserve the already prepared state on which future branches or invocations depend. In serverless systems, a snapshot is a disk-resident capture of a fully booted function instance, including the virtual machine monitor state, the emulated devices state, and the guest-physical memory contents (Ustiugov et al., 2021). Snapshot-based startup avoids recreating the VM, guest OS, runtime components, and user-code initialization. Yet the paper reports that the execution time of a function started from a snapshot is still 95% higher on average than when the same function is memory-resident, because lazy paging causes page faults as the function state is faulted in from disk one page at a time (Ustiugov et al., 2021). REAP exploits the observation that snapshot-restored functions use a small and stable working set: about 8–99 MB, with average working set about 24 MB, and for 7 out of 10 functions, more than 97% of the accessed pages are identical across invocations. By recording this working set and prefetching it proactively, REAP reduces cold-start delay by 3.7x on average and eliminates about 97% of page faults on average (Ustiugov et al., 2021).

Lean 4 proof search exposes an analogous dependency on elaborated state. In DSP-style tactic search, each branch ordinarily reconstructs the proof state by re-running import loading and theorem-body elaboration. The paper reports ~60 s per branch for import loading and 18–735 s for theorem-body elaboration in Lean 4 with Mathlib, together accounting for more than 99% of per-branch wall time (Shen et al., 25 May 2026). Proof-state snapshotting captures the elaborated proof state once and reuses it across branches through a small extension to Lean.Server.FileWorker, adding $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$5/lean/dspSnapshotCapture, and $/lean/dspSnapshotBranch. The large immutable Environment of about 2–4 GB is shared by reference, while the mutable MetavarContext is typically only KBs and is copied per branch (Shen et al., 25 May 2026). Across 48 miniF2F-v2 problems, including 45 prove-phase benchmarks, the method yields 5.6× to 50× wall-time speedup, with average 14× and median 9.7×, and speedup increases with branch count (Shen et al., 25 May 2026). The paper explicitly distinguishes this from import-level caching such as Kimina Lean Server: import caching avoids import loading, while snapshotting avoids both import loading and theorem-body elaboration within the theorem.

Asynchronous snapshots of actor systems pursue a related objective under latency constraints. The Truffle/Graal prototype captures partial heaps, tracks dependencies between actors and snapshot chunks, and completes snapshots step by step while the system keeps running (Aumayr et al., 2019). Rather than freezing the whole heap, the runtime follows dependency chains until the snapshot closure is complete. The Acme Air evaluation reports that when performing a snapshot every thousand requests, the number of slow requests—0.007% of all requests with latency above 100ms—increases by 5.43% (Aumayr et al., 2019). This indicates that execution-state snapshotting can be made compatible with latency-sensitive services, provided the runtime tracks and resolves snapshot dependencies asynchronously.

6. Delta, partial, and minimal snapshots

Chipmink is an explicit critique of repeated full snapshots in data science systems. The paper starts from the observation that notebooks and scripts manipulate massive, changing object graphs whose state may span memory heaps, shared memory, GPUs, and remote machines (Chockchowwat et al., 18 Nov 2025). Existing persistence tools such as Pickle and Dill perform complete snapshotting of the whole reachable object graph, repeatedly serializing unchanged objects. Chipmink models state as a graph of objects and references, identifies dirty objects, determines the affected subgraph, and persists only the impacted units (Chockchowwat et al., 18 Nov 2025). The key abstraction is the pod, a dynamically induced persistence unit chosen by partitioning objects into subgroups that minimize expected persistence costs based on object sizes and reference structure. The reported gains are up to 36.5× smaller storage sizes and 12.4× faster persistence than the best baselines in real notebooks and scripts (Chockchowwat et al., 18 Nov 2025).

Distributed stream processing reaches similar conclusions from a fault-tolerance perspective. Asynchronous Barrier Snapshotting (ABS) persists only the state necessary to recover a consistent execution prefix (Carbone et al., 2015). In an acyclic execution graph $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$6, the complete snapshot is $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$7 with

$$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$8

so operator state alone suffices (Carbone et al., 2015). Barriers injected periodically at the sources align inputs locally: when a task has seen barriers on all inputs, it snapshots its local state, forwards the barrier downstream, and unblocks the channels. Cycles require a minimal extension: the runtime identifies back-edges, copies local state once barriers from regular inputs arrive, logs only records received from back-edges during the logging phase, and then snapshots $$\mathcal{M} = (\mathcal{A}, \mathcal{C}, \mathcal{D}, \mathcal{N}),$$9 when all inputs have crossed the boundary (Carbone et al., 2015). The implementation on Apache Flink maintains linear scalability up to 40 nodes and avoids the global stalls of synchronous snapshotting (Carbone et al., 2015).

At the shared-memory object level, $\mathcal{A}$0-Snap formalizes bounded scan concurrency and dynamic partial scans (Kallimanis et al., 2020). A $\mathcal{A}$1-scanner snapshot object allows at most $\mathcal{A}$2 active SCAN operations in any execution, interpolating between the single-scanner case $\mathcal{A}$3 and the multi-scanner case $\mathcal{A}$4 (Kallimanis et al., 2020). The paper reports that 1-Snap provides UPDATE in $\mathcal{A}$5, SCAN in $\mathcal{A}$6, and space $\mathcal{A}$7, while $\mathcal{A}$8-Snap provides UPDATE in $\mathcal{A}$9, SCAN in $\mathcal{C}$0, and space $\mathcal{C}$1. The partial version supports PARTIAL_SCAN(A) over a runtime-supplied subset $\mathcal{C}$2, with step complexity $\mathcal{C}$3 where $\mathcal{C}$4 (Kallimanis et al., 2020). This is a formal statement of a design choice that also appears in systems work: if the consumer does not need the whole state, reading or persisting the whole state is unnecessarily expensive.

7. Trade-offs, misconceptions, and persistent distinctions

The major trade-off across the literature is between fidelity, granularity, and overhead. Repository snapshots such as MDG and Debian EDGraph provide ecosystem-scale observability but require large graph databases and specialized query infrastructure (Benelallam et al., 2019, Tang et al., 2024). Lockfiles and binary rewriting provide stronger reproducibility and integrity properties for particular builds, but their guarantees depend on trust roots and compatibility assumptions: Maven-Lockfile’s remote checksum mode trusts the repository, local mode cannot detect pre-download tampering, and lockfile compatibility varies across tool versions; Shrinkwrap works with glibc-like behavior and BSD libcs but not musl (Schmid et al., 1 Oct 2025, Zakaria et al., 2022). Runtime snapshots such as Classport and Gilesi reveal what actually executes or what contract is actually exercised, but their coverage depends on the workload and the executed test suite (Cofano et al., 23 Oct 2025, Monce et al., 28 Jul 2025).

Another persistent distinction is between inter-version and intra-execution snapshotting. Repository and lockfile systems capture the dependency graph across releases or builds. Classport and Gilesi capture runtime identity or behavior for a single execution. REAP, actor snapshots, Chipmink, and Lean proof-state snapshotting instead capture a live state so that future invocations or branches can avoid reconstructing it (Ustiugov et al., 2021, Aumayr et al., 2019, Chockchowwat et al., 18 Nov 2025, Shen et al., 25 May 2026). This suggests that “dependency” in dependency snapshotting can denote artifact graphs, runtime code provenance, protocol traces, or reusable state on which later work causally depends.

A final misconception is that snapshotting and caching are interchangeable. The Lean 4 work makes the boundary explicit: Level 1 import caching and Level 2 proof-state snapshotting are complementary because they eliminate different costs (Shen et al., 25 May 2026). The same pattern recurs elsewhere. ABS is not simply buffering channels; it is a barrier-driven algorithm for feasible snapshots (Carbone et al., 2015). Chipmink is not a memoized serializer; it is a graph-aware store that partitions the object graph into pods (Chockchowwat et al., 18 Nov 2025). Maven-Lockfile is not just a list of direct versions; it freezes the entire resolved graph together with checksums (Schmid et al., 1 Oct 2025). In that sense, dependency snapshotting is best understood not as a single mechanism but as a design principle: make dependency state explicit, time-indexed when necessary, and reusable at the granularity that preserves correctness while avoiding avoidable recomputation or drift.