Maven-Lockfile: High Integrity Rebuild of Past Java Releases

arXiv:2510.00730 · cs.SE, cs.CR · Submitted 2025-10-01 · Read on arXiv

Listen

Transcript

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

Nadia: Today's paper: "Maven-Lockfile: High Integrity Rebuild of Past Java Releases".

Elias: Modern software projects depend on many third-party libraries, complicating reproducible and secure builds

5: .

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

Title and authors: Nadia: So we're talking about "Maven-Lockfile: High Integrity Rebuild of Past Java Releases." It sounds like they're tackling a real headache in the Java world where dependencies just keep changing without warning. Elias, what do you think is the core idea behind that title?

Elias: I see it as a direct response to Maven's current situation; they’ve built a system to stop that dependency drift by creating these lockfiles. The focus is on ensuring that when you build something, you know exactly what every single piece of code and every transitive dependency version was at that specific moment.

Priya: From my side, I'm curious about the scope here. Does this mean they're just freezing the direct dependencies, or are we talking about the entire dependency graph including everything pulled in indirectly? I want to know what the data actually shows regarding how complete this capture is.

Nadia: It sounds like it’s comprehensive because they explicitly mention capturing both direct and transitive dependencies with their checksums, which is pretty deep coverage for a build tool. If you look at the abstract, they say this addresses the problem where Maven doesn't have native support for lockfiles, which is a major gap in security right now.

Elias: Exactly; that lack of native support means the process isn't deterministic by default, and this tool solves that by generating those lockfiles to freeze dependency versions and verify integrity. It moves Maven from being inherently non-deterministic to being reproducible when you use this mechanism.

Priya: The implications for data fidelity are interesting because if it captures transitive dependencies with checksums, we can actually audit the exact state of the build inputs, which is much more valuable than just a simple version number. I wonder how granular this level of dependency tracking is in practice.

Nadia: Well, they claim that this approach enables high integrity builds by capturing those checksums for everything involved. It gives us a verifiable record of what went into the final artifact, which is pretty powerful for security auditing.

Elias: That verification aspect is crucial because it allows you to detect if an artifact has been tampered with after it was downloaded, which is a huge win over just relying on version numbers alone.

Priya: So, the primary implication seems to be moving from a vague understanding of build outcomes to having concrete, verifiable inputs for every single build. That level of transparency in the dependency resolution process is something I can get behind.

The paper's summary: Nadia: Moving on to what they actually did in "Maven-Lockfile: High Integrity Rebuild of Past Java Releases." Essentially, the paper describes a tool that generates lockfiles for Maven projects. It details how this tool captures all direct and transitive dependencies along with their cryptographic checksums to create a frozen dependency graph.

Elias: That capture is the key feature here; they're not just pinning versions, they’re recording exactly what was resolved during the build process, which addresses that inherent non-determinism in Maven builds. It records both direct and indirect dependencies with those crucial checksums included in the lockfile itself.

Priya: And those checksums mean that if someone tries to swap out a library, even if they keep the same version number, the build will fail because the hash won't match what's recorded in the lockfile. That’s a strong signal for integrity. What does this actually show in terms of data quality?

Nadia: It shows that you can achieve high integrity builds because you have a way to verify the integrity of those dependencies against whatever is currently available, which helps guard against malicious tampering during distribution. They also detail how this tool allows for rebuilding projects from historical commits using a freeze feature.

Elias: The rebuild functionality is where it gets really interesting; they show you can generate a new POM file that incorporates all dependency information from the lockfile, replacing original versions with the frozen ones, and then invoke Maven with that new file to reproduce the build exactly as described in that historical state.

Priya: Reproducing historical builds is a big deal for research because it means if we find an issue in an older version, we can perfectly recreate that exact environment to debug it without worrying about how the dependency resolution might have subtly changed over time. That’s real value for reproducibility studies.

Nadia: So, the paper sets up this blueprint architecture for high-integrity builds in the context of Maven, which is a major build system in enterprise environments where consistency matters most. It’s designed to be compatible with continuous development practices through tools like GitHub Actions for automation.

