# Chainguard Libraries for Java

URL: https://edu.chainguard.dev/software-security/learning-labs/ll202607.md
Last Modified: July 24, 2026
Tags: Learning Labs, Chainguard Libraries

Learning lab for July 2026 on Chainguard Libraries for Java, covering CVE remediation, protected fallback to Maven Central, and cooldown policy.

AI frontier models are accelerating the discovery of vulnerabilities in Java applications at a pace that teams can’t keep up with. If your team is stuck on older Java versions that are hard to upgrade, you need support to remediate those vulnerabilities so you can get time back in your day to build.
In the July 2026 Learning Lab, Manfred Moser shares the details behind Chainguard Libraries for Java, with an overview of how to start using remediated versions directly with Apache Maven.
Manfred covers and demonstrates the following new features:
CVE remediation for Spring Framework and other libraries Protected fallback to Maven Central Cooldown and other policies The lab uses a hands-on demo project to migrate a typical Maven build to Chainguard Libraries.
Watch the recording
Questions The following questions were asked by the audience during the event, and responses are added since time ran out to answer them all:
How does Chainguard differ from eg: “pip-audit” for Python? or npm run audit for Node? ..etc. pip-audit and npm audit are reactive scanners that flag known vulnerabilities in dependencies you already pulled from public registries. Chainguard Libraries is preventive: dependencies are rebuilt from source in the hardened Chainguard Factory and served with malware scanning and cooldown controls, closing off the build and distribution attack surface a scanner cannot see. The two are complementary. The VEX feed from Chainguard includes information about remediated CVEs on Chainguard Libraries and can be used by scanners.
For backported fixes for Java specifically, does Chainguard have an n-? support model as to which versions fixes will be backported to? There is no fixed n-minus matrix. Backports target critical and high CVEs on older versions that customers still run and that upstream no longer patches, prioritized by usage and demand. Request specific libraries through your account team. Typically n-? policies also are not meaningful since they are heavily impacted by the release cadence of upstream projects and the presence of multiple maintained major version streams. Chainguard focuses on the customer demand for backports.
When you say. “source” - is it the source Github repo? or the public registry (Eg: PyPI for python) Source means the upstream code in a source code manager such as GitHub or GitLab, not the binary from a registry like PyPI, npm, or Maven Central. Chainguard verifies the project’s source URL and rebuilds from that code, so packages without a valid, verifiable source URL are out of scope and no binary is produced.
I don’t see “Manage pull tokens” option under my Profile for Libraries Creating pull tokens requires the ecosystem entitlement and the matching pull_token_creator role, such as libraries.java.pull_token_creator. Without both, the option does not appear. Tokens live under Overview on the Manage pull tokens tab, not a personal profile menu. Ask an administrator to confirm your entitlement and role, or create tokens with chainctl auth pull-token.
Is there a way to update the policy, change cooldown period Yes. With the Owner role, and upstream fallback enabled, create a policy with a cooldown value and enforce it:
chainctl libraries policy create --name=java-trust --cooldown-days=0 chainctl libraries policy enable java-trust --ecosystem=JAVA --mode=ENFORCEThe default is 7 days, and --cooldown-days=0 deactivates cooldown. One custom policy per ecosystem carries all your cooldown, block, and override rules.
Any support for other tech - Golang, Rust Chainguard Libraries currently covers the Java, JavaScript, and Python ecosystems. Future plans are considering Golang, Rust, .NET, and others.
How do you deal with custom / non-standard / non-one-step builds? E.e. build that require (undocumented) properties set? In the context of Chainguard Libraries on the Chainguard side, we determine how to build libraries with the help of our expert engineers and our agentic infrastructure.
In the context of customers using Chainguard Libraries on their own projects, you must troubleshoot and debug these details with the help of Apache Maven and other tools.
For the fix using this as an example do these fixes get pushed to the open source package instead of a private Chainguard repo? If not how come? Remediated fixes ship from the dedicated java-remediated Chainguard repository with a -0.cgr.N suffix, not upstream as the released artifact. These backports target older versions upstream no longer patches. Chainguard cannot publish them under the same coordinates on Maven Central. Chainguard does collaborate with upstream projects to contribute fixes as source code where possible and the project is interested.
If we are overriding versions how do we ensure integrity and stability of the application? Overriding dependency versions with CVE-remediated Java libraries allows you to keep the version difference of the change minimal and isolated to the CVE fixes. Nevertheless you must test your application thoroughly to ensure the integrity and stability of your application. When upgrading more libraries, and introducing larger version drifts, this need for verification and potentially adjusted code becomes more and more critical, and can result in significant necessary changes, that must be tested and verified like any other application change.
How do you ensure that the dependencies that you use during build do not contain any malicious code? When using Chainguard Libraries for Java with the fallback to upstream Maven Central, you can rely on the extensive analysis and scanning of the artifacts performed by Chainguard.
Resources Demo project on GitHub Slide deck Chainguard Libraries documentation