Classport: Designing Runtime Dependency Introspection for Java

arXiv:2510.20340 · cs.SE, cs.CR · Submitted 2025-10-23 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia, and with me are Elias and Priya, guest researcher.

Elias: Today's paper: "Classport: Designing Runtime Dependency Introspection for Java".

Nadia: Runtime introspection of dependencies, i.e., observing which dependencies are currently used during program execution,

Elias: First, who's behind it and why it matters.

Title and authors: Nadia: Now that we’ve covered the basic concept and mechanism of Classport: Designing Runtime Dependency Introspection for Java, let's focus on what the authors suggest are improvements or future directions for this technique.

Elias: I'm eager to hear about the proposed enhancements, because if they have ideas on hardening it against tampering or extending support to other build systems like Gradle, that tells us a lot about its long-term viability.

Priya: From a measurement perspective, I’d like to know what specific challenges the authors identify regarding dependency completeness and class completeness when evaluating this tool in real-world scenarios.

Nadia: The paper points out some limitations related to how well the technique handles dependencies that don't follow fragile conventions when trying to correctly identify them during the build phase.

Elias: That limitation is a technical hurdle, but I’m wondering if they suggest any specific cryptographic measures, perhaps signing the class files or annotations at build time and verifying those signatures at load time?

Priya: I'm curious about their assessment of the performance trade-offs; specifically, what are the findings regarding build time overhead and space overhead that they found to be acceptable for achieving this runtime visibility.

Nadia: They noted that the moderate performance cost during the build phase, ranging from eleven point five two percent to sixteen point eight zero percent, along with space overhead between 0 point 1MB and 6 point 5MB, was considered an acceptable trade-off for gaining runtime visibility into dependencies absent in the Java stack.

Elias: That’s a concrete set of numbers, which is helpful because it grounds the discussion in measurable performance metrics rather than just abstract concepts of feasibility.

Priya: And regarding runtime identification, what did they say about the accuracy when testing against their test suite versus real production workloads?

Nadia: For RQ2, they found that while not all embedded dependencies were detected—due to factors like unused code or classes loaded for type safety—Classport can still successfully introspect dependencies at runtime.

Elias: So, the system isn't perfect at capturing every single execution path in a complex environment, but it does manage to identify the set of currently executed dependencies during a given workload.

Priya: That means we need to be careful not to over-promise on its completeness; we have to accept that it won't always capture every single dependency loaded by the JVM, which is where privacy and measurement researchers come in.

Nadia: The authors are planning future work around hardening Classport against tampering by signing the class files, including dependency annotations at build time, and then verifying those signatures when the application loads.

Elias: Integrating build-time signature verification with runtime metadata checks sounds like a necessary step to ensure that the information embedded in the binary hasn't been maliciously altered by some rogue agent during execution.

Priya: If they can cryptographically guarantee provenance at load time, that would give us a much stronger trust boundary for the dependency information they are extracting.

Nadia: That move toward cryptographic verification is exactly what we need to consider when thinking about resilient software supply chain security measures against tampering.

The paper's summary: Nadia: So we’ve walked through how Classport: Designing Runtime Dependency Introspection for Java works, from the embedding process to the runtime identification phase and their suggested improvements.

Elias: It sounds like the authors are pointing toward cryptographic signing as a way to make this information more resilient against manipulation and future build system extensions.

Priya: I think the practical trade-offs they found regarding space and time overhead suggest that this technique is viable for use in production environments where some performance cost is expected.

Nadia: To wrap up, Classport: Designing Runtime Dependency Introspection for Java provides a blueprint for turning static build-time metadata into dynamic runtime knowledge about dependency usage.

Elias: It’s a tool that allows us to see which dependencies are actively executing during a given workload by embedding GAV coordinates directly into the Java binary.

Priya: Ultimately, the paper gives us concrete data on how this approach works on real projects, which is valuable for understanding what the paper actually delivers in terms of identifying active components.

Nadia: We've seen that Classport successfully identifies dependencies at runtime, even with those inherent limitations we discussed about completeness and overhead.

Elias: This capability opens up new avenues for dependency-aware security policies based on the GAV identity of what is actually running in production.

Priya: I think this work provides a solid foundation for future research into using runtime evidence to build more precise and data-driven security models.

The paper's improvements: Nadia: So we’ve seen how Classport manages to embed that Maven metadata into Java binaries and then pull it out during execution, and now we're looking at what the authors think they need to do next to really make this thing robust.

Elias: Exactly. The paper outlines some crucial hardening steps, particularly around ensuring that the dependency information embedded in those class files hasn't been tampered with while the application is actually running.

Priya: From a measurement standpoint, I’m interested in what kind of cryptographic guarantees they propose to achieve that resilience against tampering without introducing massive performance penalties.

Nadia: The authors are suggesting they should sign the class files and those dependency annotations during the build process and then verify those signatures when the application loads at runtime.

Elias: That makes a lot of sense; integrating build-time signature verification with load-time checks provides a cryptographic guarantee about where that dependency information came from.

Priya: If they can establish that kind of trust boundary through cryptography, it moves this from being just an interesting observation to something with much stronger provenance guarantees for the GAV coordinates.