Elias: The automation part is smart; they don't just want it to be a manual step but integrated into the CI/CD pipeline for continuous validation and automatic lockfile updates, which keeps things current without sacrificing integrity.

Priya: The inclusion of plugin integrity in the lockfile is also noteworthy because plugins are part of the software supply chain, so validating their versions and checksums ensures that the entire build system isn't compromised by a bad plugin. That broad scope makes it much more robust than just focusing on project dependencies.

The paper's improvements: Nadia: Now we look at what they propose as improvements, and they focus on making this tool more practical for daily use. They suggest adding support for adding Maven plugins directly into the lockfile to ensure the integrity of the build system itself.

Elias: That extends the security boundary beyond just project libraries; if a plugin is tampered with or replaced, that could compromise the whole build process, so validating those plugin versions and checksums ensures that part of the software supply chain is covered too.

Priya: I see what you mean regarding the plugins—it shows they are thinking about the entire ecosystem surrounding a build, not just the application code itself. The ability to validate those plugin artifacts is something we can use to create more resilient experimental setups for testing how vulnerabilities propagate through different layers.

Nadia: Beyond that, they highlight that Maven-Lockfile requires minimal configuration from developers compared to other tools like Gradle, which makes it much more accessible for everyday Java projects. They also include essential elements like checksums and cover all the necessary fields needed for integrity and reproducibility.

Elias: That's a practical consideration; if it’s too complicated to adopt, nobody is going to use it, so they’ve designed it to require minimal effort while still delivering the most important elements for ensuring integrity. They are balancing security needs with developer experience here.

Priya: The trade-off between ease of use and comprehensive coverage seems like a smart design choice because they've managed to include all those necessary details without making the configuration overly burdensome for the average user. That balance is something I can definitely appreciate in research focused on practical application.

Conclusion: Nadia: So, to wrap up this discussion on "Maven-Lockfile: High Integrity Rebuild of Past Java Releases," we’ve covered how this tool provides a blueprint for high-integrity builds by pinning dependencies and verifying them with checksums, ensuring historical reproducibility through rebuilding old versions. It seems like the main takeaway is that we now have a system where you can reliably recreate any past release using pinned dependency information from the lockfile.

Elias: Agreed; the combination of deterministic builds, integrity checks against tampering, and the ability to reproduce older versions makes it a significant step forward in making Maven builds more reliable for serious development work. It moves us closer to having a standard way of guaranteeing what we've built actually matches what was intended.

Priya: I think the implication is that for anyone working on complex, long-term projects, this capability provides an auditable trail that lets you check the integrity of past decisions with confidence. Knowing exactly what went into a build from last year is incredibly useful for long-term maintenance and security planning.

Nadia: Exactly; it equips Java developers with modern build integrity features with minimal configuration effort, and we can start seeing how this affects the wider software ecosystem. We're ready to move on to the next paper.

Elias: That’s right; we have a solid tool here that handles dependency resolution determinism by freezing versions and verifying everything with checksums, which is what this paper is all about.

Université de Montréal · KTH Royal Institute of Technology

cs.SE, cs.CR

Submitted: 2025-10-01

Updated: 2025-10-06

Journal ref: Proceedings of the IEEE/ACM 48th International Conference on Software Engineering, 2026

DOI: 10.1145/3774748.3787615

Code: https://github.com/chains-project/maven-lockfile

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

Importance score: 91/100

The gist: Modern software projects depend on many third-party libraries, complicating reproducible and secure builds [5].

Key concepts

Maven-Lockfile: A tool that generates lockfiles for Maven projects. It captures all direct and transitive dependencies along with their cryptographic checksums to create a frozen dependency graph, addressing the non-determinism in Maven builds.
Transitive Dependencies: Dependencies that are pulled in indirectly by a project's direct dependencies. The tool captures these indirect dependencies along with their checksums, ensuring a complete and verifiable record of what is used during the build process.
High Integrity Builds: A build process where the integrity of all components is verified. This is achieved by capturing checksums for every dependency and plugin, allowing users to detect if artifacts have been tampered with after download.
Reproducible Builds: The ability to generate a new POM file incorporating frozen dependency information from a lockfile and run Maven to reproduce the build exactly as it was in a historical state. This is crucial for debugging and long-term maintenance.

