CISA's Log4j advisory lists inventory first: identify every asset that uses the library, cloud assets included, and assume every Java and Log4j version is vulnerable until verified. You cannot patch what you cannot find, and Log4j was often bundled inside other products, so the search has to go deeper than your own code.
Where a library hides
- Direct dependencies. Listed in your build file. Easy to find.
- Transitive dependencies. Pulled in by something you depend on. Not in your build file, visible only in a resolved tree or lockfile.
- Shaded or bundled copies. Packed inside a larger JAR or product, sometimes renamed. A scan of the build file will miss them.
- Vendor products. Software you run but did not build can include the library. Your supplier has to tell you.
- Container images and old artifacts. A base image or an archived build can hold a version nobody has touched in years.
A practical approach
- Start with source. Generate an SBOM for each repository from its resolved dependencies and search for the package name.
- Scan what you deploy. Scan container images and built artifacts too, since they contain what actually runs.
- Ask suppliers. For every third party product that runs on Java, ask whether it contains Log4j and which version.
- Check the core versus API split. The Apache security page says only the
log4j-coreJAR is affected, so record which one each hit contains. - Rank by exposure. Internet facing services that log user controlled input come first.
- Re-scan on a schedule. New copies appear with every build.
Why this was hard in December 2021
CISA's advisory asks for both an inventory and a hunt for compromise, including configuration changes since 1 December 2021. Teams without a current inventory did both jobs by hand, in parallel, under pressure. Teams with an SBOM per build started with a list.
What an SBOM does and does not give you
An SBOM answers "which components are in this build." It does not tell you whether the vulnerable code is reachable, whether an attacker can reach the input, or whether a bundled copy was renamed. Pair it with reachability analysis and with supplier statements.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard produces SBOMs and runs dependency scanning across repositories, with reachability analysis to help rank findings. You can try a free scan at gold.safeguard.sh/scan. For background on the bug, see why a logging library ran attacker code.
Quick check
Why is patching Java not a Log4j fix?
CISA says you must upgrade the Log4j library itself. The Java runtime is a separate thing.
Does a clean build file mean no Log4j?
No. Transitive and bundled copies may not appear in the build file.
Sources
Last reviewed: 19 October 2026.