Nadia: And Elias, you mentioned the assumptions involved in those cryptographic proofs; what are the parameters that could potentially break their proposed verification method?

Elias: The security of that method rests on the integrity of the build process itself, so if there's a flaw in how those signatures are generated or verified at load time, it could open up a door for an attacker to swap out metadata without detection.

Priya: That brings us back to the privacy aspect—if we’re relying on cryptographic proof, are there any inherent trade-offs in terms of the computational resources needed for that verification during startup?

Elias: There are definitely computational costs, but they're generally focused at load time rather than constant execution overhead, which is where they tried to keep things manageable.

Nadia: So it’s a trade-off between build-time complexity and runtime security assurance; I wonder if this kind of cryptographic hardening would be practical for the average enterprise application.

Elias: It’s certainly a step toward making it production-ready, but we still need to think about how much overhead is acceptable when we're talking about large systems.

Priya: Given that the system can identify *actual* execution paths, I think this cryptographic layer could be really powerful for proving the integrity of those identified paths.

Nadia: It sounds like the next big step here is moving beyond just observation to verifiable proof, and that opens up some exciting avenues for how we can trust our software supply chains going forward.

Conclusion: Nadia: So we’ve finished our deep dive into Classport: Designing Runtime Dependency Introspection for Java, and we've established that embedding Maven metadata directly into Java binaries allows us to know exactly which dependencies are actually running in production environments.

Elias: Indeed, and the authors' proposal to use build-time signature verification followed by load-time checks gives us a much firmer basis for trusting that runtime data than we had before.

Priya: What I’m seeing is that this work moves the security conversation from simply looking at static lists of dependencies to having dynamic, executable evidence about what's happening right now.

Nadia: It really does, and I can't help but wonder who would actually exploit this capability and how cheaply they could get away with it if they managed to bypass that signature check.

Elias: That’s a fair question; the security of the whole thing hinges on those assumptions about the build system integrity, so any weakness in that verification process is where an attacker would focus their efforts.

Priya: From a measurement standpoint, I think this capability will allow for much more precise auditing of application behavior than we can get from traditional static analysis tools.

Nadia: Absolutely, and that precision means we could potentially detect issues in running services much faster and with less noise across huge infrastructures.

Elias: It’s a significant step toward making supply chain security proactive rather than just reactive, which is what I find most compelling about this research.

Priya: Overall, Classport: Designing Runtime Dependency Introspection for Java provides a solid blueprint for building systems that can introspect their own behavior with high fidelity at runtime.

Nadia: It’s a really exciting piece of work because it directly addresses the gap between what we *think* is in the code and what's *actually* executing.

Elias: I agree, and looking ahead, I think this opens up fascinating questions about how other systems can adapt to this same pattern of embedding and verification for enhanced security.

Priya: It definitely suggests a future where runtime evidence becomes a standard part of the compliance picture for critical software.

IMT School for Advanced Studies Lucca and University of Genoa · KTH Royal Institute of Technology

cs.SE, cs.CR

Submitted: 2025-10-23

Updated: 2026-10-04

Code: https://github.com/chains-project/classport

License: http://creativecommons.org/licenses/by-sa/4.0/

Importance score: 80/100

The gist: Runtime introspection of dependencies, i.e., observing which dependencies are currently used during program execution, is fundamental for Software Supply Chain security because it addresses the

Key concepts

GAV Coordinates
GAV stands for Group ID, Artifact ID, and Version. These are the standard identifiers used in Maven projects to uniquely identify a specific library or dependency. Classport captures these coordinates from build metadata and embeds them into the compiled Java code so they can be read later.
Embedder
The Embedder is the build-time tool that modifies compiled JAR files. It reads dependency information from Maven builds and uses bytecode transformation to inject this metadata directly into the class files of those dependencies, making it visible before the application runs.
Introspector
The Introspector is a Java agent attached to a running JVM. It intercepts classes when they load and checks for embedded dependency annotations. If a dependency is used, it records that usage with minimal overhead, allowing runtime inspection of active dependencies.

Terminology

Summary

Runtime introspection of dependencies, i.e., observing which dependencies are currently used during program execution, is fundamental for Software Supply Chain security because it addresses the limitations of static Software Bill of Materials (SBOMs) by reflecting actual dependency usages at runtime.

Classport Overview and Problem Statement

The paper introduces Classport, a blueprint and system designed to embed dependency information into Java class files, enabling the retrieval of this information at runtime. This solves a critical problem in the Java ecosystem where native support for dependency introspection is absent; while build-time metadata exists, it is not preserved during execution. The core idea is to bring build-time Maven dependency metadata—specifically the supplier, dependency name, and version (GAV coordinates)—to runtime. Classport operates in two phases: first, embedding dependency information into Java binary artifacts through build-time instrumentation, and second, retrieving this information at runtime through dynamic instrumentation.

Design Components: The Embedder