Terminology

Elias — 14× in this paper · explained in 2 episodes
Nadia — 10× in this paper · explained in 2 episodes
Verification — 6× in this paper · explained in 2 episodes
Consistency — 2× in this paper · explained in 3 episodes
Core — 1× in this paper · explained in 2 episodes
Fidelity — 1× in this paper · explained in 2 episodes

Summary

Modern software projects depend on many third-party libraries, complicating reproducible and secure builds [5]. Several package managers address this with the generation of a lockfile that freezes dependency versions and can be used to verify the integrity of dependencies. Yet, Maven, one of the most important package managers in the Java ecosystem, lacks native support for a lockfile. We present Maven-Lockfile to generate and update lockfiles, with support for rebuilding projects from past versions. Our lockfiles capture all direct and transitive dependencies with their checksums, enabling high integrity builds. Our evaluation shows that Maven-Lockfile can reproduce builds from historical commits and is able to detect tampered artifacts. With minimal configuration, Maven-Lockfile equips Java projects with modern build integrity and build reproducibility, and fosters future research on software supply chain security in Java.

We here present Maven-Lockfile, which adds state-of-the-art lockfile support for Maven. Our tool generates lockfiles, validates and rebuilds projects based on them, bringing essential integrity features to Maven. Lockfiles produced by Maven-Lockfile contain versions of dependencies and their checksums, covering both direct and transitive dependencies. Maven-Lockfile is compatible with continuous development practices through a GitHub Action that automates the generation, validation, and update of lockfiles in Continuous Integration pipelines.

To sum up, our contributions are:

• A blueprint architecture for high-integrity builds in the context of Maven – one of the most important build systems in enterprise contexts.

• Maven-Lockfile, a tool1 for ensuring the integrity of a Maven build and for guarding the build against malicious tampering with the artifacts.

• An experimental evaluation showing how Maven-Lockfile enables rebuilding old versions of a non-trivial, real-world Java project.

Maven is one of the most popular package managers in the Java ecosystem. In Maven, dependencies are declared in the project’s pom.xml file. Each dependency is identified by three attributes: groupId, artifactId, and version. The version may be fixed, but developers can also choose to declare it as the latest available version; or as a version range. When building a project, Maven resolves the dependencies of those packages: it determines which specific version to use for every dependency of a project. This process is fundamentally not deterministic. Even if a project’s own pom.xml specifies exact versions, the transitive dependencies may still rely on ranges or unspecified versions. As a result, different builds at different points in time may resolve to different versions, leading to builds that behave differently. This problem is compounded by the fact that resolved dependencies are largely invisible to developers. They are not aware that the versions of transitive dependencies have changed, which makes debugging and reproducing builds more difficult. In addition, Maven does not provide a built-in mechanism to ensure that downloaded artifacts have not been tampered with during distribution. These fundamental limitations highlight the need for proper lockfile support in Maven to guarantee determinism, integrity, and security of Maven builds.

Lockfiles extend the idea of pinning by freezing the entire dependency graph, recording the exact versions of both direct and transitive dependencies as they are resolved by the package manager [2]. Lockfiles may also contain additional details, such as the version of the package manager used and checksums for each dependency package. Lockfiles make builds reproducible and transparent, no matter when or where they are executed. They provide several important benefits: (i) Deterministic builds: The same dependency graph is installed every time the project is built, avoiding silent upgrades [8], (ii) Integrity and security: Checksums in lockfiles allow the verification of downloaded artifacts, reducing the risk of tampering [2], (iii) Transparency and auditing: Lockfiles enable comparing builds, enabling a full audit trail of changes in dependencies.

Maven-Lockfile also offers the possibility to add Maven plugins to the lockfile. Maven plugins are themselves artifacts downloaded from external repositories, forming part of the software supply chain and influencing the build result. If a plugin is replaced or tampered with, it could compromise the entire build process. Including plugins in the lockfile ensures that their versions and checksums are validated, protecting not only the project’s dependencies but also the integrity of the build system itself.

