Find every copy, decide whether it is exposed, pin a fixed version, rebuild and redeploy, then prove the old version is gone. In Java the hard part is step one, because the same library can arrive as a direct dependency, a transitive one, a shaded copy, or a nested jar in a container.
Definition
A Log4j-style event is a critical vulnerability in a library that sits in a huge number of applications, usually deep in the dependency tree. The response is mostly inventory work, with a short patching step at the end.
The runbook
1. Name the target precisely. Write the exact artifact coordinates and the affected and fixed versions from the advisory. If a library has several coordinates, list them all.
2. Search source. In every repository, run the tree for that artifact. In Maven, mvn dependency:tree -Dincludes=group:artifact. In Gradle, dependencyInsight against runtimeClasspath. See Why is this dependency on my classpath. Do not forget buildscript and plugin classpaths.
3. Search artifacts. Source misses what you cannot see in source. Check deployed JARs, WARs and images. Spring Boot archives keep libraries under BOOT-INF/lib. Shaded JARs may hide copies, see shaded JARs.
4. Search what you did not build. Vendor products and application servers can bundle Java libraries. Ask the vendor and record the answer.
5. Decide exposure. Is the vulnerable code reachable from untrusted input in this application? Rank by internet exposure and data sensitivity. This ordering is a prioritisation tool, not a reason to skip anything. See reachability.
6. Fix. Raise the version. In Maven, pin through dependencyManagement. In Spring Boot, set the managed version property. In Gradle, add a constraint. Links: Maven exclusion and pin, Spring Boot override, Gradle constraint.
7. Check the advisory for follow-ups. First fixes are sometimes incomplete, as the Log4j sequence showed. See Log4j had three CVEs in a week. Read advisories again 24 hours later.
8. Redeploy and verify. Rebuild, run tests, deploy, then re-run steps 2 and 3 against what is running. A fixed repository does not prove a fixed production.
9. Record it. Keep the list of affected systems, owners, dates and evidence. Auditors and customers will ask.
Mitigation while you wait
Where a patch cannot ship today, follow the advisory's mitigations, restrict network exposure, and add detection. Mark each system as mitigated, not fixed, and track it to closure.
What makes the next one easier
- An SBOM per build, stored and searchable.
- Pinned versions with a lockfile.
- A named owner for each service.
- A gate that blocks known vulnerable versions from merging.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a new disclosure is matched against the components you already track.
Where Safeguard fits
Safeguard offers zero-day discovery, SBOM and dependency scanning, reachability analysis, and policies and gates for blocking vulnerable versions. Fix pull requests are available through autonomous remediation, which is off by default. Try the free scan.
Quick check
Is patching the repository enough?
No. Verify the deployed artifact or image, since an old build may still be running.
Where do teams usually miss copies?
In transitive paths, shaded JARs, nested jars in images and vendor software.
Last reviewed: 19 October 2026.