The Embedder is the first key component of Classport, designed to bridge the gap between build-time and runtime visibility of dependency information. This component captures metadata from the Maven project's build process. The process involves three stages:

  1. Taking as input the compiled artifacts of a Maven project, i.e., the project’s class files and the JARs of the project’s dependencies.

  2. For each dependency JAR, locating the local version and processing its files; for class files within a dependency JAR, it embed[s] dependency metadata, i.e., its group, artifact, and version, using a bytecode transformation.

  3. When encountering manifest files with a dependency JAR (like MANIFEST.MF), it removes signature-related entries to ensure the modified JAR remains valid for distribution by the application developer.

Design Components: The Introspector

The Introspector is responsible for the runtime introspection phase, functioning as a Java agent attached to the JVM. Its goal is to extract[ing] dependency annotations and record which dependency each invoked method belongs to. To maintain low overhead, it employs a specific strategy:

  1. It intercept[s] each class at load time, before it is first used.

  2. It reads the custom annotation, checking if the GAV is already present in an in-memory set; if not, it rewrites the class bytecode to insert a small recording snippet at each method entry.

  3. This approach ensures that no previously instrumented bytecode is ever modified again, allowing it to record only dependencies that are genuinely reachable during a given workload.

Evaluation Methodology and Results

The effectiveness of Classport was evaluated on six real-world open-source Java projects, assessing two main research questions: RQ1 (embedding capability) and RQ2 (runtime inspection).

For RQ1, the evaluation focused on:

- Dependency Completeness:

- Class Completeness:

- Build Time Overhead:

The results demonstrated that Classport successfully embeds dependency information across the tested projects. The paper notes that an uber-JAR is considered complete if all Java class files are annotated with the Classport annotation. The process introduced a moderate performance cost during the build phase, with time overhead ranging from 11.52% to 16.80% and space overhead varying between 0.1MB and 6.5MB, which were deemed acceptable trade-offs for getting a unique feature absent from the Java stack: runtime visibility into dependencies.

For RQ2, the Introspector successfully identified dependencies at runtime. The paper reported that while not all embedded dependencies were detected (due to factors like unused code or classes loaded for type safety), Classport can successfully introspect dependencies at runtime, and allows applications to identify which dependencies are being currently executed, with the execution overhead varying from 2.95% to 8.54%.

Use Cases and Future Work

Classport enables significant security use cases by exposing stable GAV coordinates for each dependency executing at runtime, which is crucial for Runtime Permissions per Dependency. This allows a policy manager to enforce rules based on the dependency’s GAV identity, ensuring policies remain correct even if package names are changed due to shading. Furthermore, it facilitates Vulnerability Detection at Runtime by allowing security teams to query deployed services while they run in production, confirming if a specific vulnerable library is actively executing. Future work includes hardening Classport against tampering by signing the class files, including dependency annotations, at build time and verifying the signature at load time, and extending its support to other build systems like Gradle.

The gist: Classport embeds Maven GAV metadata into Java binary artifacts and exposes this information at runtime, during execution. It successfully identifies the set of dependencies that are actually executed during a given workload with negligible or low overhead.

Improvements for AI systems

Here are the specific improvements that can be made to AI systems based on the Classport paper, and what those improved systems could achieve:

The core contribution of Classport is enabling runtime dependency introspection for Java applications, turning static build-time metadata into dynamic runtime knowledge. This capability directly addresses critical security and optimization needs in software development pipelines.

Here are the specific improvements:

These improved AI systems can achieve the following:

  1. Detect and prioritize vulnerabilities based on actual runtime usage, drastically reducing false positives in Software Composition Analysis (SCA) tools by confirming if a vulnerable dependency is actually being executed in production workloads versus merely being present in the build graph.

  2. Implement fine-grained, dependency-aware runtime access controls (e.g., network or filesystem permissions). The system can enforce policies based on the specific GAV coordinate of a library that is actively executing code, ensuring that only necessary components have authorized privileges, overcoming limitations of package name inference which fails when classes are shaded or relocated.

  3. Perform automated dependency pruning/debloating during runtime analysis by identifying and flagging dependencies whose classes are loaded by the JVM but never executed during a specific workload (e.g., test suites). This allows developers to optimize application memory footprint and reduce the attack surface by removing unused, yet loaded, components that do not contribute to actual execution paths.

  4. Create runtime-aware security monitoring systems capable of triaging threats with surgical precision. Instead of generating broad alerts for every potential vulnerability in a massive codebase, the system can pinpoint exactly which services are actively running the vulnerable component (e.g., Log4j 1.x) and immediately prioritize remediation efforts toward those specific, exposed instances.

  5. Develop more resilient Software Supply Chain security measures against tampering by integrating build-time signature verification with runtime metadata checks. This ensures that the dependency information embedded in the binary artifact has not been maliciously altered by a rogue agent during application execution, providing a cryptographic guarantee of dependency provenance at the moment of use.

Abstract

Runtime introspection of dependencies, i.e., the ability to observe which dependencies are currently used during program execution, is fundamental for Software Supply Chain security. Yet, Java has no support for it. We solve this problem with Classport, a blueprint and system that embeds dependency information into Java class files, enabling the retrieval of dependency information at runtime. We evaluate Classport on six real-world projects, demonstrating the feasibility in identifying dependencies at runtime.

Sources

Related papers