When generating a lockfile for a project, one needs to include four key fields [2]: resolved package versions, package checksums, package source, and a way to distinguish between resolved direct and indirect dependencies. Among the most popular package managers, only Go and Cargo include all these elements. Maven-Lockfile is the first system to equip Java projects with state-of-the-art build integrity. The other popular build automation tool for Java, Gradle, includes a built-in solution to generate lockfiles. However, in practice, Gradle lockfiles are rarely used because their configuration is not user-friendly. First, the lockfile generation is not the default behavior. In addition to limited usability, Gradle lockfiles omit important details that should be part of a lockfile, such as checksums of resolved dependencies. The key novelty of Maven-Lockfile compared to Gradle is that it requires minimal configuration effort from developers and includes the most important elements to ensure integrity and reproducibility. Maven-Lockfile finally brings high integrity builds to Java developers.

Maven-Lockfile brings lockfiles to Maven (cf. Figure 1): It enables generating lockfiles (subsection 3.1), validating the integrity of build environments based on them (subsection 3.2), rebuilding old versions of a project (subsection 3.3), and automatically updating lockfiles (subsection 3.4), equipping Java projects with high integrity builds (subsection 3.5).

To answer RQ1, we use Maven-Lockfile to rebuild ten randomly chosen previous releases of Maven-Lockfile itself, starting from the first release supporting rebuilding from 2023-06-05. For each release, we checkout the corresponding commit and the corresponding lockfile. We first reproduce the build environment by downloading the Java and Maven versions specified in the lockfile. We then use the chosen release of Maven-Lockfile to produce a frozen POM from the committed lockfile of the old release (cf. Section 3.3). Finally, we validate the build environment and rebuild Maven-Lockfile using the frozen POM.

To answer RQ2, generating the lockfile for Maven-Lockfile itself and running validate against it gives no errors, which is a prequisite. We then modify the first dependency listed in the lockfile, the jar for com.google.code.gson:gson:2.13.2 by extracting and repackaging it, thus changing access times in the zip. Running validate against the lockfile again, Maven-Lockfile correctly raises an error, reporting that the checksum of the gson dependency has changed with respect to the lockfile. After rebuilding using the modified dependency, the test suite on the newly built artifact passes, illustrating that some adversarial malicious modification of gson can go undetected under normal Maven operations of a CI/CD pipeline.

Overall, our evaluation shows that Maven-Lockfile enables rebuilding old releases with reproduced dependency resolution, as frozen in the lockfile. We have introduced Maven-Lockfile, a state-of-the-art tool to validate the integrity of Maven builds, reproduce old builds, and automatically integrate with modern software engineering processes. Our evaluation shows that Maven-Lockfile can successfully rebuild previous project versions using pinned dependencies from the lockfile, and is able to detect tampered artifacts. The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers. Future research is needed to study how lockfiles can integrate with other software supply chain security mechanisms, such as transparency logs.

We have introduced Maven-Lockfile, a state-of-the-art tool to validate the integrity of Maven builds, reproduce old builds, and automatically integrate with modern software engineering processes. Our evaluation shows that Maven-Lockfile can successfully rebuild previous project versions using pinned dependencies from the lockfile, and is able to detect tampered artifacts. The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers. Future research is needed to study how lockfiles can integrate with other software supply chain security mechanisms, such as transparency logs.

The paper also notes that "There is scarce literature on longitudinal build reproducibility. We know some factors that break reproducibility, such as missing version information or nondeterministic transitive dependencies, but we lack tools for verifying reproducibility. To the best of our knowledge, Maven-Lockfile is the first system to enable systematic longitudinal reproducibility in real-world Java projects. Furthermore, Moreover, we have shown that Maven-Lockfile detects artifacts that have been tampered with." Future research can explore how lockfiles can be extended and integrated with existing security mechanisms, such as digital signatures of artifacts or transparency logs, to provide even stronger guarantees for the software supply chain. Beyond Java, the design of Maven-Lockfile provides a blueprint for bringing lockfile support to Maven and other ecosystems that currently lack it. Our paper informs general strategies for reproducible builds and supply chain protection across different build and dependency management systems.

