You do. The official jlink documentation states that developers are responsible for updating their custom runtime images. When the JDK vendor ships a security fix, an image already built with jlink does not change on its own, so you need a rebuild trigger tied to JDK releases.
What jlink produces
The jlink tool assembles a set of modules and their transitive dependencies into a custom runtime image. You choose modules with the add-modules option, and the tool brings in what they require. The result can be much smaller than a full JDK, because it carries only the parts your app uses.
Smaller means fewer packages and fewer scanner findings in the Java layer. That is a real benefit, and the reason many teams adopt it.
The patching catch
A stock JRE image from a registry is rebuilt by its maintainers when a new JDK release lands. You get the fix by pulling a newer tag or digest.
A jlink image is different. It is a copy of parts of a particular JDK build, frozen into your own image. The tool's documentation says plainly that the developer owns updates. No one else will rebuild it for you.
| Approach | Who rebuilds for a JDK fix | What you must do |
|---|---|---|
| Stock JRE tag | Image maintainer | Pull and redeploy |
| Distroless Java | Image maintainer | Pull and redeploy |
| Custom jlink runtime | You | Re-run the jlink stage and rebuild |
Make rebuilding automatic
- Build the runtime in a stage that starts from a JDK image you reference by tag and digest.
- Run jlink with the modules your app needs, and copy the result into the final stage.
- Schedule a rebuild at least weekly, with the pull option so the build fetches a fresh JDK base.
- Record the JDK version used in a label or in the SBOM so you can tell which services carry which JDK.
- Alert when the JDK vendor publishes a security update and your latest build is older.
FROM eclipse-temurin:21-jdk AS jre-build
RUN jlink --add-modules java.base,java.logging,java.sql \
--strip-debug --no-man-pages --no-header-files \
--compress=2 --output /javaruntime
# Use the same distribution family as the JDK build stage
FROM ubuntu:24.04
COPY --from=jre-build /javaruntime /opt/java
ENV PATH="/opt/java/bin:$PATH"
COPY app.jar /app/app.jar
USER 1000
ENTRYPOINT ["java", "-jar", "/app/app.jar"]
To find the modules your app needs, the JDK ships a dependency analysis tool called jdeps. Test thoroughly, since a missing module surfaces as a run time error.
Missing module trouble
Apps that use reflection, service loading or optional features can need modules that static analysis misses. The jlink documentation mentions a bind-services option to link service provider modules and their dependencies. Run your integration tests against the custom runtime before shipping it.
Where Safeguard fits
The hard part of a custom runtime is knowing which services embed which JDK build. Safeguard generates SBOMs and supports asset discovery, so you can look up affected images when a JDK advisory appears. Policies can flag stale builds. A free scan shows the dependency side of the same picture.
Quick check
Does a jlink image get smaller scan results?
Often fewer, because unused modules are not included. The trade-off is that you carry the rebuild duty described above.
Can I use jlink with an unmodular application?
jlink links modules, so classpath applications usually need an analysis step to pick the right JDK modules. Check the current JDK documentation for your Java version.
Sources
Last reviewed: 19 October 2026.
