Log4J Analysis

If the Log4j Analysis is useful to you, or if you'd like to see the functionality expanded, let us know! Reach out to your Customer Service representative to start a conversation.


Sonatype is making the Log4j Data Insight functionality temporarily available to Nexus Lifecycle customers to provide them with information that may be useful in identifying and remediating instances of log4j embedded in their applications. This class analysis insight identifies vulnerable log4j class files in components that Lifecycle cannot definitively identify.


Under a normal Lifecycle scan, class files implicated with a log4j vulnerability could go unreported if they are not similarly matched to a specific versioned component.

But, because vulnerable class files for the log4j vulnerability have a unique fingerprint, it can be detected in the Lifecycle analysis even when the package is not known. The Logj4 analysis uses both exact class file hash matching and Advanced Binary Fingerprinting (partial matching) to identify vulnerable classes. The insight will show when partial matching was used to identify a vulnerable class file.

The primary targets of this insight are "uberjars" and "shaded jars," which are typically proprietary artifacts. It will also analyze jars that were similarly matched by Nexus Lifecycle.

The results of the log4j analysis do not necessarily prove that your project is vulnerable. It only identifies where the the implicated class files have been found in the code.

Please note that manifest-only scans may produce duplicate results.

Accessing the Log4J Analysis

To see the Log4j Analysis on your IQ Server, you'll need to be a Lifecycle customer and be part of our Product Preview Program. Reach out to your Customer Service representative.

Click the cogwheel icon in the top right-hand corner of the browser UI, then click Data Insights at the bottom.

You'll be brought to the Data Insights landing page. Click Log4j Analysis on the left.

Reading and Understanding the Log4J Analysis

Example of the Log4J analysis

The Log4j analysis shows results for the latest scan of each application and includes applications scanned within the last 30 days. The date range is provided at the top of the page.

The table's values are as follows:

Column NameMeaning
Application NameThis is the Lifecycle application name that contains the vulnerable artifacts. This is linked to the Lifecycle application configuration page for easy navigation to find out more information about the application. Only the applications you have permission to see will be displayed.
StageThis refers to the scan stage of the application.
Problem CodeDenotes the exact CVE that may be present in the application.
Location (and Match State)

The location within the artifact that contains the potentially vulnerable classes. Click the chevron at the right to show the full location.

Because some uber/shaded jars have modified the package name and contents of the classes, we use Sonatype Advanced Binary Fingerprinting partial matching technology to identify potentially vulnerable components.

A match state of Exact means Sonatype has found an exact match of a known implicating class file.

A match state of Partial means Sonatype has found a partial match of a known implicating hash file.

Possible Errors

Currently, there are two possible error states.

If there are no applications in the data table, then Lifecycle did not find exact or partial matches to any known vulnerable log4j class files in your applications.

If you see the red box labeled An error occurred loading data, then your scanned apps have not been processed yet.


Given the severity of the log4j vulnerabilities, we highly recommend reviewing the Log4j Analysis on a regular basis.

  • Open the analysis and take note of the implicated applications. Use the button at the top of the analysis to save a CSV file locally.
  • Click each link in the Application column to go to that application's Orgs and Policies page. Scroll to the bottom of the page to see the Access section.
    • This section should help you identify the application's owners. 
  • Using that information, reach out to development teams with apps on the Log4j Analysis. Alert them that their application may be vulnerable to the log4j vulnerability.
    • If the Log4j Analysis finds an Exact match, then regular Lifecycle scans would have previously alerted you or the development team to the presence of a log4j vulnerability.
      • If the component can be upgraded to a non-vulnerable version, do so.
      • If the component can't be upgraded, waive the vulnerability in the appropriate report and document any mitigation efforts taken by the development team.
    • If the Log4j Analysis finds a Partial match, then the contents of a class file in that application are similar to the contents of a class file from a vulnerable version of log4j. This result may come from a shaded jar, uber jar, or from a developer changing a log4j class file incrementally to better support a function, fix a bug, etc.
      • Class files implicated in this way can be tricky to fix. Supply the CSV file to the development team so they can identify the exact location of the implicated class file. Ask for a commitment to fix it and document their efforts.
  • Document the results for each application on the Log4j Analysis. The ideal state is that you know the overall log4j-based risk for each app on the analysis.

Remember that an application's business purpose and function will strongly influence how much risk it brings into your organization. For example, an app with a log4j vulnerability that is purely internal may not need remediation.