The evaluation results show that In nine out of ten cases, it is possible to rebuild the project based on this environment. Major version 4 fails to rebuild due to a bug in the dependency resolution used by Maven-Lockfile. Specifically, Maven-Lockfile incorrectly added transitive dependencies with the test scope to the frozen pom.xml, instead of the same transitive dependency without the test scope. Dependencies with the test scope are not available in non-test classpaths and thus, the compilation fails as Maven cannot access the expected classes." This was fixed in version 5.1.0, after which rebuilding has been stable.

For RQ2, Maven-Lockfile correctly raises an error, reporting that the checksum of the gson dependency has changed with respect to the lockfile. This illustrates that some adversarial malicious modification of gson can go undetected under normal Maven operations of a CI/CD pipeline. The paper concludes by stating, The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers.

The paper also states that Maven-Lockfile is the first system to equip Java projects with state-of-the-art build integrity. It also mentions that "Gradle lockfiles are rarely used because their configuration is not user-friendly. First, the lockfile generation is not the default behavior. In addition to limited usability, Gradle lockfiles omit important details that should be part of a lockfile, such as checksums of resolved dependencies."

The evaluation table shows results for generating new lockfiles (Generate), validating old lockfiles (Validate), and rebuilding from them (Rebuild). For RQ1, "All releases contain a valid lockfile, demonstrating that the generation of lockfiles behaves correctly and all could be used to validate the build environment. In nine out of ten cases, it is possible to rebuild the project based on this environment."

The paper also notes that Validating and rebuilding version 3.0.1 and 3.1.0 required the use of Maven-Lockfile version 2. This is because the major version 3.x of Maven-Lockfile added new fields to the lockfile which were not backwards compatible. And for versions up to and including 5.1.0, the lockfiles contained the previous-SNAPSHOT version instead of the version specified in the pom at the release tag. Version 5.5.0, similar to major version 3, introduced new fields requiring the use of the previous version of Maven-Lockfile (in this case 5.4.2) to successfully validate."

The paper concludes by stating, We have introduced Maven-Lockfile, a state-of-the-art tool to validate the integrity of Maven builds, reproduce old builds, and automatically integrate with modern software engineering processes. The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers. Future research is needed to study how lockfiles can integrate with other software supply chain security mechanisms, such as transparency logs."

The summary is:

Maven-Lockfile addresses the lack of native lockfile support in Maven by generating lockfiles that capture all direct and transitive dependencies with their checksums, enabling high integrity builds. Lockfiles record the exact versions and checksums of both direct and transitive dependencies, making builds reproducible and transparent. The benefits include deterministic builds, integrity and security through checksum verification against tampering, transparency for auditing build changes. Maven-Lockfile supports continuous development practices via a GitHub Action for automated generation, validation, and update in CI pipelines. It includes support for adding Maven plugins to ensure the integrity of the build system itself. Key features include generating lockfiles (Section 3.1), validating the integrity of build environments based on them (Section 3.2), rebuilding old versions of a project (Section 3.3) by creating a frozen POM file incorporating dependency information from the lockfile, and automatically updating lockfiles via a CI pipeline (Section 3.4). The novelty compared to Gradle is that Maven-Lockfile requires minimal configuration effort and includes essential elements like checksums, unlike Gradle's rarely used lockfiles which omit important details. Evaluation demonstrated that Maven-Lockfile can successfully rebuild previous project versions using pinned dependencies from the lockfile, as frozen in the lockfile. It also successfully detects tampered artifacts by checking checksums; for example, modifying a dependency and running validation correctly raises an error reporting a changed checksum. The tool is presented as the first system to equip Java projects with state-of-the-art build integrity and systematic longitudinal reproducibility in real-world Java projects. Future research should explore integrating lockfiles with other security mechanisms like transparency logs. The evaluation showed that In nine out of ten cases, it is possible to rebuild the project based on this environment. However, a bug in version 4 failed to rebuild due to incorrect handling of test scope dependencies; this was fixed in version 5.1.0. The paper concludes by stating, The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers. The paper also notes that Maven-Lockfile is the first system to equip Java projects with state-of-the-art build integrity. It also mentions that "Gradle lockfiles are rarely used because their configuration is not user-friendly. First, the lockfile generation is not the default behavior. In addition to limited usability, Gradle lockfiles omit important details that should be part of a lockfile, such as checksums of resolved dependencies. The evaluation table shows results for generating new lockfiles (Generate), validating old lockfiles (Validate), and rebuilding from them (Rebuild). For RQ1, All releases contain a valid lockfile, demonstrating that the generation of lockfiles behaves correctly and all could be used to validate the build environment. In nine out of ten cases, it is possible to rebuild the project based on this environment. The paper also notes that Validating and rebuilding version 3.0.1 and 3.1.0 required the use of Maven-Lockfile version 2. This is because the major version 3.x of Maven-Lockfile added new fields to the lockfile which were not backwards compatible. And for versions up to and including 5.1.0, the lockfiles contained the previous-SNAPSHOT version instead of the version specified in the pom at the release tag. Version 5.5.0, similar to major version 3, introduced new fields requiring the use of the previous version of Maven-Lockfile (in this case 5.4.2) to successfully validate. The paper concludes by stating, We have introduced Maven-Lockfile, a state-of-the-art tool to validate the integrity of Maven builds, reproduce old builds, and automatically integrate with modern software engineering processes. The novelty of Maven-Lockfile lies in its full coverage of the essential elements needed for integrity and reproducibility, equipping Java projects with modern build integrity at minimal cost for developers. Future research is needed to study how lockfiles can integrate with other software supply chain security mechanisms, such as transparency logs."

The summary is:

Improvements for AI systems

Here are the specific improvements that can be made to AI systems, based on the insights provided by Maven-Lockfile: High Integrity Rebuild of Past Java Releases, along with what those improved AI systems could achieve:

The development of a state-of-the-art dependency management system (like Maven-Lockfile) that captures and verifies the complete, deterministic dependency graph, including transitive dependencies and their cryptographic checksums.
The implementation of automated CI/CD pipelines that automatically generate, validate against a frozen lockfile, and update dependency records in real-time.
The creation of a mechanism to reliably reproduce historical software builds from specific versions (longitudinal reproducibility), ensuring that the exact same dependency resolution used at any past point in time can be perfectly recreated.
The integration of build environment metadata (OS version, Maven version, Java version) into the lockfile to detect and explain discrepancies in build results caused by environmental changes.
The development of a robust integrity verification tool that detects subtle tampering or silent updates to downloaded artifacts by comparing current artifact checksums against those recorded in the lockfile.

These improved AI systems can achieve the following:

Automated, Tamper-Proof Software Development: An AI system could ensure that every software release is built deterministically, guaranteeing that the exact same code is compiled and packaged regardless of when or where the build occurs.
Secure Historical Debugging and Auditing: Developers could instantly recreate any past version of a complex project to debug historical bugs or validate security concerns, eliminating the ambiguity caused by shifting transitive dependencies.
Proactive Supply Chain Security: The AI system can continuously monitor for unauthorized changes in third-party libraries, flagging potential tampering before it compromises a production build, effectively guarding against sophisticated software supply chain attacks.
Accurate Build Environment Diagnostics: The system can diagnose build failures not just based on code changes, but also on subtle shifts in the execution environment (e.g., detecting if a change in the underlying operating system or compiler version is causing unexpected behavior).
Guaranteed Reproducibility for Critical Systems: For high-stakes applications (like medical devices or financial software), this capability provides an auditable, verifiable guarantee that the deployed software exactly matches the verified source code and dependencies from a specific historical commit.

Abstract

Modern software projects depend on many third-party libraries, complicating reproducible and secure builds. Several package managers address this with the generation of a lockfile that freezes dependency versions and can be used to verify the integrity of dependencies. Yet, Maven, one of the most important package managers in the Java ecosystem, lacks native support for a lockfile. We present Maven-Lockfile to generate and update lockfiles, with support for rebuilding projects from past versions. Our lockfiles capture all direct and transitive dependencies with their checksums, enabling high integrity builds. Our evaluation shows that Maven-Lockfile can reproduce builds from historical commits and is able to detect tampered artifacts. With minimal configuration, Maven-Lockfile equips Java projects with modern build integrity and build reproducibility, and fosters future research on software supply chain security in Java.